Amazon Web Services ブログ

Amazon VPC CNI プラグインでノード 1 台に配置可能な Pod 数を増やすために

この記事は Amazon VPC CNI plugin increases pods per node limits を翻訳したものです。

—

2021年8月現在、Amazon VPC Container Networking Interface (CNI) プラグイン は「プレフィックス割り当てモード」をサポートし、AWS Nitro ベースの EC2 インスタンスタイプで、ノード1台に配置可能な Pod 数を今までより多くすることができます。VPC CNI プラグインは新しい VPC の機能を使って、IP アドレスプレフィックスを EC2 インスタンスにアタッチされた Elastic Network Interface（ENI）に関連付けることを可能にしています。ネットワークインターフェイスに個々のセカンダリ IPv4 アドレスを割り当てる代わりに、/28（16 IP アドレス）IPv4 アドレスプレフィックスを割り当てることができます。これにより、ノード 1 台に配置可能な Pod 数が大幅に向上しました。

本記事では、この機能がどのように実装されているかを深掘りしていきます。VPC CNI プラグインでプレフィックス割り当てを有効にする方法について一通り説明し、ユースケースと重要な考慮事項についても論じていきます。

Amazon VPC CNI プラグインのプレフィックス割り当てモード

Pod は、Kubernetes で作成および管理する、デプロイ可能なコンピューティングの最小単位です。Pod は、Kubernetes クラスター内で通信するために一意の IP アドレスが必要です (ホストネットワーク Pod は例外です)。Amazon Elastic Kubernetes Services (EKS) は、デフォルトで VPC Container Networking Interface (CNI) プラグイン を実行し、EC2 インスタンスのネットワークインターフェイスと IP アドレスを管理することにより、Pod に IP アドレスを割り当てます。VPC CNI プラグインは EC2 ネットワーキングと直接統合され、AWS で実行されている Kubernetes クラスターで高パフォーマンスで低レイテンシーなコンテナネットワーキングを提供します。このプラグインを使うことで、クラスターの VPC から各 Pod に IP アドレスを割り当てることができます。デフォルトでは、Pod に割り当てることができる IP アドレスの数は、EC2 インスタンスタイプにアタッチ可能なENI や インターフェイスあたりのセカンダリ IP の最大数に依存します。

プレフィックス割り当てモードでは、インスタンスタイプごとの ENI の最大数は変わりませんが、個々の IPv4 アドレスをネットワークインターフェイスに割り当てるのではなく、/28（16 IP アドレス）の IPv4 アドレスプレフィックスを割り当てるように VPC CNI プラグインを設定できるようになりました。Pod には、ENI に割り当てたプレフィックスから IPv4 アドレスを割り当てます。

どのように機能するのか

Amazon VPC CNI プラグインは、aws-node という名前の Kubernetes Daemonset としてワーカーノードにデプロイされます。このプラグインは、 Local IP Address Management (L-IPAM) と CNI プラグインという 2 つの主要なコンポーネントで構成されています。

  • L-IPAM デーモン (IPAMD)：ネットワークインターフェイスを作成してワーカーノードにアタッチし、プレフィックスをネットワークインターフェイスに割り当てます。そしてスケジュールされた Pod への割り当て用に、各ノードで IP プレフィックスのウォームプールを維持します。
  • CNI プラグイン：ホストネットワークの接続(例：ネットワークインターフェイスと仮想イーサネットのペア設定) や、Pod の namespace に正しいネットワークインターフェイスを追加する役割を担います。CNI プラグインは、Remote Procedure Calls (RPC) を介して IPAMD と通信します。

次のコマンドは、 VPC CNI プラグインが EC2 コントロールプレーンとどのようにやり取りするかを示す EC2 API 呼び出しの例です。

内部では、ワーカーノードの初期化時に IPAMD は、プライマリ ENI に CIDR ブロックプレフィックスを割り当てるように EC2 にリクエストします。

aws ec2 assign-private-ipv4-addresses --network-interface-id eni-38664474 --ipv4-prefix-count 1 --secondary-private-ip-address-count 0

