AKS クラスターは、複数のチームまたはテナントからワークロードをスケーリングしてホストする際に、共有インフラストラクチャによって分離がより複雑になる可能性があります。 リソース集中型またはバースト性の高いワークロードが予測可能なワークロードを中断するのを防ぐために、より強力な分離が必要になる場合があります。 また、セキュリティ要件を満たすために機密性の高いワークロードを分離する必要がある場合もあります。
これらの要件を満たすために、論理的または物理的な分離戦略によってワークロードを分離できます。 論理的に分離するには、 Kubernetes 名前空間を 使用してリソースとデプロイを分離します。 名前空間は基になるクラスター インフラストラクチャを共有するため、個別のクラスターと同じ物理的分離境界は提供されません。 個別のクラスターは物理的な境界を提供しますが、クラスターが完全な容量を使用しない場合、この戦略によってコストが増加する可能性があります。
AKS でのポッドのサンドボックス化では、個別の軽量ポッド仮想マシン (VM) でワークロードを実行する機能が導入されています。 各ポッド VM にはコンピューティング分離境界があります。ワークロードは独自のゲスト カーネルで実行され、ホスト カーネルや他のポッド VM のワークロードから分離されます。
ポッドのサンドボックス化は、オープンソースの Kata Containers プロジェクトに基づいて構築されています。
Important
ポッド VM の境界では、コンピューティングの分離のみが提供されます。 AKS コントロール プレーン、ストレージまたはデータ パス、またはクラスター管理者アクセス権を持つユーザーによって実行されるアクションは分離されません。 ポッドのサンドボックスだけでは、完全なハード マルチテナント機能は提供されません。 マルチテナント デプロイの場合は、 マルチテナント ソリューションの AKS ガイダンスを 確認し、必要な ID、ネットワーク、ストレージ、ガバナンスの制御を適用します。
アーキテクチャとコンポーネント
ポッドのサンドボックス化では、Kata Containers ランタイムを使用して、サンドボックス化されたポッドごとに軽量ポッド VM を作成します。 次の図は、ホスト側コンポーネントが分離ポッド VM を作成して管理する方法と、ゲスト側コンポーネントがワークロードを実行する方法を示しています。
- ポッド マニフェストで、
runtimeClassName: kata-vm-isolationを設定して Kata Containers ランタイムを選択します。 - Containerd は、標準のランタイム shim の代わりに Kata shim (
containerd-shim-kata-v2) を呼び出します。 - Kata shim はクラウド ハイパーバイザー仮想マシン モニター (VMM) を起動します。このモニターでは、個別のゲスト カーネルと Kata エージェントを使用してポッド VM が作成されます。
- Kata エージェントは、ポッド VM 内にコンテナーとワークロード プロセスを作成して管理します。
- ポッド VM が削除されると、Kata shim はポッド VM をシャットダウンし、そのリソースをコンテナー ホストに解放します。
利点とユース ケース
ポッドのサンドボックス化により、独自のゲスト カーネルを使用して、軽量ポッド VM 内の各サンドボックス ポッドが分離されます。 このコンピューティング境界により、ワークロードがホスト カーネルと他のポッド VM のワークロードから分離されます。 ポッドのサンドボックス化をネットワーク ポリシーやAzure Policyなどの制御と組み合わせて、ポッド VM の境界でカバーされないネットワークとガバナンスのリスクに対処します。 マルチテナント デプロイのコントロールの選択に関するガイダンスについては、マルチテナント ソリューションの AKS ガイダンスを参照してください。
一般的なユース ケース
ポッドのサンドボックスは、次の場合に役立ちます。
- サンドボックスポッドごとに個別のコンピューティング分離境界を提供しながら、同じ AKS クラスター上の異なるテナントのワークロードをホストします。
- 共有クラスター容量を引き続き使用しながら、信頼されていないワークロードをホスト カーネルと他のポッド VM のワークロードから分離します。
- 機密性の高いワークロードや価値の高いワークロードを、他のポッド VM で実行されているワークロードから保護します。
- CPU とメモリの要求と制限を各ポッド VM に適用することで、他のサンドボックス ポッドに対するリソース集中型またはバースト性の高いワークロードの影響を軽減します。
- ワークロードの障害によるコンピュート環境への影響範囲をその Pod VM に限定します。
ワークロードの分離
ポッドのサンドボックス化を使用すると、サンドボックス化されたポッドごとに個別のコンピューティング分離境界を維持しながら、共有クラスター ノードにワークロードを併置できます。
ワークロードのリソース要求と制限を宣言できます。 AKS では、それらを省略すると既定値が適用されます。 ポッド VM は、リソースを集中的に消費するワークロードを、その VM に割り当てられた CPU とメモリに制限します。 ワークロードによってポッド VM の障害が発生した場合、コンピューティング分離境界によって、その障害から他のポッド VM のワークロードが保護されます。
柔軟性
サンドボックスポッドと標準ポッドは、同じクラスターで実行できます。 この柔軟性により、ポッド VM の分離を必要とするワークロードにのみ適用できます。
オープン ソース コンポーネント
ポッドのサンドボックスでは、 クラウド ハイパーバイザー VMM や Kata Containers ランタイムなどのオープンソース コンポーネントが使用されます。 オープン開発は、分離コンポーネントの透明性を提供し、コミュニティレビューを可能にします。 このアーキテクチャでは、各ポッド VM のゲスト カーネルも、Azure Linux ホスト カーネルから分離されます。
既存のワークロードを移行する
基本的なデプロイの場合は、既存のポッド仕様に Kata ランタイム クラスを追加して、ポッド VM でワークロードを実行します。 このマニフェストの変更では、標準の runc ランタイムを使用するポッドと同じ動作は保証されません。 移行の前に、ワークロードの運用動作と Kubernetes 機能の互換性を検証し、ポッド VM のリソースのサイズ設定とオーバーヘッドを考慮します。 詳細については、「 ポッドのサンドボックス化に関する考慮事項」を参照してください。
次のステップ
- デプロイ前にPod のサンドボックス化に関する考慮事項を確認してください。
- AKS にポッドサンドボックスをデプロイします。