Azure Kubernetes Service (AKS)を使用したポッドのサンドボックス化

AKS でのポッド のサンドボックス化では、Kata コンテナーを使用して、独自のゲスト カーネルを使用して軽量仮想マシン (VM) で各サンドボックス ポッドを実行します。 このコンピューティング境界により、ホスト カーネルと他のポッド VM 内のワークロードからワークロードが分離されます。 アーキテクチャ、利点、ユース ケースの詳細については、Azure Kubernetes Service (AKS)でのポッド サンドボックスの概要に関するページを参照してください。

この記事では、Linux AKS クラスター Azure新規または既存のポッド サンドボックスをデプロイし、Kata ランタイムを使用してアプリケーションをデプロイし、必要に応じてカーネルの分離を確認します。

前提条件

• Azure CLI バージョン 2.80.0 以降。 az --versionを実行して Azure CLI のバージョンを確認し、az upgradeを実行してアップグレードします。 詳細については、「 Azure CLI のインストール」の手順を参照してください。
• AKS では、Kubernetes バージョン 1.27.0 以降でポッドサンドボックスがサポートされています。
• Kubernetes クラスターを管理するには、Kubernetes コマンド ライン クライアント kubectlを使用します。 Azure Cloud Shell には kubectl が付属しています。 kubectl コマンドを使用して、az aks install-cliをローカルにインストールできます。
• Microsoft.Network/AllowBringYourOwnPublicIpAddress機能は、サブスクリプションに登録する必要があります。 この機能は、Kata ランタイムを使用するポッド サンドボックス ワークロードに必要です。

Microsoft.Network/AllowBringYourOwnPublicIpAddress機能を登録する

1. az feature register コマンドを使用して、サブスクリプションにMicrosoft.Network/AllowBringYourOwnPublicIpAddress機能を登録します。 登録には数分かかる場合があります。

   az feature register --namespace Microsoft.Network --name AllowBringYourOwnPublicIpAddress
   

2. ポッドのサンドボックスをデプロイする前に、az feature show コマンドを使用して登録状態がRegisteredされていることを確認します。

   az feature show --namespace Microsoft.Network --name AllowBringYourOwnPublicIpAddress --query properties.state --output tsv
   

3. 機能が登録されたら、az provider register コマンドを使用して、Microsoft.Network リソース プロバイダーの登録を更新します。

   az provider register --namespace Microsoft.Network
   

制限事項

ポッドのサンドボックス化には、次の制約が適用されます。

• Kata コンテナーは、従来のコンテナーが Azure Files と高パフォーマンスのローカル SSD で実現できる IOPS パフォーマンス制限に達しない可能性があります。
• Microsoft Defender for Containers は、Kata ランタイム ポッドの評価をサポートしていません。
• Kata ホスト ネットワーク アクセスはサポートされていません。 VM 内からホスト ネットワーク構成に直接アクセスすることはできません。
• ポッド サンドボックスを使用した CPU とメモリの割り当ては、 runcとは異なります。 各 Kata ポッドは、ポッドのメモリ制限に基づいて固定メモリサイズが決まる pod VM 上で実行されます。制限を指定しない場合、既定値は 512Mi になります。 CPU の制限によってポッド VM の vCPU 割り当てが決まります。小数部の制限は、その割り当てに対して vCPU 全体に切り上げられます。 詳細については、「 ポッドのサンドボックス化に関する考慮事項」を参照してください。
• ポッドのサンドボックス化は、Azure Linux でのみサポートされます。 Ubuntu とWindowsはサポートされていません。 詳細については、AKS Azure Linux コンテナー ホストを参照してください。
• ポッド サンドボックスを使用するノード プールで Federal Information Processing Standard (FIPS) または Trusted Launch を有効にすることはできません。 詳細については、「 ポッドのサンドボックス化に関する考慮事項」を参照してください。
• ポッド サンドボックスを使用するノード プールでは、Arm64 アーキテクチャはサポートされていません。

しくみ

AKS 上のポッド サンドボックスは、オープンソースの Kata Containers プロジェクトの上に構築されます。 AKS 用の Azure Linux コンテナー ホストで実行されている Kata コンテナーは、VM ベースの分離とポッドごとに個別のカーネルを提供します。 ポッドサンドボックスを使用すると、ポッドごとにリソースを割り当てることができ、同じホスト上で実行されている他の Kata Containers または名前空間コンテナーと共有されません。

ソリューション アーキテクチャは、次の主要コンポーネントに基づいています。

• AKS 用の Azure Linux コンテナー ホスト
• Microsoft Hyper-V ハイパーバイザー
• オープンソースの Cloud Hypervisor 仮想マシン モニター (VMM)
• ランタイムの Kata Containers との統合

Kata Containers を使用したポッド のサンドボックスのデプロイは、コンテナーをデプロイする標準的な containerd ワークフローに似ています。 ポッド サンドボックスが有効になっているクラスターには、ポッド マニフェスト (runtimeClassName: kata-vm-isolation) で参照できる特定のランタイム クラスが付属しています。 ランタイム クラスの既定値とカスタマイズの詳細については、「 ポッドのサンドボックス化に関する考慮事項」を参照してください。

