Linux のプレフィックスモード - Amazon EKS
レコメンデーション

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Linux のプレフィックスモード

Amazon は、ノードで使用できる IP アドレスの数を増やし、ノードあたりのポッド密度を高めるために、Amazon EC2ネットワークインターフェイスにネットワークプレフィックスをVPCCNI割り当てます。個々のセカンダリ IP アドレスをネットワークインターフェイスに割り当てるIPv6CIDRs代わりに、Amazon VPCCNIアドオンのバージョン 1.9.0 以降を IPv4および に割り当てるように設定できます。

プレフィックスモードはIPv6クラスターでデフォルトで有効になっており、サポートされている唯一のオプションです。は、 のスロットに /80 IPv6プレフィックスをVPCCNI割り当てますENI。詳細については、IPv6このガイドの セクションを参照してください。

プレフィックス割り当てモードでは、インスタンスタイプあたりのエラスティックネットワークインターフェイスの最大数は変わりませんが、個々のIPv4アドレスVPCCNIをネットワークインターフェイスのスロットに割り当てる代わりに、/28 (16 IP アドレス) IPv4 アドレスプレフィックスを割り当てるように Amazon を設定できるようになりました。ENABLE_PREFIX_DELEGATION を true に設定すると、 に割り当てられたプレフィックスから IP アドレスが Pod にVPCCNI割り当てられますENI。EKS ユーザーガイドに記載されている手順に従って、プレフィックス IP モードを有効にしてください。

2 つのワーカーサブネットの図

ネットワークインターフェイスに割り当てることができる IP アドレスの数は、インスタンスタイプによって異なります。ネットワークインターフェイスに割り当てる各プレフィクスが、1 つの IP アドレスとしてカウントされます。例えば、c5.largeインスタンスにはネットワークインターフェイスあたりの10IPv4アドレスの制限があります。このインスタンスの各ネットワークインターフェイスにはプライマリIPv4アドレスがあります。ネットワークインターフェイスにセカンダリIPv4アドレスがない場合は、ネットワークインターフェイスに最大 9 つのプレフィックスを割り当てることができます。ネットワークインターフェイスに割り当てる追加のIPv4アドレスごとに、ネットワークインターフェイスにプレフィックスを 1 つ割り当てることができます。インスタンスタイプごとのネットワークインターフェイスごとの IP アドレスと、ネットワークインターフェイスへのプレフィックスの割り当てに関するAWSEC2ドキュメントを確認します。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html

ワーカーノードの初期化中、 は 1 つ以上のプレフィックスをプライマリ にVPCCNI割り当てますENI。は、ウォームプールを維持することでポッドの起動を高速化するためのプレフィックスをCNI事前割り当てます。ウォームプールに保持されるプレフィックスの数は、環境変数を設定することで制御できます。

  • WARM_PREFIX_TARGET、現在のニーズを超えて割り当てられるプレフィックスの数。

  • WARM_IP_TARGET、現在のニーズを超えて割り当てられる IP アドレスの数。

  • MINIMUM_IP_TARGET、いつでも使用できる IP アドレスの最小数。

  • WARM_IP_TARGET および MINIMUM_IP_TARGET を設定すると、 が上書きされますWARM_PREFIX_TARGET。

スケジュールされたポッドが増えると、既存の に追加のプレフィックスがリクエストされますENI。まず、 は既存の に新しいプレフィックスを割り当てVPCCNIようとしますENI。がキャパシティーである場合、 ENIはノードに新しい ENIを割り当てVPCCNIようとします。新しい は、ENI上限 (インスタンスタイプで定義) に達するまでアタッチENIsされます。新しい ENI がアタッチされると、ipamd は WARM_PREFIX_TARGET、、WARM_IP_TARGETおよび MINIMUM_IP_TARGET設定を維持するために必要な 1 つ以上のプレフィックスを割り当てます。

IP をポッドに割り当てる手順のフローチャート

レコメンデーション

プレフィックスモードを使用する