より多くの IP が必要になると、既存の ENI に対して追加のプレフィックスをリクエストします。

aws ec2 assign-private-ipv4-addresses --network-interface-id eni-38664474 --ipv4-prefix-count 1 --secondary-private-ip-address-count 0

ENI に割り当てることができるプレフィックス数の上限に達すると、セカンダリ ENI を作成・アタッチします。

aws ec2 create-network-interface --subnet-id subnet-9d4a7abc --ipv4-prefix-count 1

IPAMD は、プレフィックスで消費される IP の数のマッピングを保持します。また、プレフィックス内で IP が使用されていない場合、プレフィックスを開放します。

aws ec2 unassign-ipv4-addresses --IPv4-prefix --network-interface-id eni-38664473

EC2 など他の AWS サービスとの競合を回避するため、またはサブネット内のフラグメンテーション (詳細はブログの後半で説明します）を最小限に抑えるための特別な要件がある場合には、サブネット内にプレフィックス専用のスペースを予約することも効果的です。Amazon VPC CNI プラグインは、IP アドレスの割り当てに予約済みのプレフィックスを自動的に使用します。VPC CNI プラグインは以下の API 呼び出しを自動的に実行しないことに注意してください。これはアウトオブバンドで実行する必要があります。

aws ec2 create-subnet-address-reservation --subnet-id subnet-1234 --type prefix --cidr 69.89.31.0/24

プレフィックスモードが有効になっている場合、次の図のようなプロセスで Pod に IP を割り当てます。

開始方法

このセクションでは、EKS クラスターを作成し、プレフィックス割り当てモードを設定します。プレフィックス割り当てモードは VPC CNI プラグインのバージョン 1.9.0 以降で動作します。

EKS クラスターを作成

eksctl を使用してクラスターを作成します。この例では eksctl の最新バージョンを使用していることを確認してください。注：ここでは、EKS add-ons を通じて VPC CNI の最新バージョンを自動的に検出してインストールするように eksctl に指示しています。次のマニフェストをコピーし、cluster.yaml という名前のファイルで保存します。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
 
metadata:
  name: pd-cluster
  region: us-west-2
 
iam:
  withOIDC: true

addons:
  - name: vpc-cni
    version: latest
eksctl create cluster -f cluster.yaml

プレフィックス割り当てモードを有効化

ネットワークインターフェイスにプレフィックスを割り当てるように、VPC CNI プラグインにパラメータ ENABLE_PREFIX_DELEGATION を設定します。

kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true

環境変数が設定されていることを確認します。

kubectl describe daemonset -n kube-system aws-node | grep ENABLE_PREFIX_DELEGATION

IPv4 アドレスを保持し、より高速にスケール

Amazon VPC CNI プラグインは、WARM_PREFIX_TARGET、または WARM_IP_TARGET と MINIUM_IP_TARGET のいずれか/両方の設定をサポートしています。推奨設定 (および github のインストール用マニフェストで設定されているデフォルト値) は、WARM_PREFIX_TARGET を 1 に設定することです。マニフェストでまだ設定されていない場合は、以下のコマンドでこの値を手動で設定できます。

kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1

プレフィックス割り当てモードが有効な時、WARM_PREFIX_TARGET、WARM_IP_TARGET または MINIMUM_IP_TARGET の値をゼロに設定することはできません。これらのパラメータをどんな値で設定するのかは、ユースケース次第です。設定されている場合、WARM_IP_TARGET および/または MINIMUM_IP_TARGET が WARM_PREFIX_TARGET よりも優先されます。

github のインストール用マニフェストにおいては WARM_PREFIX_TARGET が 1 で設定されており、既存のプレフィックスが 1 つの Pod でのみ使用されている場合でも、追加の完全な (/28) プレフィックスを 1 つ割り当てます。ENI にプレフィックスを割り当てるための十分なスペースがない場合、新しい ENI が生成されます。新しい ENI が作成されると、IPAMD は WARM_PREFIX_TARGET を維持するために必要なプレフィックスの数を判断し、割り当てます。新しい ENI は、既存の ENI に割り当てられたすべてのプレフィックスを使い果たした場合にのみアタッチされます。

ほとんどの場合、WARM_PREFIX_TARGET を推奨値である 1 に設定することで、インスタンスに割り当てられた未使用の IP アドレスを最小限に抑えながら、Pod の起動時間を短縮することができます。この動作は、個別のセカンダリ IP アドレスモードのデフォルト値である WARM_ENI_TARGET を 1 に設定するよりも改善されています。セカンダリ IP アドレスモードではノードに割り当てることができる IP アドレスの数がインスタンスタイプに依存していました。たとえば、c5.18xlarge の場合、ENI ごとに最大 50 の IP アドレスをデフォルトで割り当てます。プレフィックス割り当てでは、インスタンスタイプに関係なく、IP アドレスは常に /28（16 の IP アドレス）の塊で割り当てます。

ノードごとの IPv4 アドレスをさらに節約したくて、Pod の起動速度をわずかに犠牲にできる場合は、WARM_IP_TARGET および MINIMUM_IP_TARGET を設定します。これらのパラメータの利用は、WARM_PREFIX_TARGET をオーバーライドします。WARM_IP_TARGET を 16 未満の値に設定することで、IPAMD が 1 つの未使用プレフィックスを付加したままにすることを防ぐことができます。

具体的な例として、定常状態を見積もるユーザーがノードあたり 25 の Pod をデプロイするとしましょう。m5.large インスタンスを使用しており、3 つの ENI と ENIごとに 9 つのプレフィックスを割り当てることができます。このユーザーは、利用可能なIPv4 アドレスの数に制限のある VPC を扱っており、ノードに割り当てられているが未使用の IP アドレスの数を最小限に抑える必要があります。Pod の起動速度をいくらか犠牲にすることをいとわないため、デフォルトの推奨値である WARM_PREFIX_TARGET を1に設定する代わりに、WARM_IP_TARGET と MINIUM_IP_TARGET を設定することにしました。MINIUM_IP_TARGET を 25 に設定しています。これは、ベースラインとして各ノードで少なくとも 25 の Pod がスケジュールされることを想定しているためです。また、WARM_IP_TARGET を 5 に設定します。プレフィックス割り当てでは、IPAMD は IPv4 アドレスを 16 の塊でしか割り当てられないことを覚えておいてください。

クラスター内でノードが起動すると、IPAMD はプライマリ ENI に 2 プレフィックス (32 IP アドレス) を割り当てます (このユーザは CNI カスタムネットワークを使用していないため、この例ではプライマリ ENI のみが使用されます)。これで MINIMUM_IP_TARGET 25の要件を満たすことができました。そして 25 の Pod がワーカーノードにスケジュールされ、IPAMD によるアクションは実行されません。これは、Pod の要件を満たすのに十分な IP アドレスがすでに割り当てられており、7 つの未使用の IP アドレスがあり、WARM_IP_TARGET 5 の要件を満たしているからです。次に、アプリケーションのトラフィックが急増し、需要を満たすために追加で 12 Pod がワーカーノードにスケジュールされます。3 番目の Pod がスケジュールされると、IPAMD は、ノードに残っている空き IP アドレスが 4 つだけであり、WARM_IP_TARGET の 5 を下回っていると計算し、EC2 のAPI を呼び出して ENI に追加のプレフィックスを割り当てます。追加でスケジュールされた 12 の Pod のうち 7 つには、既存のプールから IP アドレスがすぐに割り当てられますが、最後の 5 つの Pod では、追加のプレフィックスを割り当てる処理にともない、IP アドレスの割り当てが開始されるのがわずかに遅れる場合があります。この新しい定常状態に達すると、ワーカーノードにはプライマリ ENI のみアタッチされ、3 つのプレフィックスがあり、合計 48 の IP が割り当てられ、37 の Pod がノード上で実行されています。

これら設定の組み合わせのユースケースと例の詳細については、VPC CNI プラグインのドキュメントを参照してください。注：WARM_IP_TARGET を使用する場合、MINIUM_IP_TARGET を設定する必要はありませんが、各ノードに ベースラインとなる Pod をクラスターにスケジュールすることが予想される場合は、この設定を推奨します。上記の例で MINIUM_IP_TARGET が設定されていない場合、IPAMD はノード起動時は 1 プレフィックスを割り当てるだけですが、25 Pod の初期スケジューリング時にも追加のプレフィックスを割り当てます。既存の ENI に割り当て可能なプレフィックスの最大数に達した場合にのみ、追加のネットワークインターフェイスをアタッチする必要があります。この m5.large の例の場合、それは 9 プレフィックス、つまり 144 の IP アドレスなので、追加の ENI が必要になることはほとんどありません。トラフィックは依然として下位にある単一のネットワークカードを通過するため、すべての Pod を1つのENIで実行しても、パフォーマンスへの影響はありません (最近ローンチした p4d.24xl インスタンスタイプのみが複数のネットワークカードをサポートします)。

以前から利用可能だった、個別のセカンダリ IP アドレスモードで WARM_IP_TARGET と MINIUM_IP_TARGET を使用するよりも、プレフィックス割り当てモードでこれらのパラメーターを設定する方がパフォーマンスが向上します。セカンダリ IP アドレスモードでは、IP アドレスの割り当てを一度に 1 つずつ制御します。WARM_IP_TARGET を設定すると、よりきめ細かな割り当てを実現するために、必要な EC2 API 呼び出しの回数が大幅に増加し、API スロットリングが発生し、新しい ENI または IP のワーカーノードへの割り当てが遅延することがあります。既存の ENI に追加のプレフィックスを割り当てることは、新しい ENI を作成してインスタンスにアタッチするよりも、EC2 APIの操作が高速になります。これにより、IPv4 アドレスの割り当てに手間がかからず、パフォーマンス特性が向上します。通常、プレフィックスの割り当ては 1 秒以内に完了しますが、新しい ENI のアタッチには最大 10 秒かかる場合があります。ほとんどのユースケースで、プレフィックス割り当てモードで実行している場合、IPAMD はワーカーノードごとに ENI を 1 つだけ必要とします。（最悪の場合）ノードあたり最大 15 個の未使用 IP がある状況が差し支えなければ、この新しいプレフィックス割り当てモードを使用し、それに伴うパフォーマンスと効率の向上を実現することを強くお勧めします。

ノードにデプロイできる Pod の最大数を計算

VPC CNI プラグインを使用する場合、設定内容によってノードごとに実行できる Pod の最大数が異なります。このローンチの一環として、EKS マネージド型ノードグループをアップデートし、VPC CNI プラグインの v1.9 以上を使用している場合に、インスタンスタイプと VPC CNI プラグインの設定値に基づいて、推奨される最大 Pod 実行数を自動的に計算および設定するようになりました。最大 Pod 実行数の値は、新規で作成されたマネージド型ノードグループ、または AMI を新しいバージョンで更新したノードグループに設定されます。これは、プレフィックス割り当てのユースケースと、CNI カスタムネットワークの両方に役立ちます。CNI カスタムネットワークを利用している際は、最大 Pod 実行数を以前は手動で低く設定する必要がありました。

重要: マネージド型ノードグループでは、Namespace kube-system にインストールされた、 aws-node という名前の DaemonSet の、aws-node というの名前のコンテナという条件で VPC CNI プラグインを探します。VPC CNI プラグインを他の名前や Namespace でインストールするようにカスタマイズした場合、マネージド型ノードグループの自動での最大 Pod 実行数計算プロセスはスキップされ、EKS 最適化 AMI に組み込まれているデフォルト値で設定されたままになります。

セルフマネージドノードグループまたはカスタム AMI を使ったマネージド型ノードグループを使用している場合は、推奨される最大 Pod 実行数を手動で計算する必要があります。プレフィックス割り当てモードで最大 Pod 実行数がどのように計算されるか見てみましょう。プレフィックスとプライベート IP アドレスの合計数は、インスタンスタイプごとに設定されている割り当て可能なプライベート IP 数に左右されることに注意してください。たとえば、m5.large インスタンスの ENI には 10 スロットの制限があり、そのうちの 1 つは ENI のプライマリ IP アドレスに必要であり、9 スロット分を /28 プレフィックスに使用できます。

次の式を使用して、プレフィックス割り当てモードが有効な場合にノード 1 台に配置可能な Pod の最大数を決定できます。

(利用するインスタンスタイプに割り当て可能な ENI の数 × (ENI ごとのスロット数制限 - 1)* 16)

下位互換性の理由から、EKS 最適化 Amazon Linux AMI のインスタンスタイプごとのデフォルトの最大 Pod 実行数は変更されません。m5.large のような小さいインスタンスタイプにプレフィックスを割り当てていくと、IP アドレスを使い果たすずっと前にインスタンスの CPU とメモリリソースを使い果たす可能性が高く、max_pods は上記の式の結果と異なる場合もあります。

セルフマネージドおよびカスタム AMI を使ったマネージド型ノードグループユーザーにおけるこのプロセスを簡素化するために、max-pod-calculator.sh スクリプトを導入して、インスタンスタイプと VPC CNI プラグインの設定に基づいた Amazon EKS の推奨最大 Pod 実行数を確認できるようにしました。

max-pods-calculator.sh をダウンロードします。

curl -o max-pods-calculator.sh https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/files/max-pods-calculator.sh

ダウンロードしたスクリプトにマシンからの実行権限を付与します。

chmod +x max-pods-calculator.sh

スクリプトを実行して max_pods の値を確認します。

./max-pods-calculator.sh --instance-type m5.large --cni-version 1.9.0 --cni-prefix-delegation-enabled

1 つの m5.large インスタンスに対して Amazon EKS が推奨する最大 Pod 実行数は次のとおりです。

110

プレフィックス割り当てが有効になっている m5.large に付加できる IPv4 アドレスの数は、実際には非常に多くなります（3 ENI ×（ENI ごとに 9 プレフィックス）* プレフィックスあたり 16 IP）= 432 IP。ただし、max Pods 計算スクリプトは、Kubernetes scalability thresholds および推奨設定に基づいて、戻り値を 110 に制限します。インスタンスタイプに 30 個を超える vCPU がある場合、この制限は 250 まで増えます。これは、内部の EKS スケーラビリティチームのテストに基づく数値です。プレフィックス割り当てモードは、プライマリ ENI が Pod に使用されない CNI カスタムネットワークのユーザーに特に適しています。プレフィックス割り当てを使用すると、プライマリ ENI を Pod に使用できなくても、ほぼすべての Nitro インスタンスタイプで少なくとも 110 の IP を付加できます。上記の例だと、CNI カスタムネットワークとプレフィックス割り当てが有効になっている m5.large に 288 の IPv4 アドレスを割り当てることができます。

マネージド型ノードグループを作成

プレフィックス割り当てモードは、AWS Nitro ベースの EC2 インスタンスタイプでサポートされています。Nitro ベースのインスタンスタイプのいずれかで Amazon Linux 2を立ち上げます。プレフィックス割り当てモードは Windows ではサポートされていません。

eksctl create nodegroup \
    --cluster pd-cluster \
    --region us-west-2 \
    --name pg-nodegroup \
    --node-type m5.large \
    --nodes 1

サンプルアプリケーションをデプロイ

ここで、プレフィックス IP の割り当てを実際にやってみるために、レプリカ 80 のサンプル NGINX アプリケーションをデプロイしてみましょう。

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 80
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: public.ecr.aws/nginx/nginx:1.21
        ports:
        - containerPort: 80
EOF

Deployment によって作成された Pod を一覧表示します。

kubectl get pods -l app=nginx

これで、マネジメントコンソールで Amazon EC2 にアクセスし、インスタンス PD-Cluster-PG-nodeGroup-Node に移動できます。[ネットワーク] タブの下に、ENI に割り当てられた IPv4 プレフィックスが表示されます。プレフィックスと ENI の数は、Pod のレプリカ数によって異なります。この場合、レプリカ数は 80 で、最低 5 つのプレフィックス (/28) です。

訳者注釈：実際ノードでは CoreDNS の Pod もプレフィックスからIPを消費しており、ノードで消費される IP 数は 80 を超えています。ゆえに下のキャプチャでは7 つ(使用中のプレフィックスが 6、WARM_PREFIX_TARGET 1 により未使用のプレフィックスが 1) のプレフィックスが割り当てられています。

ENI に追加された新しい IPv4 プレフィックスを観察するために、Deployment をスケールしてみましょう。

kubectl scale deployment.v1.apps/nginx-deployment --replicas=110

上の画像からも、ENI に新しい IPv4 プレフィックスが割り当てられたことが確認できるでしょう。

重要な考慮事項

サブネットのフラグメンテーション

EC2 が /28 IPv4 プレフィックスを ENI に割り当てる際、サブネットから連続したブロックの IP アドレスを取得する必要があります。プレフィックスの生成元のサブネットがフラグメンテーションを起こしている場合（散在したセカンダリ IP アドレスで使用率の高いサブネット）、プレフィックスの割り当てに失敗し、VPC CNI プラグインのログに次のエラーメッセージが表示されます。

failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

フラグメンテーションを避け、プレフィックスを作成するための十分に連続したスペースを確保するために、プレフィックス割り当てとともに最近発表された機能である VPC サブネット CIDR 予約を使用できます。この機能を使用すると、サブネット内の IP スペースをプレフィックスによる排他的使用のために予約できます。EC2 は、ENI または EC2 インスタンスにこのスペース内の IP を 割り当てることはなく、このスペースのフラグメンテーションを回避できます。予約を作成すると、VPC CNI プラグインは EC2 API を呼び出して、予約済みスペースから割り当て可能なプレフィックスを自動的に割り当てます。

CIDR 予約したスペースの一部が、現在既にEC2 のセカンダリ IP アドレスとして消費されている場合でも、CIDR予約を作成できます。消費されていたこの IP アドレスが解放されると、EC2 はこれらの IP アドレスを再割り当てしません。ベストプラクティスとしては、新しいサブネットを作成し、サブネット内にプレフィックス用のスペースを予約し、そのサブネットで実行されているワーカーノード用に VPC CNI プラグインでプレフィックス割り当てを有効にすることをお勧めします。EKS クラスターにインストールされた VPC CNI プラグインでプレフィックス割り当てが有効になっていて、実行する Pod 専用に新しいサブネットを作れる場合は、CIDR 予約をする必要がなくなります。

アップグレード/ダウングレード時のふるまい

プレフィックスモードは VPC CNI プラグイン v1.9.0 以降で動作します。プレフィックスモードを有効にし、プレフィックスが ENI に割り当てられると、VPC CNI プラグインを 1.9.0 より前のバージョンにダウングレードすることは避けてください。VPC CNI プラグインをダウングレードする場合は、ノードを削除して再作成する必要があります。

新しいノードとノードグループを作成して、使用可能な IP アドレスの量を増やすことを強くお勧めします。また、既存のすべてのノードを cordon および drain して、Pod を安全に退避します。新しいノードで起動した Pod には、ENI に割り当てられたプレフィックスから IP アドレスが割り当てられます。Pod の実行を確認したら、古いノードとノードグループを削除します。

リソース割り当て管理

留意すべきもう 1 つの重要な考慮事項は、Pod リソースの Requests と Limits を設定することです。ベストプラクティスとして、ワークロード特性次第で少なくとも Pod リソースに Requests は常に設定するべきです。これらの値を設定しない場合、プレフィックス割り当てを有効にしてスケジュールできる Pod が増加することを考慮すると、ノードでリソースの競合が発生する可能性があります。プレフィックス割り当てにより、VPC CNI プラグインを使用する場合、IPv4 アドレスはノードあたりの Pod 実行の制限要因ではなくなります。

Pod のセキュリティグループとの比較

ノードレベルのセキュリティグループ構成でワークロード要件を満たすことができる場合は、プレフィックス割り当ては適切なネットワークモードの選択と言えます。プレフィックス割り当てでは、複数の Pod が ENI を共有しており、その ENI に関連付けられたセキュリティグループも共有します。各 Pod に個別のセキュリティグループが必要な要件がある場合は、Pod のセキュリティグループ機能を活用できます。ユースケースと要件に基づいて、ネットワーキングモード/戦略を選択しないといけません。小さいインスタンスタイプでの Pod の起動時間とノード 1 台に配置可能な Pod 数が重要であり、ノードレベルのセキュリティグループで用件を満たせる場合は、プレフィックスの割り当てを使用します。Pod が特定のセキュリティグループのセットを必要とするセキュリティ要件がある場合、SecurityGroupPolicy カスタムリソースを適用すると、Pod にセキュリティグループが適用された専用のブランチネットワークインターフェイスを割り当てます。Pod は、ブランチインターフェイスのプライマリ IP アドレスに接続されています。現在、セカンダリ IP アドレスまたはプレフィックスをブランチインターフェイスに割り当てることはできません。

最大 Pod 数計算スクリプトは、Pod のセキュリティグループとは関連しません。これは、ノード 1 台あたりの最大 Pod 実行数が Kubernetes 拡張リソースによって制限されるためです。Kubernetes 拡張リソースでは、ブランチネットワークインターフェイスの数が拡張リソースとしてアドバタイズされ、SecurityGroupPolicy に一致する Pod はブランチインターフェイスのリソースリクエスト用の webhook で挿入されます。ブランチインターフェイスが必要な Pod がスケジュールされると、別のコンポーネントである VPC リソースコントローラー（EKS コントロールプレーンで実行）が EC2 API を呼び出して、ブランチインターフェイスを作成し、ワーカーノードにアタッチします。インスタンスタイプごとのブランチインターフェイスの最大数は、EKS ドキュメントに記載されています。この動作の詳細については、ローンチブログを参照してください。ブランチネットワークインターフェイスを割り当てた Pod と ENI プレフィックスから IP を割り当てられた Pod は、同じノード上に共存できることに注意してください。

プレフィックス割り当てと Pod のセキュリティグループ、この両方の長所を活かせるオプションは現時点ではありません。考えられるアイデアの 1 つは、コンテナロードマップのこちらの Issue で調査されています。しかし、これはスケジューリングの難しさが問題になっています。

お片付け

余剰なコスト支払いを避けるために、この演習用に作成した Amazon EKS クラスターを削除します。クラスターの削除に加えて、ノードグループも削除します。

eksctl delete cluster --name pd-cluster

結論

AWS コンテナサービスロードマップの Issue 138 と 1557 では、プレフィックス割り当てと Amazon VPC CNI プラグインで可能なさまざまな設定オプションの詳細について問い合わせがありました。この記事では、プレフィックス割り当てモード、VPC CNI プラグインのワークフローのまとめ、インストールとセットアップの選択肢について詳しく説明しました。重要な考慮事項とユースケースのセクションでは、プレフィックス割り当てモードの使用に関するガイダンスを提供しました。

Amazon EKS でプレフィックス割り当てモードを使用して ノード1台に配置可能な Pod 数をより多くする方法を説明しました。さらに、私たちはプレフィックス割り当ての皆様の利用方法から絶えず学んでいます。フラグメンテーションを起こしているサブネットを扱う場合、プレフィックス割り当ての失敗に対処するために VPC CNI プラグインでグレースフルリトライの手法をアップグレードすることを今後計画しています。

Amazon EC2 ネットワークインターフェイスへのプレフィックスの割り当ての詳細については、EC2 ユーザーガイドをご覧ください。また、サブネット CIDR 予約に関する VPC ガイドをご覧ください。プレフィックス割り当てのインストール手順と最近の製品の改善については、Amazon EKS ユーザーガイドをご覧ください。また、VPC CNI プラグインに関するフィードバックを提供や、ロードマップの評価、GitHub でホストされている AWS コンテナロードマップへの新機能提案もぜひよろしくお願いします。

翻訳はソリューションアーキテクト濱が担当しました。原文はこちらです。