翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# IP アドレス使用率の最適化
**ヒント**
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 ](vpc-cni.md)プラグインは、VPC の CIDR (複数可) から各ポッドに IP アドレスを割り当てます。このアプローチは、VPC フローログやその他のモニタリングソリューションなどのツールを使用して、Pod アドレスを完全に可視化します。ワークロードタイプによっては、大量の IP アドレスがポッドによって消費される可能性があります。
AWS ネットワークアーキテクチャを設計するときは、VPC およびノードレベルで Amazon EKS IP 消費量を最適化することが重要です。これにより、IP の枯渇の問題を軽減し、ノードあたりのポッド密度を向上させることができます。
このセクションでは、これらの目標の達成に役立つテクニックについて説明します。
## ノードレベルの IP 消費を最適化する
[プレフィックス委任](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html)は、Amazon Virtual Private Cloud (Amazon VPC) の機能であり、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに IPv4 または IPv6 プレフィックスを割り当てることができます。これにより、ネットワークインターフェイス (ENI) あたりの IP アドレスが増加し、ノードあたりのポッド密度が増加し、コンピューティング効率が向上します。プレフィックスの委任は、カスタムネットワーキングでもサポートされています。
詳細については、[「Linux ノードでのプレフィックス委任](prefix-mode-linux.md)」および[「Windows ノードでのプレフィックス委任](prefix-mode-win.md)」セクションを参照してください。
## IP の枯渇問題を軽減する
クラスターが使用可能なすべての IP アドレスを消費しないように、VPCs とサブネットのサイズを増加を考慮して設定することを強くお勧めします。
[IPv6](ipv6.md) を採用することは、これらの問題を最初から回避する優れた方法です。ただし、スケーラビリティのニーズが初期計画を超え、IPv6 を採用できない組織では、IP アドレスの枯渇に対する VPC 設計の改善が推奨されます。Amazon EKS のお客様で最も一般的に使用される手法は、ルーティング不可能なセカンダリ CIDRs を VPC に追加し、IP アドレスを Pod に割り当てるときにこの追加の IP スペースを使用するように VPC CNI を設定することです。これは一般的に[カスタムネットワーク](custom-networking.md)と呼ばれます。
ノードに割り当てられた IPs のウォームプールを最適化するために使用できる Amazon VPC CNI の変数について説明します。このセクションは、Amazon EKS に組み込まれていないが、IP の枯渇を軽減するのに役立つその他のアーキテクチャパターンで終了します。
### IPv6 を使用する (推奨)
IPv6 の採用は RFC1918 の制限を回避する最も簡単な方法です。ネットワークアーキテクチャを選択するときは、IPv6 を最初のオプションとして採用することを強くお勧めします。IPv6 は IP アドレス領域全体を大幅に拡大し、クラスター管理者は IPv4 の制限を回避するために労力を費やすことなく、アプリケーションの移行とスケーリングに集中できます。
Amazon EKS クラスターは、IPv4 と IPv6 の両方をサポートしています。デフォルトでは、EKS クラスターは IPv4 アドレス空間を使用します。クラスター作成時に IPv6 ベースのアドレス空間を指定すると、IPv6 を使用できます。IPv6 EKS クラスターでは、ポッドとサービスは IPv6 アドレスを受け取りますが**、レガシー IPv4 エンドポイントが IPv6 クラスターで実行されているサービスに接続し、その逆も可能です**。クラスター内のすべてのpod-to-pod通信は、常に IPv6 経由で行われます。VPC (/56) 内では、IPv6 サブネットの IPv6 CIDR ブロックサイズは /64 に固定されます。これにより、2^64 (約 18 50 億) の IPv6 アドレスが提供され、 は EKS でのデプロイをスケーリングできます。
詳細については、[IPv6 クラスターの実行](ipv6.md)」セクションを参照してください。実践的な経験については、「Get hands-on with [ IPv6 workshop」の「Understanding IPv6 on Amazon EKS](https://catalog.workshops.aws/ipv6-on-aws/en-US/lab-6)」セクションを参照してください。 [ IPv6 ](https://catalog.workshops.aws/ipv6-on-aws/en-US)
![\[IPv6 モードの EKS クラスター\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/opt_ipv6.gif)
### IPv4 クラスターの IP 消費を最適化する
このセクションは、レガシーアプリケーションを実行しているお客様、および/または IPv6 に移行する準備ができていないお客様専用です。すべての組織ができるだけ早く IPv6 に移行することをお勧めしますが、IPv4 を使用してコンテナワークロードをスケールするための代替アプローチを検討する必要がある場合もあります。このため、Amazon EKS クラスターで IPv4 (RFC1918) アドレス空間の消費量を最適化するためのアーキテクチャパターンについても説明します。
#### 成長の計画
IP の枯渇に対する第 1 の防御策として、クラスターが使用可能なすべての IP アドレスを消費しないように、IPv4 VPCs とサブネットのサイズを増やすことを強くお勧めします。サブネットに十分な使用可能な IP アドレスがない場合、新しい Pod またはノードを作成することはできません。
VPC とサブネットを構築する前に、必要なワークロードスケールから逆算することをお勧めします。例えば、[eksctl](https://eksctl.io/) (EKS でクラスターを作成および管理するためのシンプルな CLI ツール) を使用してクラスターを構築する場合、/19 サブネットはデフォルトで作成されます。/19 のネットマスクは、8000 を超えるアドレスを割り当てることができるほとんどのワークロードタイプに適しています。
**重要**
VPCs とサブネットのサイズを設定する場合、ロードバランサー、RDS データベース、その他の VPC 内サービスなど、IP アドレスを消費できる要素 (ポッドとノードを除く) が多数存在する可能性があります。
さらに、Amazon EKS は、コントロールプレーンへの通信を可能にするために必要な最大 4 つの Elastic Network Interface (X-ENI) を作成できます (詳細については[、こちら](subnets.md))。クラスターのアップグレード中に、Amazon EKS は新しい X-ENIsを作成し、アップグレードが成功すると古い X-ENI を削除します。このため、EKS クラスターに関連付けられたサブネットには、少なくとも /28 (16 IP アドレス) のネットマスクをお勧めします。
サンプル [EKS Subnet Calculator ](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx)スプレッドシートを使用して、ネットワークの計画を立てることができます。スプレッドシートは、ワークロードと VPC ENI 設定に基づいて IP 使用量を計算します。IP 使用量を IPv4 サブネットと比較して、設定とサブネットサイズがワークロードに十分かどうかを判断します。VPC 内のサブネットで使用可能な IP アドレスが不足している場合は、VPC の元の CIDR ブロックを使用して[新しいサブネットを作成する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#create-subnets)ことをお勧めします。[Amazon EKS がクラスターサブネットとセキュリティグループの変更を許可するようになりました](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-eks-modification-cluster-subnets-security/)。
#### カスタムネットワーキング
RFC1918 IP スペースを使い果たそうとする場合は、[カスタムネットワーキング](custom-networking.md)パターンを使用して、専用の追加サブネット内でポッドをスケジュールすることで、ルーティング可能な IPs を節約できます。カスタムネットワーキングはセカンダリ CIDR 範囲に有効な VPC 範囲を受け入れますが、CG-NAT スペースの CIDRs (/16) を使用することをお勧めします。つまり、RFC1918 範囲よりも企業設定で使用される可能性が低い`100.64.0.0/10``198.19.0.0/16`ためです。
詳細については、[カスタムネットワーキング](custom-networking.md)の専用セクションを参照してください。
![\[カスタムネットワーキング\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/opt_custom-networking.gif)
#### 拡張サブネット検出
拡張サブネット検出は、[Amazon VPC CNI](vpc-cni.md) で検出できるように新しいサブネットにタグを付けることで、IP を使い果たすための効率的なネットワーク設定の代替手段を提供します。拡張サブネット検出を使用すると、現在のワークロードが同じサブネットで実行され続け、Amazon Elastic Kubernetes Service (Amazon EKS) は新しい「使用可能なサブネット (複数可）」で追加のポッドをスケジュールできるようになりました。
クラスターの現在のサブネットで IP アドレスが不足している場合は、次のように Amazon EKS クラスターにサブネットを追加するだけです。
1. 新しい CIDR ブロックを VPC に関連付けます。
1. 新しい CIDR ブロックに新しいサブネットを作成し、「kubernetes.io/role/cni」 =「1」でタグ付けします。
1. Amazon VPC CNI アドオンの「true」への ENABLE\$1SUBNET\$1DISCOVERY 設定を有効にします (バージョン 1.18.0 以降のデフォルト）。
VPC および Amazon EKS クラスターで拡張サブネット検出を有効にすると、次の図に示すように、新しい Elastic Network Interface (ENIs) が Amazon EKS ノードにアタッチされます。
![\[拡張サブネット検出\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/opt_enhanced-subnet-discovery.gif)
詳細については、AWS コンテナブログの[「Amazon VPC CNI が拡張サブネット検出を導入](https://aws.amazon.com/blogs/containers/amazon-vpc-cni-introduces-enhanced-subnet-discovery/)する」を参照してください。
#### IPs ウォームプールを最適化する
デフォルト設定では、VPC CNI は ENI 全体 (および関連する IPs) をウォームプールに保持します。これにより、特に大規模なインスタンスタイプでは、大量の IPs消費される可能性があります。
クラスターサブネットで使用できる IP アドレスの数に制限がある場合は、以下の VPC CNI 設定環境変数を精査します。
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_ENI_TARGET`
ノードで実行する予定の Pod の数に厳密に一致する`MINIMUM_IP_TARGET`ように、 の値を設定できます。これにより、Pod が作成され、CNI は EC2 API を呼び出すことなくウォームプールから IP アドレスを割り当てることができます。
の値の設定が低`WARM_IP_TARGET`すぎると、EC2 API への追加の呼び出しが発生し、リクエストのスロットリングが発生する可能性があることに注意してください。大規模なクラスターでは、リクエストのスロットリングを避けるため`MINIMUM_IP_TARGET`、 とともに を使用します。
これらのオプションを設定するには、`aws-k8s-cni.yaml`マニフェストをダウンロードし、環境変数を設定します。執筆時点で、最新のリリースはこちら[にあります](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/config/master/aws-k8s-cni.yaml)。設定値のバージョンが、インストールされている VPC CNI バージョンと一致していることを確認します。
**警告**
これらの設定は、CNI を更新するとデフォルトにリセットされます。更新する前に、CNI のバックアップを取得してください。設定を確認して、更新が成功した後に再適用する必要があるかどうかを確認します。
既存のアプリケーションのダウンタイムなしで CNI パラメータをその場で調整できますが、スケーラビリティのニーズをサポートする値を選択する必要があります。たとえば、バッチワークロードを使用している場合は、Pod `WARM_ENI_TARGET` スケールのニーズに合わせてデフォルトを更新することをお勧めします。を高い値`WARM_ENI_TARGET`に設定すると、大きなバッチワークロードの実行に必要なウォーム IP プールが常に維持されるため、データ処理の遅延を回避できます。
**警告**
VPC 設計の改善は、IP アドレスの枯渇に対する推奨応答です。IPv6 やセカンダリ CIDRs。これらの値を調整してウォーム IPs の数を最小限に抑えることは、他のオプションを除外した後の一時的な解決策である必要があります。これらの値を誤って設定すると、クラスターオペレーションが妨げられる可能性があります。本番稼働用システムに変更を加える前に、[このページ](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)の考慮事項を確認してください。
#### IP アドレスインベントリのモニタリング
上記のソリューションに加えて、IP 使用率を可視化することも重要です。[CNI メトリクスヘルパー](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md)を使用して、サブネットの IP アドレスインベントリをモニタリングできます。使用可能なメトリクスには、次のようなものがあります。
+ クラスターがサポートできる ENIs の最大数
+ 既に割り当てられている ENIsの数
+ Pod に現在割り当てられている IP アドレスの数
+ 使用可能な IP アドレスの合計数と最大数
サブネットの IP アドレスが不足している場合に通知を受け取るように [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)を設定することもできます。
**警告**
VPC CNI の `DISABLE_METRICS`変数が false に設定されていることを確認します。
#### その他の考慮事項
IP の枯渇に役立つ Amazon EKS には組み込まれていない他のアーキテクチャパターンがあります。例えば、[VPCs 間の通信を最適化](subnets.md#cross-vpcs)したり[、複数のアカウント間で VPC を共有](subnets.md#subnets-multiple-accounts)して IPv4 アドレスの割り当てを制限したりできます。
これらのパターンの詳細については、以下を参照してください。
+ [ハイパースケール Amazon VPC ネットワークの設計](https://aws.amazon.com/blogs/networking-and-content-delivery/designing-hyperscale-amazon-vpc-networks/)
+ [Amazon VPC Lattice との安全なマルチアカウントマルチ VPC 接続](https://aws.amazon.com/blogs/networking-and-content-delivery/build-secure-multi-account-multi-vpc-connectivity-for-your-applications-with-amazon-vpc-lattice/)を構築します。