ポッドでこの機能を使用するには、唯一の違いは、ポッド スペックにkata-vm-isolation を追加することです。ポッドが kata-vm-isolation runtimeClass を使用すると、ハイパーバイザーは、ワークロードが動作するために、独自のカーネルを使用して軽量の仮想マシンを起動します。

ポッドサンドボックスを使用してクラスターを作成する

次の手順を実行して、Azure CLI を使用して AKS Linux AKS クラスターをデプロイします。

1. 次のパラメーターを使用して az aks create コマンドを実行して、AKS クラスターを作成します。

   パラメーター	必須の値	メモ
   --workload-runtime	KataVmIsolation	ノード プールでポッドのサンドボックス化を有効にします。
   --os-sku	AzureLinux	ポッドのサンドボックスでは、Azure Linux OS SKU のみがサポートされます。
   --node-vm-size	入れ子になった仮想化をサポートする第 2 世代 VM サイズ	たとえば、 Dsv3 シリーズの VM サイズを使用します。
   --node-count	3	この例の 3 つのノードを作成します。 ワークロードの値を調整します。

   次の例では、myResourceGroup に 3 つのノードを含む myAKSCluster という名前のクラスターを作成します。

   az aks create \
       --name myAKSCluster \
       --resource-group myResourceGroup \
       --os-sku AzureLinux \
       --workload-runtime KataVmIsolation \
       --node-vm-size Standard_D4s_v3 \
       --node-count 3 \
       --generate-ssh-keys
   

2. 次のコマンドを実行して、Kubernetes クラスターのアクセス資格情報を取得します。 az aks get-credentials コマンドを使用し、クラスター名とリソース グループ名の値を置き換えます。

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
   

3. kubectl get pods コマンドを実行して、すべての名前空間内のすべてのポッドを一覧表示します。

   kubectl get pods --all-namespaces
   

既存のクラスターでポッドサンドボックスを有効にする

既存の AKS クラスターでこの機能を使用するには、次の要件を満たす必要があります。

• クラスターでは、Kubernetes バージョン 1.27.0 以降が実行されます。

• 次のコマンドを使用して、ポッドをホストするノード プールを作成してポッドのサンドボックス化を有効にします。

1. az aks nodepool add コマンドと次のパラメーターを使用して、AKS クラスターにノード プールを追加します。

   パラメーター	必須の値	メモ
   --resource-group	既存の AKS クラスターを含むリソース グループ	たとえば、 myResourceGroupを使用します。
   --cluster-name	既存の AKS クラスターの名前	たとえば、 myAKSClusterを使用します。
   --name	一意のノード プール名	たとえば、 nodepool2を使用します。
   --workload-runtime	KataVmIsolation	ノード プールでポッドのサンドボックス化を有効にします。
   --os-sku	AzureLinux	ポッドのサンドボックスでは、Azure Linux OS SKU のみがサポートされます。
   --node-vm-size	入れ子になった仮想化をサポートする第 2 世代 VM サイズ	たとえば、 Dsv3 シリーズの VM サイズを使用します。
   --node-count	1	この例のノードを 1 つ作成します。 ワークロードの値を調整します。

   次の例では、"myResourceGroup" の "nodepool2" に 1 つのノードを持つノード プールを "myAKSCluster" に追加します。

   az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataVmIsolation --node-vm-size Standard_D4s_v3 --node-count 1
   

2. az aks update コマンドを実行してクラスター構成を調整し、クラスターが新しいノード プールとKataVmIsolationワークロード ランタイムを認識するようにします。

   az aks update --name myAKSCluster --resource-group myResourceGroup
   

3. クラスターの更新が正常に完了し、ポッド サンドボックス ノード プールで想定されるワークロード ランタイム、OS SKU、VM サイズが使用されていることを確認します。

   az aks show \
       --name myAKSCluster \
       --resource-group myResourceGroup \
       --query provisioningState \
       --output tsv
   
   az aks nodepool show \
       --cluster-name myAKSCluster \
       --resource-group myResourceGroup \
       --name nodepool2 \
       --query "{workloadRuntime:workloadRuntime, osSKU:osSKU, vmSize:vmSize}" \
       --output table
   

   クラスターのプロビジョニング状態は Succeededする必要があります。 ノード プールの出力には、 KataVmIsolation、 AzureLinux、選択した VM サイズが表示されます。

ポッドサンドボックスを使用してアプリケーションをデプロイする

ポッドのサンドボックス化を使用すると、Kata ランタイムを使用しない標準ポッドと、ランタイムを使用する Kata ポッドを組み合わせてデプロイできます。 Kata ポッドは、そのポッド仕様で runtimeClassName: kata-vm-isolation を指定します。

