Azure Kubernetes Service (AKS)に関するポッドのサンドボックス化に関する考慮事項

Azure Kubernetes Service (AKS)でのポッドのサンドボックス化には、リソース管理、メモリ管理、CPU 管理、およびセキュリティに関する考慮事項があります。

ポッドサンドボックスでのリソース管理

デプロイのリソース (特に大規模またはリソースに依存するワークロード) を指定する場合は、これらの考慮事項を確認してください。

Kata コンポーネント

Kata デプロイには、AKS ノードで実行されるコンポーネントと、ポッド仮想マシン (VM) 内で実行されるコンポーネントが含まれます。 このホストとゲストの分割によって、メモリと CPU 使用率の処理方法が決まります。

ポッドサンドボックスでのメモリ管理

未使用のメモリを割り当てずに、ワークロードと Kata ゲスト コンポーネントをサポートするのに十分な高さのポッド VM メモリ制限を設定します。

ポッド VM のメモリ サイズ

各ポッド VM は、ワークロードとすべての Kata ゲスト コンポーネントのメモリを取得します。 Kata エージェントや VM カーネルなどのゲスト コンポーネントの予想されるワークロード消費量を超えるメモリを含めます。 一般的なメモリ値については、 参照使用量 の値を参照してください。

Kubernetes ポッドのメモリ制限によって、ポッド VM のメモリ サイズが決まります。 ポッドのメモリ制限を変更して、ポッド VM のメモリ サイズを変更します。

RuntimeClass 通常、メモリ オーバーヘッドはポッド VM のメモリ サイズに合わせて増加します。

RuntimeClass メモリオーバーヘッド

Pod サンドボックス化ワークロードには、既定のリソース オーバーヘッド値を含む既定の Kata RuntimeClass (kata-vm-isolation) が含まれます。 リソース クォータをきめ細かく制御するには、特定のリソース オーバーヘッドを伴うカスタム RuntimeClassを設定します。 ポッド のメモリ制限では、ポッド VM で使用できるゲスト側メモリのサイズが設定されます。 RuntimeClass オーバーヘッドでは、ホスト側の Kata コンポーネントのノード容量が予約され、ゲスト コンポーネントの予想されるメモリ消費量を考慮する必要はありません。

特殊なランタイムを作成し、RuntimeClass マニフェストの overhead フィールドを使用してメモリ オーバーヘッドを指定できます。 たとえば、次のマニフェストでは、リソース消費量が少ないと予想されるワークロードのランタイムが作成されます。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

memory: "120Mi"値は、Kubernetes がポッドをスケジュールし、そのcgroupサイズを設定するときに、120Mi の固定ポッド オーバーヘッドを追加します。 handler: kata値は、AKS ノードで構成された Kata ランタイム ハンドラーと一致する必要があります。

カスタム RuntimeClassを使用する前に、 kubectl get runtimeclass を実行し、そのハンドラーが AKS クラスターでサポートされていることを確認します。

オーバーヘッドを指定する必要はありませんが、ワークロード用に予約されているリソースを細かく制御する場合にお勧めします。 既定の kata-vm-isolationRuntimeClass を使用し、ポッドのメモリ制限を指定しない場合、ポッド VM のサイズは既定で 512Mi になります。 既定の RuntimeClass では、ホスト コンポーネントに約 88Mi のメモリ オーバーヘッドが追加されるため、ポッドの cgroup 制限は 600Mi になります。

ユーザー ワークロード

Kata ワークロードでは、構成済みの ポッド VM メモリ サイズ から、Kata エージェントやゲスト VM カーネルなどのゲスト コンポーネントが消費するメモリを差し引いたメモリを使用できます。

メモリを推定するには、次のコンポーネントを使用します。

1. ポッド VM に接続します ( kubectl exec または kubectl debug してポッド内のシェルを開きます)。
2. free コマンドを実行します。
3. 使用されている列を調べて、ゲスト カーネルと Kata エージェントが消費するメモリを推定します。

メモリ cgroups

Kubernetes が Kata ポッドをスケジュールすると、kubelet はポッドをメモリ cgroupに割り当てます。 cgroupでは、ポッドで使用可能なリソースを定義できるように、ポッドのメモリ要求と制限が適用されます。

メモリ cgroup には、次の 2 つの重要なフィールドがあります。

memory.current値がmemory.maxの値を超えると、メモリ不足が検出された場合、カーネルはポッドで OOMKill をトリガーする可能性があります。

使用値を参照する

一般的なメモリ使用量の例として、次の値を使用します。 128 MiB 以下のポッド VM メモリ サイズはサポートされていません。

この表を読み取る方法: memory.current には、ポッド VM のメモリ割り当てと現在のホスト コンポーネントの使用状況が含まれます。 kubelet は、ポッドのメモリ制限とRuntimeClassオーバーヘッドからmemory.maxを計算します。 これらの値の違いは、追加のホスト コンポーネントの使用に使用できる容量を示しています。

メモリ管理のベスト プラクティス

• マニフェストで limits.memory を設定してポッド VM のメモリ サイズを指定し、すべてのデプロイに適したリソース クォータを定義します。
  • VM が起動する前に、ポッド VM のノード容量を予約するには、0 以外のポッド メモリ要求を使用します。 要求は、ポッド VM とその中で実行されるコンテナーを考慮する必要があります。
  • Kata ホスト コンポーネントが消費するノード容量を考慮するには、0 以外の RuntimeClass メモリ オーバーヘッドを使用します。
