次の方法で共有

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

信頼されていない、または悪意のある可能性のあるコードからコンテナー ワークロードをセキュリティで保護するために、AKS にはポッド サンドボックスと呼ばれるメカニズムが含まれるようになりました。 ポッド サンドボックスは、コンテナー アプリケーションと、コンテナー ホストの共有カーネルおよびコンピューティング リソース (CPU、メモリ、ネットワークなど) との間の分離境界を提供します。 アプリケーションは、分離された軽量ポッド仮想マシン (VM) でスピンアップされます。 ポッドサンドボックスは、他のセキュリティ対策またはデータ保護制御を補完して、アーキテクチャ全体の機密情報をセキュリティで保護するための規制、業界、またはガバナンスのコンプライアンス要件を満たすのに役立ちます。

この記事は、この新機能とその実装方法を理解するのに役立ちます。

前提条件

  • 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 が付属しています。 az aks install-cli コマンドを使用して kubectl をローカルにインストールできます。

制限事項

ポッドサンドボックスに適用できる制約を次に示します。

  • Kata コンテナーは、従来のコンテナーが Azure Files と高パフォーマンスのローカル SSD で実現できる IOPS パフォーマンス制限に達しない可能性があります。

  • Microsoft Defender for Containers は、Kata ランタイム ポッドの評価をサポートしていません。

  • Kata ホスト ネットワーク アクセスはサポートされていません。 VM 内からホスト ネットワーク構成に直接アクセスすることはできません。

  • ポッド サンドボックスを使用した CPU とメモリの割り当てには、 runcと比較した他の考慮事項があります。 「考慮事項」ページの「メモリー管理」セクションを参照してください。

しくみ

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

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

Kata コンテナーを使用したポッド サンドボックスのデプロイは、コンテナーをデプロイする標準的な 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 であり、入れ子になった仮想化をサポートする任意の Azure VM サイズが機能します。 たとえば、Dsv3 VM です。

    次の例では、myResourceGroup 内の 1 つのノードで 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 バージョン変更資格情報 コマンドを使用してクラスター名とリソース グループ名の既定値を置き換えます。

    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 クラスターを作成する既存のリソース グループの名前を入力します。
    • クラスター名: AKS クラスターの一意の名前 ("myAKSCluster" など) を入力します。
    • --name: "nodepool2" などのクラスター ノード プールの一意の名前を入力します。
    • --workload-runtime: KataVmIsolation を 指定して、ノード プールでポッド サンドボックス機能を有効にします。 --workload-runtime パラメーターにより、次の他のパラメーターが次の要件を満たすようになります。 それ以外の場合、コマンドは失敗し、対応するパラメーターに関する問題を報告します。
      • --os-sku: AzureLinux。 この機能は、Azure Linux os-sku でのみサポートされています。
      • --node-vm-size: 第 2 世代 VM であり、入れ子になった仮想化をサポートする任意の Azure VM サイズが機能します。 たとえば、Dsv3 VM です。

    次の例では、"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

  2. az aks update コマンドを実行して、クラスターでポッドのサンドボックス化を有効にします。

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

アプリケーションのデプロイ

ポッドサンドボックスを使用すると、Kata ランタイムを利用しない "通常の" ポッドと、ランタイムを利用する Kata ポッドを組み合わせてデプロイできます。 デプロイ時の 2 つの主な違いは、Kata ポッドの仕様にライン runtimeClassName: kata-vm-isolation があることです。

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"]

    runtimeClassNameSpec の値は kata-vm-isolation です。

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

    kubectl apply -f kata-app.yaml

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

    pod/isolated-pod created

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

Kata ポッドのカーネルと Kata 以外のポッドのカーネルの違いを確認する場合は、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. AKS クラスター内のコンテナーにアクセスするために、kubectl exec コマンドを実行してシェル セッションを開始します。 この例では、 kata-pod 内のコンテナーにアクセスしています。

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

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

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

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

    uname -r

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

    [user]/# uname -r
6.6.96.mshv1

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

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

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

    uname -r

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

    6.6.100.mshv1-1.azl3

クリーンアップ

この機能の評価が完了したら、Azure の料金を回避するために、不要なリソースをクリーンアップします。 評価またはテストの一部として新しいクラスターをデプロイした場合は、az aks delete コマンドを使用してクラスターを削除できます。

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

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

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

次のステップ

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