

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

# Linux のプレフィックスモード
<a name="prefix-mode-linux"></a>

**ヒント**  
 Amazon EKS [https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)ワークショップを通じてベストプラクティスをご覧ください。

Amazon VPC CNI は、[Amazon EC2 ネットワークインターフェイス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html)にネットワークプレフィックスを割り当てて、ノードで使用できる IP アドレスの数を増やし、ノードあたりのポッド密度を向上させます。ネットワークインターフェイスに個々のセカンダリ IP アドレスを割り当てる代わりに、Amazon VPC CNI アドオンのバージョン 1.9.0 以降を設定して IPv4 および IPv6 CIDRs を割り当てることができます。

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

プレフィックス割り当てモードでは、インスタンスタイプあたりの Elastic Network Interface の最大数は変わりませんが、個々の IPv4 アドレスをネットワークインターフェイスのスロットに割り当てる代わりに、/28 (16 IP アドレス) の IPv4 アドレスプレフィックスを割り当てるように Amazon VPC CNI を設定できるようになりました。`ENABLE_PREFIX_DELEGATION` が true に設定されている場合、VPC CNI は ENI に割り当てられたプレフィックスから Pod に IP アドレスを割り当てます。[EKS ユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html)に記載されている手順に従って、プレフィックス IP モードを有効にしてください。

![\[2 つのワーカーサブネットの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/pm_image.png)


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

ワーカーノードの初期化中、VPC CNI はプライマリ ENI に 1 つ以上のプレフィックスを割り当てます。CNI は、ウォームプールを維持することで、ポッドの起動を高速化するためのプレフィックスを事前に割り当てます。ウォームプールに保持されるプレフィックスの数は、環境変数を設定することで制御できます。
+  `WARM_PREFIX_TARGET`、現在のニーズを超えて割り当てられるプレフィックスの数。
+  `WARM_IP_TARGET`、現在のニーズを超えて割り当てられる IP アドレスの数。
+  `MINIMUM_IP_TARGET`: いつでも使用できる IP アドレスの最小数。
+  `WARM_IP_TARGET` と `MINIMUM_IP_TARGET` を設定すると、 が上書きされます`WARM_PREFIX_TARGET`。

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

![\[ポッドに IP を割り当てる手順のフローチャート\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/pm_image-2.jpeg)


## 推奨事項
<a name="_recommendations"></a>

### プレフィックスモードを使用する
<a name="_use_prefix_mode_when"></a>

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

下位互換性のために、[最大ポッド](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt)制限はセカンダリ IP モードをサポートするように設定されています。ポッド密度を増やすには、Kubelet に`max-pods`値を指定し、ノードのユーザーデータ`--use-max-pods=false`として を指定します。[max-pod-calculator.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/max-pods-calculator.sh) スクリプトを使用して、特定のインスタンスタイプで EKS が推奨するポッドの最大数を計算することを検討できます。ユーザーデータの例については、EKS [ユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html)を参照してください。

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

プレフィックス割り当てモードは、プライマリ [ENI がポッドに使用されていない CNI カスタムネットワーキング](https://docs.aws.amazon.com/eks/latest/userguide/cni-custom-network.html)のユーザーにとって特に重要です。プレフィックスを割り当てることで、ポッドに使用されるプライマリ ENI がない場合でも、ほぼすべての Nitro インスタンスタイプにより多くの IPs をアタッチできます。

### プレフィックスモードを回避する
<a name="_avoid_prefix_mode_when"></a>

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

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

### 同じノードグループで同様のインスタンスタイプを使用する
<a name="_use_similar_instance_types_in_the_same_node_group"></a>

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

**警告**  
特定のノードグループ内のすべてのノードの最大ポッド数は、ノードグループ内の任意の 1 つのインスタンスタイプの*最小*最大ポッド数によって定義されます。

### IPv4 アドレスを節約`WARM_PREFIX_TARGET`するように を設定する
<a name="_configure_warm_prefix_target_to_conserve_ipv4_addresses"></a>

[のインストールマニフェストの](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/config/v1.9/aws-k8s-cni.yaml#L158)デフォルト値`WARM_PREFIX_TARGET`は 1 です。ほとんどの場合、 の推奨値 1 `WARM_PREFIX_TARGET`は、インスタンスに割り当てられた未使用の IP アドレスを最小限に抑えながら、ポッドの高速起動時間を適切に組み合わせます。

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

### 新しい ENI をアタッチするよりも新しいプレフィックスを割り当てることを優先する
<a name="_prefer_allocating_new_prefixes_over_attaching_a_new_eni"></a>

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

### サブネット予約を使用してサブネットの断片化を回避する (IPv4)
<a name="_use_subnet_reservations_to_avoid_subnet_fragmentation_ipv4"></a>

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

```
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 予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html#work-with-subnet-cidr-reservations)を使用して、サブネット内の IP スペースを予約し、プレフィックスによって排他的に使用することができます。予約を作成すると、VPC CNI プラグインは EC2 APIs を呼び出して、予約済みスペースから自動的に割り当てられるプレフィックスを割り当てます。

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

### VPC CNI をダウングレードしない
<a name="_avoid_downgrading_vpc_cni"></a>

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

### プレフィックス委任への移行中にすべてのノードを置き換える
<a name="_replace_all_nodes_during_the_transition_to_prefix_delegation"></a>

既存のワーカーノードをローリング置換するのではなく、使用可能な IP アドレスの数を増やすために新しいノードグループを作成することを強くお勧めします。既存のすべてのノードを遮断およびドレインして、既存のすべての Pod を安全に削除します。サービスの中断を防ぐために、重要なワークロードの本番稼働用クラスターに [Pod Disruption Budgets](https://kubernetes.io/docs/tasks/run-application/configure-pdb) を実装することをお勧めします。新しいノードのポッドには、ENI に割り当てられたプレフィックスから IP が割り当てられます。Pod が実行されていることを確認したら、古いノードとノードグループを削除できます。マネージド型ノードグループを使用している場合は、ここに記載されている手順に従って[ノードグループを安全に削除](https://docs.aws.amazon.com/eks/latest/userguide/delete-managed-node-group.html)してください。