ランタイム クラスは Kata ランタイムを選択しますが、特定のポッド サンドボックス ノード プールでワークロードを実行する必要がある場合は、スケジュール制約も定義する必要があります。 たとえば、 nodeSelectorで組み込みの AKS ノード プール ラベルを使用します。 nodepool2をポッド サンドボックス ノード プールの名前に置き換えます。

spec:
  runtimeClassName: kata-vm-isolation
  nodeSelector:
    kubernetes.azure.com/agentpool: nodepool2

分離をより強化するには、Pod サンドボックス用ノードプールをテイントし、対応するトレランスを Kata ワークロードに追加できます。 対応する許容値がないテイントでは、他のワークロードがそのノードプールでスケジュール設定されなくなります。 詳細については、「 AKS クラスターでのノード テイントの使用」を参照してください。

Kata ランタイムを使用してアプリケーションをデプロイする

AKS クラスターに Kata ランタイムを使用してポッドをデプロイするには、次の手順を実行します。

1. kata-app.yaml という名前のファイルを作成して、kata ポッドを記述し、次のマニフェストを貼り付けます。

   kind: Pod
   apiVersion: v1
   metadata:
     name: isolated-pod
   spec:
     runtimeClassName: kata-vm-isolation
     containers:
     - name: kata
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

   runtimeClassNameのポッド スペック値がkata-vm-isolation。

2. kubectl apply コマンドを実行して Kubernetes ポッドをデプロイし、kata-app.yaml ファイルを指定します。

   kubectl apply -f kata-app.yaml
   

   コマンドの出力は、次の例のようになります。

   pod/isolated-pod created
   

カーネルの分離を確認する (省略可能)

1. Kata ポッドと非 Kata ポッドのカーネルを比較するには、 normal-app.yaml という名前のファイルを作成します。 次のマニフェストは、Kata ランタイムを使用しない標準ポッドを定義します。

kind: Pod
apiVersion: v1
metadata:
  name: normal-pod
spec:
  containers:
  - name: non-kata
    image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

1. kubectl apply コマンドを使用して、標準ポッドをデプロイします。

   kubectl apply -f normal-app.yaml
   

2. AKS クラスター内のコンテナーにアクセスするには、 kubectl exec コマンドを実行してシェル セッションを開始します。 この例では、 分離ポッド内のコンテナーにアクセスしています。

   kubectl exec -it isolated-pod -- /bin/sh
   

   Kubectl はクラスターに接続し、/bin/sh内の最初のコンテナー内でisolated-pod実行し、ターミナルの入力ストリームと出力ストリームをコンテナーのプロセスに転送します。 Kata 以外のポッドをホストしているコンテナーへのシェル セッションを開始して、違いを確認することもできます。

3. isolated-pod からコンテナーへのシェル セッションを開始した後、コマンドを実行して、kata コンテナーがポッド サンドボックスで実行されていることを確認します。 サンドボックスの外部にある Kata 以外のコンテナーとは異なるカーネル バージョンがあります。

   カーネルのバージョンを確認するには、次のコマンドを実行します。

   uname -r
   

   ポッド サンドボックスのカーネルからの出力は次の例のようになります。

   [user]/# uname -r
   6.6.96.mshv1
   

4. 通常ポッドからコンテナーへのシェル セッションを開始して、カーネルの出力を確認します。

   kubectl exec -it normal-pod -- /bin/bash
   

   カーネルのバージョンを確認するには、次のコマンドを実行します。

   uname -r
   

   次の例は、 通常ポッドを実行している VM からの出力に似ています。これは、ポッド サンドボックス内で実行されている Kata ポッドとは異なるカーネルです。

   6.6.100.mshv1-1.azl3
   

リソースをクリーンアップする

1. この機能の評価が完了したら、Azure料金を回避する必要がなくなったリソースをクリーンアップします。 評価またはテストの一環として新しいクラスターをデプロイした場合は、次の az aks delete コマンドを実行して AKS クラスターを削除します。

   az aks delete --resource-group myResourceGroup --name myAKSCluster
   

2. 既存のクラスターにポッド サンドボックスをデプロイした場合は、 kubectl delete pod コマンドを使用してポッドを削除できます。

   kubectl get pods
   kubectl delete pod <kata-pod-name>
   

3. ポッド サンドボックス コンピューティング リソースを削除するには、 az aks nodepool delete コマンドを使用して Kata ノード プールを削除することもできます。 ノード プールを削除する前に、保持するワークロードがノード プールで実行されていないことを確認します。

   az aks nodepool delete \
     --cluster-name myAKSCluster \
     --resource-group myResourceGroup \
     --name nodepool2
   

次のステップ

• ハードウェアの分離と Azure プラットフォームのメンテナンス イベントの制御を使用するための、AKS クラスターを持つノード用の Azure 専用ホストの詳細について確認します。
• ポッドサンドボックスの分離についてさらに詳しく調べ、ワークロードシナリオを調べるには、 ポッドサンドボックスラボを試してみてください。