ワーカーノードで Pod 密度の問題が発生した場合は、プレフィックスモードを使用します。VPC CNI エラーを回避するには、プレフィックスモードに移行する前に、サブネットで /28 プレフィックスのアドレスの連続ブロックを調べることをお勧めします。サブネット予約の詳細については、「サブネット予約を使用してサブネットの断片化を回避する (IPv4）」セクションを参照してください。

下位互換性のために、最大ポッド制限はセカンダリ IP モードをサポートするように設定されています。ポッド密度を増やすには、Kubelet にmax-pods値を指定し、ノードのユーザーデータ--use-max-pods=falseとして指定します。max-pod-calculator.sh スクリプトを使用して、特定のインスタンスタイプの EKSの推奨最大ポッド数を計算することを検討できます。ユーザーデータの例については、EKSユーザーガイドを参照してください。

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

プレフィックス割り当てモードは、プライマリがポッドに使用ENIされていないCNIカスタムネットワークのユーザーにとって特に重要です。プレフィックスを割り当てると、ポッドIPsにENIプライマリが使用されていなくても、ほぼすべての Nitro インスタンスタイプにさらに多くの をアタッチできます。

プレフィックスモードを回避する

サブネットが非常にフラグメント化されていて、/28 プレフィックスを作成するための使用可能な IP アドレスが不十分な場合は、プレフィックスモードを使用しないでください。プレフィックスが生成されるサブネット (スキャッターされたセカンダリ IP アドレスを持つ頻繁に使用されるサブネット) がフラグメント化されている場合、プレフィックスアタッチメントが失敗する可能性があります。この問題は、新しいサブネットを作成し、プレフィックスを予約することで回避できます。

プレフィックスモードでは、ワーカーノードに割り当てられたセキュリティグループは Pods によって共有されます。共有コンピューティングリソースでさまざまなネットワークセキュリティ要件を持つアプリケーションを実行してコンプライアンスを達成するためのセキュリティ要件がある場合は、Pods のセキュリティグループの使用を検討してください。

同じノードグループで類似のインスタンスタイプを使用する

ノードグループには、多くのタイプのインスタンスが含まれている場合があります。インスタンスの最大ポッド数が少ない場合、その値はノードグループ内のすべてのノードに適用されます。ノードグループで同様のインスタンスタイプを使用して、ノードの使用を最大化することを検討してください。自動ノードスケーリングに Karpenter API を使用している場合は、プロビジョンャーの要件部分で node.kubernetes.io/instance-type を設定することをお勧めします。

警告

特定のノードグループ内のすべてのノードの最大ポッド数は、ノードグループ内の単一のインスタンスタイプの最小最大ポッド数によって定義されます。

IPv4 アドレスを保存するWARM_PREFIX_TARGETように を設定する

のインストールマニフェストのデフォルト値WARM_PREFIX_TARGETは 1 です。ほとんどの場合、 の推奨値 1 WARM_PREFIX_TARGETは、インスタンスに割り当てられた未使用の IP アドレスを最小限に抑えながら、ポッドの高速起動時間を適切に組み合わせます。

ノードの使用WARM_IP_TARGETとMINIMUM_IP_TARGET設定ごとにIPv4アドレスをさらに保存する必要がある場合は、設定WARM_PREFIX_TARGET時に上書きされます。WARM_IP_TARGET を 16 未満の値に設定することで、 CNIが余分なプレフィックス全体をアタッチしないようにできます。

新しいプレフィックスをアタッチするよりも、新しいプレフィックスを割り当てることを優先する ENI

既存の に追加のプレフィックスを割り当てるのENIは、インスタンスENIに新しい を作成してアタッチするよりも高速なEC2API操作です。プレフィックスを使用すると、IPv4アドレス割り当てが不足する一方でパフォーマンスが向上します。プレフィックスのアタッチは通常 1 秒未満で完了しますが、新しいアタッチには最大 10 秒かかるENI場合があります。ほとんどのユースケースCNIでは、プレフィックスモードで を実行する場合、 はワーカーノードENIごとに 1 つのみ必要です。ノードIPsあたり最大 15 個の未使用を (最悪の場合) 確保できる場合は、新しいプレフィックス割り当てネットワークモードを使用し、それに伴うパフォーマンスと効率の向上を実現することを強くお勧めします。

サブネット予約を使用してサブネットの断片化を回避する (IPv4）

が に /28 IPv4プレフィックスEC2を割り当てる場合ENI、サブネットからの IP アドレスの連続ブロックである必要があります。プレフィックスが生成されるサブネットがフラグメント化されている場合 (セカンダリ IP アドレスが散在している高使用率サブネット）、プレフィックスアタッチメントが失敗する可能性があり、VPCCNIログに次のエラーメッセージが表示されます。

failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: There are not enough free cidr blocks in the specified subnet to satisfy the request.

フラグメント化を回避し、プレフィックスを作成するための十分な連続スペースを確保するために、VPCサブネットCIDR予約を使用して、サブネット内の IP スペースを予約して、プレフィックスが排他的に使用することができます。予約を作成すると、VPCCNIプラグインは EC2 APIs を呼び出して、予約されたスペースから自動的に割り当てられるプレフィックスを割り当てます。

新しいサブネットを作成し、プレフィックス用にスペースを確保し、そのサブネットで実行されているワーカーノードVPCCNIのプレフィックス割り当てを で有効にすることをお勧めします。新しいサブネットが、VPCCNIプレフィックス割り当てが有効になっているEKSクラスターで実行されているポッド専用である場合は、プレフィックス予約ステップをスキップできます。

ダウングレードを避ける VPC CNI

プレフィックスモードは、VPCCNIバージョン 1.9.0 以降で機能します。プレフィックスモードが有効になり、プレフィックスが に割り当てられると、Amazon VPC CNI アドオンを 1.9.0 より前のバージョンにダウングレードすることは避ける必要がありますENIs。をダウングレードする場合は、ノードを削除して再作成する必要がありますVPCCNI。

プレフィックス委任への移行中にすべてのノードを置き換える

既存のワーカーノードをローリング置き換えるのではなく、使用可能な IP アドレスの数を増やすために新しいノードグループを作成することを強くお勧めします。既存のすべてのノードをコードしてドレインし、既存のすべての Pod を安全にエビクトします。サービスの中断を防ぐために、重要なワークロードの本番稼働クラスターに Pod Disruption Budgets を実装することをお勧めします。新しいノードのポッドには、 に割り当てられたプレフィックスから IP が割り当てられますENI。Pods が実行されていることを確認したら、古いノードとノードグループを削除できます。マネージド型ノードグループを使用している場合は、ここに記載されている手順に従ってノードグループ を安全に削除してください。

📝 でこのページを編集する GitHub