Azure Kubernetes Service (AKS) は、クラスターをすばやくデプロイおよび管理することができる、マネージド Kubernetes サービスです。 この記事では、Azure CLI を使用して Windows Server コンテナーを実行する AKS クラスターをデプロイします。 また、Windows Server コンテナー内の ASP.NET サンプル アプリケーションをクラスターにデプロイします。
注
AKS クラスターの迅速なプロビジョニングを開始するため、この記事には、評価のみを目的とした既定の設定でクラスターをデプロイする手順が含まれています。 運用環境に対応したクラスターをデプロイする前に、ベースライン参照アーキテクチャを理解して、ビジネス要件にどの程度合致しているかを検討することをお勧めします。
開始する前に
このクイックスタートは、Kubernetes の基本的な概念を理解していることを前提としています。 詳細については、「Azure Kubernetes Services (AKS) における Kubernetes の中心概念」を参照してください。
- Azure アカウントをお持ちでない場合は、開始する前に無料アカウントを作成してください。
Azure Cloud Shell で Bash 環境を使用します。 詳細については、「Azure Cloud Shell の概要」を参照してください。
CLI リファレンス コマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。 詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
ローカル インストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 その他のサインイン オプションについては、「 Azure CLI を使用した Azure への認証」を参照してください。
初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。 拡張機能の詳細については、「Azure CLI で拡張機能を使用および管理する」を参照してください。
az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。 最新バージョンにアップグレードするには、az upgrade を実行します。
- この記事では、Azure CLI のバージョン 2.0.64 以降が必要です。 Azure Cloud Shell を使用している場合は、最新バージョンが既にインストールされています。
- クラスターの作成に使用している ID に、適切な最小限のアクセス許可が与えられていることを確認します。 AKS のアクセスと ID の詳細については、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」を参照してください。
- 複数の Azure サブスクリプションをお持ちの場合は、az account set コマンドを使用して、リソースが課金の対象となる適切なサブスクリプション ID を選択してください。 詳細については、Azure CLI で Azure サブスクリプションを管理する方法に関するページを参照してください。
リソース グループを作成する
Azure リソース グループは、Azure リソースが展開され管理される論理グループです。 リソース グループを作成する際は、場所を指定するよう求められます。 この場所は、リソース グループのメタデータが格納される場所です。また、リソースの作成時に別のリージョンを指定しない場合は、Azure でリソースが実行される場所です。
- az group create コマンドを使用して、リソース グループを作成します。 次の例では、WestUS2 の場所に myResourceGroup という名前のリソース グループを作成します。 次のコマンドとこの記事内のその他のコマンドを BASH シェルに入力します。
export RANDOM_SUFFIX=$(openssl rand -hex 3)
export REGION="canadacentral"
export MY_RESOURCE_GROUP_NAME="myAKSResourceGroup$RANDOM_SUFFIX"
az group create --name $MY_RESOURCE_GROUP_NAME --___location $REGION
結果:
{
"id": "/subscriptions/xxxxx-xxxxx-xxxxx-xxxxx/resourceGroups/myResourceGroupxxxxx",
"___location": "WestUS2",
"managedBy": null,
"name": "myResourceGroupxxxxx",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
AKS クラスターを作成する
このセクションでは、次の構成で AKS クラスターを作成します。
- クラスターは、確実に動作するように 2 つのノードで構成されます。 ノードは、Kubernetes ノード コンポーネントとコンテナー ランタイムを実行する Azure 仮想マシン (VM) です。
- クラスター上のすべての Windows Server ノードの管理者資格情報は、
--windows-admin-password
パラメーターと--windows-admin-username
パラメーターによって設定されます。これは Windows Server のパスワード要件を満たしている必要があります。 - ノード プールは
VirtualMachineScaleSets
を使用します。
Azure CLI を使用して AKS クラスターを作成するには、以下の手順に従います。
- クラスターの Windows Server ノードの管理者資格情報として使用するユーザー名を作成します。 (入力を求められた元の例。この Exec ドキュメントでは、環境変数は非対話形式で設定されています)。
export WINDOWS_USERNAME="winadmin"
- 前の手順で作成した管理者ユーザー名のパスワードを作成します。 パスワードは 14 文字以上で、Windows Server パスワードの複雑さの要件を満たしている必要があります。
export WINDOWS_PASSWORD=$(echo "P@ssw0rd$(openssl rand -base64 10 | tr -dc 'A-Za-z0-9!@#$%^&*()' | cut -c1-6)")
-
az aks create コマンドを使用してクラスターを作成し、
--windows-admin-username
および--windows-admin-password
パラメーターを指定します。 次のコマンド例では、前のコマンドで設定 したWINDOWS_USERNAME と WINDOWS_PASSWORD の値を使用してクラスターを作成します。 一意性を得るために、ランダムなサフィックスがクラスター名に追加されます。
export MY_AKS_CLUSTER="myAKSCluster$RANDOM_SUFFIX"
az aks create \
--resource-group $MY_RESOURCE_GROUP_NAME \
--name $MY_AKS_CLUSTER \
--node-count 2 \
--enable-addons monitoring \
--generate-ssh-keys \
--windows-admin-username $WINDOWS_USERNAME \
--windows-admin-password $WINDOWS_PASSWORD \
--vm-set-type VirtualMachineScaleSets \
--network-plugin azure
数分後、コマンドが完了し、クラスターに関する情報が JSON 形式で返されます。 場合によっては、クラスターのプロビジョニングに数分以上かかることがあります。 プロビジョニングには最大 10 分かかります。
パスワード検証エラーが発生し、設定したパスワードが長さと複雑さの要件を満たしている場合は、別のリージョンにリソース グループを作成してみてください。 その後、新しいリソース グループを使用してクラスターを作成してください。
ノード プールの作成時に管理者のユーザー名とパスワードを指定しない場合、ユーザー名は azureuser に設定され、パスワードはランダムな値に設定されます。 詳細については、「Windows Server に関する FAQ」を参照してください
管理者のユーザー名は変更できませんが、az aks update
を使用して AKS クラスターが Windows Server ノードに使用する管理者パスワードを変更することはできます。 詳細については、「Windows Server に関する FAQ」を参照してください。
Windows Server コンテナー用のノード プールをサポートする AKS クラスターを実行するには、Azure CNI の (高度な) ネットワーク プラグインを使用するネットワーク ポリシーを、ご利用のクラスターで使用する必要があります。
--network-plugin azure
パラメーターは Azure CNI を指定します。
ノード プールを追加する
既定では、Linux コンテナーを実行できるノード プールを使用して、AKS クラスターが作成されます。 Linux ノード プールと共に Windows Server コンテナーを実行できる別のノード プールを追加する必要があります。
Kubernetes バージョン 1.25.0 以降の場合、Windows Server 2022 が既定のオペレーティング システムです。 Windows Server 2019 は、以前のバージョンの既定の OS です。 特定の OS SKU を指定しない場合、Azure によって、クラスターで使用される Kubernetes のバージョンの既定の SKU を使用して新しいノード プールが作成されます。
既定の OS SKU を使用するには、OS SKU を指定せずにノード プールを作成します。 ノード プールは、クラスターの Kubernetes バージョンに基づき、既定のオペレーティング システムに対して設定されます。
az aks nodepool add
コマンドを使用して、Windows ノード プールを追加します。 次のコマンドでは、npwin という名前の新しいノード プールが作成され、それが myAKSCluster に追加されます。 コマンドではまた、az aks create
の実行時に作成された既定の仮想ネットワークの既定のサブネットが使用されます。 OS SKU が指定されていないため、ノード プールは、クラスターの Kubernetes バージョンに基づいて既定のオペレーティング システムに設定されます。
az aks nodepool add \
--resource-group $MY_RESOURCE_GROUP_NAME \
--cluster-name $MY_AKS_CLUSTER \
--os-type Windows \
--name npwin \
--node-count 1
クラスターに接続する
Kubernetes クラスターを管理するには、Kubernetes のコマンドライン クライアントである kubectl を使用します。 Azure Cloud Shell を使用している場合、kubectl
は既にインストールされています。
kubectl
をローカルにインストールして実行したい場合は、az aks install-cli コマンドを呼び出します。
-
kubectl
コマンドを使用して、Kubernetes クラスターに接続するように を構成します。 このコマンドは、資格情報をダウンロードし、それを使用するように Kubernetes CLI を構成します。
az aks get-credentials --resource-group $MY_RESOURCE_GROUP_NAME --name $MY_AKS_CLUSTER
- クラスター ノードの一覧を返す kubectl get コマンドを使用してクラスターへの接続を確認します。
kubectl get nodes -o wide
次の出力例は、クラスター内のすべてのノードを示しています。 すべてのノードの状態が [準備完了] であることを確認します。
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
aks-nodepool1-20786768-vmss000000 Ready agent 22h v1.27.7 10.224.0.4 <none> Ubuntu 22.04.3 LTS 5.15.0-1052-azure containerd://1.7.5-1
aks-nodepool1-20786768-vmss000001 Ready agent 22h v1.27.7 10.224.0.33 <none> Ubuntu 22.04.3 LTS 5.15.0-1052-azure containerd://1.7.5-1
aksnpwin000000 Ready agent 20h v1.27.7 10.224.0.62 <none> Windows Server 2022 Datacenter 10.0.20348.2159 containerd://1.6.21+azure
注
各ノード プールのコンテナー ランタイムは、コンテナー ランタイムの下に表示されます。 コンテナー ランタイムの値は containerd://
で始まり、これはそれぞれがコンテナー ランタイムとして containerd
を使用することを意味します。
アプリケーションをデプロイする
Kubernetes のマニフェスト ファイルでは、どのコンテナー イメージを実行するかなど、クラスターの望ましい状態を定義します。 この記事では、Windows Server コンテナー内で ASP.NET サンプル アプリケーションを実行するために必要なすべてのオブジェクトを作成するのにマニフェストを使用します。 このマニフェストには、ASP.NET サンプル アプリケーションの Kubernetes デプロイと、インターネットからアプリケーションにアクセスするための外部 Kubernetes サービスが含まれています。
ASP.NET サンプル アプリケーションは、.NET Framework のサンプルの一部として提供され、Windows Server コンテナー内で実行されます。 AKS では、Windows Server コンテナーは Windows Server 2019 以降のイメージをベースにしている必要があります。 Kubernetes マニフェスト ファイルではまた、ノード セレクターを定義する必要があり、この定義では、Windows Server コンテナーを実行できるノード上でご利用の ASP.NET サンプル アプリケーションのポッドを実行するように AKS クラスターに指示します。
-
sample.yaml
という名前のファイルを作成し、以下の YAML 定義をコピーします。
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: sample
spec:
replicas: 1
template:
metadata:
name: sample
labels:
app: sample
spec:
nodeSelector:
"kubernetes.io/os": windows
containers:
- name: sample
image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
resources:
limits:
cpu: 1
memory: 800M
ports:
- containerPort: 80
selector:
matchLabels:
app: sample
---
apiVersion: v1
kind: Service
metadata:
name: sample
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
selector:
app: sample
YAML マニフェスト ファイルの内訳については、「デプロイと YAML マニフェスト」を参照してください。
YAML ファイルをローカルに作成して保存する場合は、[ファイルのアップロード/ダウンロード] ボタンを選択し、ローカル ファイル システムからファイルを選択することで、CloudShell の既定のディレクトリにマニフェスト ファイルをアップロードできます。
- kubectl apply コマンドを使用してアプリケーションをデプロイし、ご利用の YAML マニフェストの名前を指定します。
kubectl apply -f sample.yaml
次の出力例は、デプロイおよびサービスが正常に作成されたことを示しています。
{
"deployment.apps/sample": "created",
"service/sample": "created"
}
アプリケーションをテストする
アプリケーションが実行されると、Kubernetes サービスによってアプリケーション フロント エンドがインターネットに公開されます。 このプロセスが完了するまでに数分かかることがあります。 場合によっては、サービスのプロビジョニングに数分以上かかることがあります。 プロビジョニングには最大 10 分かかります。
-
kubectl get pods コマンドを使って、デプロイされたポッドの状態を確認します。 続行する前に、すべてのポッドを
Running
の状態にします。
kubectl get pods
while true; do
export EXTERNAL_IP=$(kubectl get service sample -o jsonpath="{.status.loadBalancer.ingress[0].ip}" 2>/dev/null)
if [[ -n "$EXTERNAL_IP" && "$EXTERNAL_IP" != "<pending>" ]]; then
kubectl get service sample
break
fi
echo "Still waiting for external IP assignment..."
sleep 5
done
最初に、サンプル サービスの "EXTERNAL-IP" が "保留中" として表示されます。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sample LoadBalancer xx.xx.xx.xx pending xx:xxxx/TCP 2m
"EXTERNAL-IP" アドレスが "保留中" から実際のパブリック IP アドレスに変わったら、 を使用して ウォッチ プロセスを停止します。CTRL-C
kubectl
次のサンプル出力は、サービスに割り当てられている有効なパブリック IP アドレスを示しています。
{
"NAME": "sample",
"TYPE": "LoadBalancer",
"CLUSTER-IP": "10.0.37.27",
"EXTERNAL-IP": "52.179.23.131",
"PORT(S)": "80:30572/TCP",
"AGE": "2m"
}
数分後にサービスの外部 IP アドレスに対して Web ブラウザーを開いて、実際のサンプル アプリを確認します。
次のステップ
このクイックスタートでは、Kubernetes クラスターをデプロイした後、そこへ Windows Server コンテナー内の ASP.NET サンプル アプリケーションをデプロイしました。 このサンプル アプリケーションはデモ専用であり、Kubernetes アプリケーションのすべてのベスト プラクティスを表すわけではありません。 実稼動用に AKS を使用した完全なソリューションを作成するうえでのガイダンスについては、AKS ソリューション ガイダンスに関する記事を参照してください。
AKS の詳細を学習し、コードからデプロイまでの完全な例を確認するには、Kubernetes クラスター チュートリアルに進んでください。
Azure Kubernetes Service