**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす
**適用対象**: Amazon EC2 インスタンスを持つ Linux および Windows ノード
**適用対象**: パブリックサブネットおよびプライベートサブネット
各 Amazon EC2 インスタンスではエラスティックネットワークインターフェイス の最大数と、各ネットワークインターフェイスに割り当て可能な IP アドレスの最大数がサポートされています。各ノードにはネットワークインターフェースごとに 1 つの IP アドレスが必要です。その他の使用可能な IP アドレスはすべて `Pods` に割り当てることができます。`Pod` それぞれに固有の IP アドレスが必要です。その結果、使用可能なコンピューティングリソースとメモリリソースはあるが、`Pods` に割り当てる IP アドレスが不足しているために追加の `Pods` に対応できないノードが存在する可能性があります。
個別のセカンダリ IP アドレスではなく、IP プレフィックスをノードに割り当てて、ノードで`Pods`に割り当て可能な IP アドレスの数を増やす方法について説明します。各プレフィックスには複数の IP アドレスが含まれます。IP プレフィックスが割り当てられるようにクラスターを設定しない場合、クラスターは Pod 接続に必要なネットワークインターフェイスと IP アドレスを設定するために Amazon EC2 アプリケーションプログラミングインターフェイス (API) の呼び出しをさらに実行する必要があります。クラスターのサイズが大きくなるにつれて、これらの API コールの頻度が高くなるため、Pod とインスタンスの起動時間が長くなる場合があります。これにより、大規模でスパイク的なワークロードの需要を満たすためにスケーリングの遅延が発生します。また、スケーリング要件を満たすためには追加のクラスターと VPC をプロビジョニングする必要があるため、コストと管理オーバーヘッドも増加します。詳細については「GitHub」の「[Kubernetes スケーラビリティ閾値](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md)」を参照してください。
## Amazon VPC CNI plugin for Kubernetes 機能との互換性
次の機能で IP プレフィックスを使用できます：
+ IPv4 ソースネットワークアドレス変換 - 詳細については「[Pod のアウトバウンドインターネットアクセスを有効にする](external-snat.md)」を参照してください。
+ クラスター、ポッド、サービスへの IPv6 アドレス - 詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
+ Kubernetes ネットワークポリシーを使用したトラフィックの制限 - 詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。
次のリストは適用される Amazon VPC CNI プラグイン設定に関する情報を示しています。各設定の詳細については、GitHub の「[amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md)」を参照してください。
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## 考慮事項
この機能を使用する場合は以下を考慮してください：
+ 各 Amazon EC2 インスタンスタイプでは、Pod の最大数がサポートされています。マネージドノードグループが複数のインスタンスタイプで構成されている場合、クラスターのインスタンスで指定する Pod の最大数の内、最小の値がクラスター内のすべてのノードに適用されます。
+ デフォルトでは1 つのノードで実行できる `Pods` の最大数は 110 ですが、この値は変更できます。数値を変更し、既存のマネージド型ノードグループがある場合、ノードグループの AMI または起動テンプレートを次に更新するときに、新しいノードで変更済みの値が適用されるようになります。
+ IP アドレスの割り当てから IP プレフィックスの割り当てに移行する場合は既存のノードにローリング置換を実行するのではなく、新しいノードグループを作成して使用可能な IP アドレスの数を増やすことをお勧めします。IP アドレスと IP プレフィックスの両方が割り当てられているノードで Pod を実行すると、アドバタイズされた IP アドレスの容量に不一致が生じ、ノード上の将来のワークロードに影響する可能性があります。推奨される移行方法については、「*Amazon EKS Best Practices Guide*」の「[Prefix Delegation mode for Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html)」を参照してください。
+ セキュリティグループのスコープはノードレベル - 詳細については「[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
+ ネットワークインターフェイスに割り当てられた IP プレフィックスはノードあたりの高い Pod 密度をサポートし、最適な起動時間になっています。
+ IP プレフィックスと IP アドレスは標準の Amazon EC2 Elastic ネットワークインターフェイスに関連付けられています。特定のセキュリティグループを必要とする Pod には、ブランチネットワークインターフェイスのプライマリ IP アドレスが割り当てられます。IP アドレスを取得するポッド、または IP プレフィックスからの IP アドレスを、同じノード上のブランチネットワークインターフェイスを取得する Pod と混在させることができます。
+ Linux ノードのみを含むクラスターの場合。
+ ネットワークインターフェイスにプレフィックスを割り当てるようにアドオンを設定すると、クラスター内のすべてのノードグループにあるすべてのノードを削除しない限り、Amazon VPC CNI plugin for Kubernetes アドオンを `1.9.0` (または `1.10.1`) より前のバージョンにダウングレードすることはできません。
+ Pod のセキュリティグループ (`POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` および `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false` に設定) も使用している場合、Pod が VPC の外部のエンドポイントと通信するときに、Pod に割り当てた任意のセキュリティグループではなく、ノードのセキュリティグループが使用されます。
[セキュリティグループ](security-groups-for-pods.md) (`POD_SECURITY_GROUP_ENFORCING_MODE`=`strict` に設定) も使用している場合、`Pods` が VPC の外部のエンドポイントと通信するときに、`Pod’s` セキュリティグループが使用されます。
# Amazon EKS ノードで使用可能な IP アドレスを増やす
個別のセカンダリ IP アドレスではなく、IP プレフィックスをノードに割り当てて、ノードで Pod に割り当て可能な IP アドレスの数を増やす方法について説明します。
## 前提条件
+ 既存のクラスターが必要です。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
+ Amazon EKS ノードが配置されているサブネットでは、`/28` 個の連続ブロック (`IPv4` クラスターの場合)、または `/80` 個の Classless Inter-Domain Routing (CIDR) ブロック (`IPv6` クラスターの場合) が十分な数として必要になります。`IPv6` クラスターに含めることができるのは Linux ノードだけです。IP アドレスがサブネット CIDR 全体に分散している場合、IP プレフィックスを使用すると失敗する可能性があります。次の構成を推奨します。
+ サブネット CIDR 予約を使用すると、予約された範囲内の IP アドレスがまだ使用されている場合でも、解放時に IP アドレスが再割り当てされません。これにより、セグメンテーションなしでプレフィックスを割り当てることができます。
+ IP プレフィックスが割り当てられているワークロードの実行に特に使用される新しいサブネットを使用してください。IP プレフィックスを割り当てると、Windows と Linux 両方のワークロードを同じサブネットで実行できます。
+ ノードに IP プレフィックスを割り当てるには、ノードが AWS Nitro ベースである必要があります。Nitro ベースではないインスタンスでは、引き続き個別のセカンダリ IP アドレスが割り当てられますが、Pod に割り当てることのできる IP アドレスの数は Nitro ベースのインスタンスよりも大幅に少なくなります。
+ **Linux ノードのみのクラスターの場合** – クラスターが `IPv4` ファミリーで設定されている場合は、バージョン `1.9.0` 以降の Amazon VPC CNI plugin for Kubernetes アドオンがインストールされている必要があります。現在のバージョンは、次のコマンドで確認できます。
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
クラスターが `IPv6` ファミリーで設定されている場合は、バージョン `1.10.1` のアドオンがインストールされている必要があります。プラグインバージョンが必要なバージョンよりも古い場合は、更新する必要があります。詳細については、「[Amazon VPC CNI を使用してポッドに IP を割り当てる](managing-vpc-cni.md)」の更新セクションを参照してください。
+ **Windows ノードのみのクラスターの場合**
+ クラスターで Windows サポートを有効にする必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。
## ノードに IP アドレスプレフィックスを割り当てる
ノードに IP アドレスプレフィックスを割り当てるようにクラスターを設定します。ノードのオペレーティングシステムに対応する手順を完了します。
### Linux
1. パラメータを有効にして、Amazon VPC CNI DaemonSet のネットワークインターフェイスにプレフィックスを割り当てます。クラスターをデプロイすると、バージョン `1.10.1` 以降の Amazon VPC CNI plugin for Kubernetes アドオンも同時にデプロイされます。`IPv6` ファミリーを使用してクラスターを作成している場合、この設定はデフォルトで `true` に設定されています。`IPv4` ファミリーを使用してクラスターを作成している場合、この設定はデフォルトで `false` に設定されています。
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**重要**
サブネットに使用可能な IP アドレスがある場合でも、サブネットに使用可能な `/28` 個の連続したブロックがない場合には、Amazon VPC CNI plugin for Kubernetes ログに次のエラーが記述されます。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
これは、サブネット全体に広がる既存のセカンダリ IP アドレスの断片化が原因で発生する可能性があります。このエラーを解決するには、新しいサブネットを作成してそこに Pod を起動するか、Amazon EC2 サブネットの CIDR 予約を使用して、プレフィックス割り当てで使用するサブネット内の領域を予約します。詳細については、Amazon VPC ユーザーガイドの「[サブネット CIDR の予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」を参照してください。
1. 前提条件のリストに記載されたバージョン以降の Amazon VPC CNI plugin for Kubernetes を使用しながら、起動テンプレートなしでマネージドノードグループをデプロイする場合、または AMI ID を指定していない起動テンプレートを使用してデプロイする場合には、このまま次のステップに進みます。マネージド型ノードグループは、Pod の最大数を自動的に計算します。
AMI ID を指定した起動テンプレートを使用して、セルフマネージド型ノードグループまたはマネージド型ノードグループをデプロイする場合は、Amazon EKS でノードの推奨最大 Pod 数を決定する必要があります。「」の指示に従い、ステップ 3 に `--cni-prefix-delegation-enabled` を追加します。後のステップで使用するために、出力に注意してください。
**重要**
マネージド型ノードグループは、`maxPods` の値に最大数を適用します。vCPUs が 30 未満のインスタンスの場合、最大数は 110 で、その他すべてのインスタンスの最大数は 250 です。この最大数は、プレフィックス委任が有効かどうかにかかわらず適用されます。
1. `IPv6` 用に設定されたクラスターを使用している場合は、このまま次のステップに進みます。
以下のオプションの内の 1 つでパラメータを指定します。どのオプションが適切で、どの値を提供するかを決定するには、GitHub の「[WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, and MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md)」を参照してください。
example values は、ゼロより大きい値で置き換えます。
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` または `MINIMUM_IP_TARGET` – この値を設定した場合、`WARM_PREFIX_TARGET` に対し設定されている値はすべて上書きされます。
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. 少なくとも 1 つの Amazon EC2 Nitro Amazon Linux 2023 インスタンスタイプを使用して、次のいずれかのタイプのノードグループを作成します。Nitro インスタンスタイプのリストについては、「Amazon EC2 ユーザーガイド」の「[Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)」を参照してください。この機能は Windows ではサポートされていません。*110* が含まれているオプションの場合は、ステップ 3 の値 (推奨) または独自の値に置き換えてください。
+ **セルフマネージド** –「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」の手順に従い、ノードグループをデプロイします。CloudFormation スタックを作成する前に、テンプレートファイルを開き、次のように `UserData` の `NodeLaunchTemplate` を調整します。
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
`eksctl` を使用してノードグループを作成する場合は、次のコマンドを使用できます。
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **マネージド型** — 次のいずれかのオプションを使用して、ノードグループをデプロイします：
+ **起動テンプレートがない場合、または AMI ID が指定されていない起動テンプレートを使用する場合** –「[クラスターのマネージドノードグループを作成する](create-managed-node-group.md)」の手順を完了します。マネージド型ノードグループは、Amazon EKS で推奨される `max-pods` の値を自動的に計算します。
+ **指定した AMI ID を持つ起動テンプレート** — 起動テンプレートで Amazon EKS 最適化 AMI ID を指定するか、Amazon EKS 最適化 AMI から構築されたカスタム AMI を指定してから、[起動テンプレートを使用してノードグループをデプロイ](launch-templates.md)起動テンプレートでは、次のユーザーデータを指定します。このユーザーデータが `NodeConfig` オブジェクトを渡してノードの `nodeadm` ツールによって読み取られます。`nodeadm` の詳細については、[nodeadm のドキュメント](https://awslabs.github.io/amazon-eks-ami/nodeadm)を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
`eksctl` を使用してノードグループを作成する場合は、次のコマンドを使用できます。
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Amazon EKS 最適化 AMI から構築されていないカスタム AMI を作成した場合は、自分で設定をカスタム作成する必要があります。
**注記**
また、インスタンスとは異なるサブネットの Pod に IP アドレスを割り当てる場合は、このステップで機能を有効化する必要があります。詳細については、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
### Server
1. IP プレフィックスの割り当てを有効にします。
1. 編集する `amazon-vpc-cni` `ConfigMap` を開きます。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. `data` セクションに次の行を追加します。
```
enable-windows-prefix-delegation: "true"
```
1. ファイルを保存し、エディタを閉じます。
1. `ConfigMap` に行が追加されたことを確認します。
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
返された出力が `true` でない場合は、エラーが発生した可能性があります。ステップをもう一度実行してみてください。
**重要**
サブネットに使用可能な IP アドレスがある場合でも、サブネットに使用可能な `/28` 個の連続したブロックがない場合には、Amazon VPC CNI plugin for Kubernetes ログに次のエラーが記述されます。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
これは、サブネット全体に広がる既存のセカンダリ IP アドレスの断片化が原因で発生する可能性があります。このエラーを解決するには、新しいサブネットを作成してそこに Pod を起動するか、Amazon EC2 サブネットの CIDR 予約を使用して、プレフィックス割り当てで使用するサブネット内の領域を予約します。詳細については、Amazon VPC ユーザーガイドの「[サブネット CIDR の予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」を参照してください。
1. (オプション) クラスターの事前スケーリング動作と動的スケーリング動作を制御するための追加設定を指定します。詳細については、「GitHub」の「[ Windows でのプレフィックス委任モードの設定オプション](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md)」を参照してください。
1. 編集する `amazon-vpc-cni` `ConfigMap` を開きます。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. サンプル値を 0 より大きい値に置き換え、必要なエントリを `ConfigMap` の `data` セクションに追加します。`warm-ip-target` または `minimum-ip-target` のいずれかに値を設定した場合、その値は `warm-prefix-target` に設定された値をオーバーライドします。
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. ファイルを保存し、エディタを閉じます。
1. 少なくとも 1 つの Amazon EC2 Nitro インスタンスタイプで Windows ノードグループを作成します。Nitro インスタンスタイプのリストについては、「Amazon EC2 ユーザーガイド」の「[Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)」を参照してください。デフォルトでは、1 つのノードにデプロイできる Pod の最大数は 110 です。この数値を増減させる場合は、ブートストラップ設定のユーザーデータに以下を指定します。*max-pods-quantity* を最大ポッド値に置き換えます。
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
マネージド型ノードグループをデプロイする場合は、この設定を起動テンプレートに追加する必要があります。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。Windows ブートストラップスクリプトの設定パラメータの詳細については、「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
## 最大 Pod 数と使用可能な IP アドレスを決定する
1. ノードがデプロイされると、クラスター内のノードの表示が可能になります。
```
kubectl get nodes
```
出力例は次のとおりです。
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. いずれかのノードを記述して、そのノードの `max-pods` 値と使用可能な IP アドレスの数を決定します。*192.168.30.193* を、前の出力で返されたいずれかのノードの名前の `IPv4` アドレスに置き換えます。
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
出力例は次のとおりです。
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
前の出力にある `110` は、*144* 個の IP アドレスが使用可能であるにもかかわらず、Kubernetes がノードにデプロイする Pod の最大数です。