• リソースを集中的に使用するワークロードの場合は、ワークロードとゲスト コンポーネントに十分なメモリを提供するポッドのメモリ制限を設定します。
• RuntimeClass必要以上のノード容量を予約することなく、Kata ホスト コンポーネントに十分な高いメモリ オーバーヘッドを設定します。

ポッド サンドボックスでの CPU 管理

ポッドの CPU 制限と RuntimeClass オーバーヘッドを設定して、Cpu リソースを Kata ワークロードに割り当てます。 CPU 制限がない場合、Kata ホスト コンポーネントはノードで使用可能な任意の CPU 容量を使用できます。

CPU の予約

次のフィールドのいずれかまたは両方を設定して、Kata ワークロードの CPU 容量を予約します。

• RuntimeClass CPU オーバーヘッド
• ポッドの CPU 制限

2 つの値のうち少なくとも 1 つを指定すると、コントロール プレーンは、ワークロード用にノード上の指定された数の CPU を予約します。 同じノード上の他のポッドは、この予約容量にアクセスできません。

ポッドの CPU 制限

アプリケーションのマニフェストで ポッドの CPU 制限 を宣言します。 この制限により、関連付けられているポッド VM 内のコンテナーで使用できる CPU の数が制御されます。

ポッドの CPU 制限を宣言しない場合、ノードに十分な容量がある場合、AKS は 1 つの vCPU をポッド VM に割り当てます。 Kata ホスト コンポーネントには CPU 消費量の制限はありません。

RuntimeClass CPU オーバーヘッド

ワークロードをデプロイする前に、Kata ホスト コンポーネントのノード容量を予約する RuntimeClass オーバーヘッドを指定します。

RuntimeClass マニフェストの overhead フィールドを使用して CPU オーバーヘッドを指定できます。 たとえば、次のようになります。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

cpu: "250m"値は、Kubernetes がポッドをスケジュールし、そのcgroupサイズを設定するときに、固定ポッド オーバーヘッドの 0.25 vCPU を追加します。 Kata ホスト コンポーネントの予想される CPU 消費量に基づいて、この値を調整します。

CPU 管理のベスト プラクティス

• 通常、ノードに十分な空き CPU 容量がある場合、これらの予約は不要である可能性があります。
• 通常、ノードが CPU 消費量の上限に達した場合、0 以外の予約を使用すると、ポッドをより確実に実行できます。
  • ポッド CPU 要求は、Kubernetes スケジューラがワークロードに対して十分なノード容量を予約するのに役立ちます。 特定のワークロードの予約容量は、ノード上の他のワークロードでは使用できません。
• インフラストラクチャが対応できる CPU 要求を指定します。 使用可能な容量が 0 に近い場合、または要求が大きすぎる場合、ワークロードの 開始に失敗する可能性があります。
• CPU 要求を CPU の制限に合わせます。 要求は Kubernetes のスケジュール設定に影響しますが、Kata shim ではそれらを使用してポッド VM のサイズを設定しません。 CPU の制限によって、ポッド VM の vCPU 割り当てが決まります。 CPU 制限が宣言されていない場合、ポッド VM は 1 つの vCPU を受け取り、Kata ホスト コンポーネントには CPU 消費量の制限はありません。

宣言の例

ポッドのサンドボックス化に関するセキュリティに関する考慮事項

ポッドのサンドボックス化により、他のワークロードやホストからワークロードが分離されますが、次のセキュリティ リスクを考慮する必要があります。

特権ポッド

一部のワークロードには特権ポッドが必要です。 特権ポッドは作成できますが、 ホスト デバイスはポッドに接続されていません。

特権コンテナーを使用すると、ゲスト VM でルート アクセスが提供されますが、コンテナーはホストから分離された状態を維持します。

ポッドのサンドボックス化を使用する場合でも、必要な場合にのみ特権ポッドを使用します。 信頼されたユーザーのみに特権ポッドの管理を許可します。

ホスト パスストレージボリューム

hostPathボリュームを Kata ポッドにマウントすると、ホスト ファイル システムの一部がコンテナーに直接公開され、ポッドのサンドボックスの分離が弱まる可能性があります。 ポッドサンドボックスワークロードに アップストリームの hostPath セキュリティガイダンス を適用します。

/dev下のファイルは、ホスト システムではなくゲスト システムからコンテナーにマウントされるため、例外です。 この動作により、ワークロードでこのパスが必要な場合にポッドの分離が維持されます。

Azure Policy でhostPathボリュームをブロックする

Azure Policyでは、クラスター コンポーネントの一元的で一貫性のある適用と保護が提供されます。

AKS には、ベスト プラクティス を適用する組み込みのポリシー定義 が用意されています。 Kubernetes クラスター ポッドを割り当てる場合は、Deny効果を持つ許可ボリュームの種類ポリシーのみを使用し、許可されたボリュームの種類からhostPathを除外して、hostPathボリュームのマウントを試みるポッドをブロックする必要があります。

次のステップ

AKS にポッド サンドボックスをデプロイする方法について説明します。