翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Windows のプレフィックスモード
Amazon EKS では、Windows ホストで実行される各 Pod には、デフォルトで [VPC リソースコントローラー](https://github.com/aws/amazon-vpc-resource-controller-k8s)によってセカンダリ IP アドレスが割り当てられます。この IP アドレスは、ホストのサブネットから割り当てられた VPC ルーティング可能なアドレスです。Linux では、インスタンスにアタッチされた各 ENI には、セカンダリ IP アドレスまたは /28 CIDR (プレフィックス) で入力できる複数のスロットがあります。ただし、Windows ホストは 1 つの ENI とその使用可能なスロットのみをサポートします。セカンダリ IP アドレスのみを使用すると、割り当て可能な IP アドレスが多数ある場合でも、Windows ホストで実行できるポッドの数を実質的に制限できます。
Windows ホストのポッド密度を高めるために、特に小さなインスタンスタイプを使用する場合は、Windows ノードの**プレフィックス委任**を有効にできます。プレフィックス委任を有効にすると、/28 IPv4 プレフィックスがセカンダリ IP アドレスではなく ENI スロットに割り当てられます。プレフィックスの委任を有効にするには、設定マップに `amazon-vpc-cni` `enable-windows-prefix-delegation: "true"`エントリを追加します。これは、Windows サポートを有効にする`enable-windows-ipam: "true"`エントリを設定する必要がある設定マップと同じです。
[EKS ユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html)に記載されている手順に従って、Windows ノードのプレフィックス委任モードを有効にしてください。
![\[2 つのワーカーサブネットの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/pm_windows-1.jpg)
図: セカンダリ IP モードとプレフィックス委任モードの比較
ネットワークインターフェイスに割り当てることができる IP アドレスの最大数は、インスタンスタイプとそのサイズによって異なります。ネットワークインターフェイスに割り当てられた各プレフィックスは、使用可能なスロットを消費します。たとえば、`c5.large`インスタンスにはネットワークインターフェイスあたりの`10`スロット数の制限があります。ネットワークインターフェイスの最初のスロットは常にインターフェイスのプライマリ IP アドレスによって消費され、プレフィックスやセカンダリ IP アドレス用の 9 つのスロットが残ります。これらのスロットにプレフィックスが割り当てられている場合、ノードは (9 \$1 16) 144 IP アドレスをサポートできますが、セカンダリ IP アドレスが割り当てられている場合、サポートできる IP アドレスは 9 つのみです。詳細については、[インスタンスタイプごとのネットワークインターフェイスごとの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)と、[ネットワークインターフェイスへのプレフィックスの割り当て](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html)に関するドキュメントを参照してください。
ワーカーノードの初期化中、VPC リソースコントローラーは IP アドレスのウォームプールを維持することで、ポッドの起動を高速化するためにプライマリ ENI に 1 つ以上のプレフィックスを割り当てます。ウォームプールに保持されるプレフィックスの数は、`amazon-vpc-cni`設定マップで次の設定パラメータを設定することで制御できます。
+ `warm-prefix-target`、現在のニーズを超えて割り当てられるプレフィックスの数。
+ `warm-ip-target`、現在のニーズを超えて割り当てられる IP アドレスの数。
+ `minimum-ip-target`: いつでも使用できる IP アドレスの最小数。
+ `warm-ip-target` および/または`minimum-ip-target`、設定されている場合は が上書きされます`warm-prefix-target`。
ノードでより多くの Pod がスケジュールされると、既存の ENI に追加のプレフィックスがリクエストされます。Pod がノードでスケジュールされている場合、VPC Resource Controller はまずノードの既存のプレフィックスから IPv4 アドレスを割り当てようとします。これが不可能な場合、サブネットに必要な容量がある限り、新しい IPv4 プレフィックスがリクエストされます。
![\[ポッドに IP を割り当てる手順のフローチャート\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/pm_windows-2.jpg)
図: Pod への IPv4 アドレスの割り当て時のワークフロー
## 推奨事項
### プレフィックスの委任を使用する
ワーカーノードで Pod 密度の問題が発生した場合は、プレフィックス委任を使用します。エラーを回避するには、プレフィックスモードに移行する前に、サブネットで /28 プレフィックスの連続するアドレスブロックを調べることをお勧めします。[サブネット予約の詳細については、「サブネット予約を使用してサブネットの断片化 (IPv4) を回避する](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」セクションを参照してください。
デフォルトでは、Windows ノード`max-pods`の は に設定されます`110`。ほとんどのインスタンスタイプでは、これで十分です。この制限を増減する場合は、ユーザーデータのブートストラップコマンドに以下を追加します。
```
-KubeletExtraArgs '--max-pods=example-value'
```
Windows ノードのブートストラップ設定パラメータの詳細については、[こちらの](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html#bootstrap-script-configuration-parameters)ドキュメントを参照してください。
### プレフィックスの委任を避ける
サブネットが非常に断片化されており、/28 プレフィックスを作成するための使用可能な IP アドレスが不十分な場合は、プレフィックスモードを使用しないでください。プレフィックスが生成されるサブネット (分散セカンダリ IP アドレスを持つ頻繁に使用されるサブネット) がフラグメント化されている場合、プレフィックスアタッチメントが失敗することがあります。この問題は、新しいサブネットを作成し、プレフィックスを予約することで回避できます。
### IPv4 アドレスを節約するためにプレフィックス委任のパラメータを設定する
`warm-prefix-target`、`warm-ip-target`、および を使用して、プリスケーリングと動的スケーリングの動作をプレフィックスで微調整`minimum-ip-target`できます。デフォルトでは、次の値が使用されます。
```
warm-ip-target: "1"
minimum-ip-target: "3"
```
これらの設定パラメータを微調整することで、IP アドレスを節約し、IP アドレスの割り当てによる Pod レイテンシーを低減する最適なバランスを実現できます。これらの設定パラメータの詳細については、[こちらの](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md)ドキュメントを参照してください。
### サブネット予約を使用してサブネットの断片化を回避する (IPv4)
EC2 が /28 IPv4 プレフィックスを ENI に割り当てる場合、サブネットからの IP アドレスの連続したブロックである必要があります。プレフィックスが生成されるサブネットがフラグメント化されている場合 (分散セカンダリ IP アドレスを持つ高度に使用されているサブネット）、プレフィックスアタッチメントが失敗し、次のノードイベントが表示されます。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
フラグメント化を回避し、プレフィックスを作成するために十分な連続スペースを確保するには、[VPC サブネット CIDR 予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html#work-with-subnet-cidr-reservations)を使用して、サブネット内の IP スペースを予約し、プレフィックスによって排他的に使用できるようにします。予約を作成すると、リザーブドブロックの IP アドレスは他のリソースに割り当てられません。これにより、VPC Resource Controller はノード ENI への割り当て呼び出し中に使用可能なプレフィックスを取得できます。
新しいサブネットを作成し、プレフィックスのスペースを予約し、そのサブネットで実行されているワーカーノードのプレフィックス割り当てを有効にすることをお勧めします。新しいサブネットが、プレフィックスの委任が有効になっている EKS クラスターで実行されている Pod 専用である場合は、プレフィックスの予約ステップをスキップできます。
### セカンダリ IP モードからプレフィックス委任モードに移行するとき、またはその逆に移行するときにすべてのノードを置き換える
既存のワーカーノードをローリング置換するのではなく、新しいノードグループを作成して使用可能な IP アドレスの数を増やすことを強くお勧めします。
セルフマネージド型ノードグループを使用する場合、移行のステップは次のとおりです。
+ 新しいノードがワークロードに対応できるようにクラスターの容量を増やす
+ Windows のプレフィックス委任機能の有効化/無効化
+ 既存のすべてのノードを遮断してドレインし、既存のすべての Pod を安全に削除します。サービスの中断を防ぐため、重要なワークロードの本番稼働用クラスターに [Pod Disruption Budgets](https://kubernetes.io/docs/tasks/run-application/configure-pdb) を実装することをお勧めします。
+ Pod が実行されていることを確認したら、古いノードとノードグループを削除できます。新しいノードのポッドには、ノード ENI に割り当てられたプレフィックスから IPv4 アドレスが割り当てられます。
マネージド型ノードグループを使用する場合、移行のステップは次のとおりです。
+ Windows のプレフィックス委任機能の有効化/無効化
+ [ここで](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html)説明するステップを使用して、ノードグループを更新します。これは上記と同様のステップを実行しますが、EKS によって管理されます。
**警告**
ノード上のすべての Pod を同じモードで実行する
Windows では、セカンダリ IP モードとプレフィックス委任モードの両方で Pod を同時に実行しないことをお勧めします。このような状況は、セカンダリ IP モードからプレフィックス委任モードに移行するか、実行中の Windows ワークロードでその逆に移行すると発生する可能性があります。
これは実行中のポッドには影響しませんが、ノードの IP アドレス容量に関して不整合が生じる可能性があります。たとえば、セカンダリ IPv4 アドレス用に 14 個のスロットを持つ t3.xlarge ノードがあるとします。10 個の Pod を実行している場合、ENI の 10 個のスロットがセカンダリ IP アドレスによって消費されます。プレフィックスの委任を有効にすると、kube-api サーバーにアドバタイズされる容量は (14 スロット x プレフィックスあたり 16 ip アドレス) 244 ですが、その時点での実際の容量は (残りの 4 スロット x プレフィックスあたり 16 アドレス) 64 になります。アドバタイズされた容量と実際の容量 (残りのスロット) の間にこの不整合があると、割り当て可能な IP アドレスよりも多くの Pod を実行すると、問題が発生する可能性があります。
つまり、上記の移行戦略を使用して、ポッドをセカンダリ IP アドレスからプレフィックスから取得したアドレスに安全に移行できます。モードを切り替えると、Pod は引き続き正常に実行され、次のようになります。
+ セカンダリ IP モードからプレフィックス委任モードに切り替える場合、実行中のポッドに割り当てられたセカンダリ IP アドレスは解放されません。プレフィックスは空きスロットに割り当てられます。ポッドが終了すると、使用していたセカンダリ IP とスロットが解放されます。
+ プレフィックス委任モードからセカンダリ IP モードに切り替えると、範囲内のすべての IPs がポッドに割り当てられなくなると、プレフィックスが解放されます。プレフィックスの IP がポッドに割り当てられている場合、そのプレフィックスはポッドが終了するまで保持されます。
### プレフィックスの委任による問題のデバッグ
[ここで](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/troubleshooting.md)デバッグガイドを使用して、Windows でのプレフィックスの委任で直面している問題を詳しく調べることができます。