翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
アプリケーションのモダナイゼーションにより、コンテナ化された環境は急速に拡大しています。つまり、より多くのワーカーノードとポッドがデプロイされています。
Amazon VPC CNI プラグインは、VPC の CIDR (複数可) から各ポッドに IP アドレスを割り当てます。このアプローチは、VPC フローログやその他のモニタリングソリューションなどのツールを使用して、Pod アドレスを完全に可視化します。ワークロードタイプによっては、ポッドによって大量の IP アドレスが消費される可能性があります。
AWS ネットワークアーキテクチャを設計するときは、VPC およびノードレベルで Amazon EKS IP 消費を最適化することが重要です。これにより、IP の枯渇の問題を軽減し、ノードあたりのポッド密度を向上させることができます。
このセクションでは、これらの目標の達成に役立つテクニックについて説明します。
ノードレベルの IP 消費を最適化する
プレフィックス委任は、Amazon Virtual Private Cloud (Amazon VPC) の機能であり、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに IPv4 または IPv6 プレフィックスを割り当てることができます。これにより、ネットワークインターフェイス (ENI) あたりの IP アドレスが増加し、ノードあたりのポッド密度が増加し、コンピューティング効率が向上します。プレフィックスの委任は、カスタムネットワーキングでもサポートされています。
詳細については、「Linux ノードでのプレフィックス委任」セクションと「Windows ノードでのプレフィックス委任」セクションを参照してください。
IP の枯渇を軽減
クラスターが使用可能なすべての IP アドレスを消費しないように、VPCs とサブネットのサイズを増加を考慮して設定することを強くお勧めします。
IPv6 を採用することは、これらの問題を最初から回避する優れた方法です。ただし、スケーラビリティのニーズが初期計画を超え、IPv6 を採用できない組織では、IP アドレスの枯渇に対する VPC 設計の改善が推奨されます。Amazon EKS のお客様に最もよく使用される手法は、ルーティング不可能なセカンダリ CIDRs を VPC に追加し、IP アドレスを Pod に割り当てるときにこの追加の IP スペースを使用するように VPC CNI を設定することです。これは一般的にカスタムネットワークと呼ばれます。
ノードに割り当てられた 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 EKS クラスター」セクションを参照してください。実践的な経験については、「Get hands-on with IPv6 workshop」の「Understanding IPv6 on Amazon EKS
IPv4 クラスターの IP 消費を最適化する
このセクションは、レガシーアプリケーションを実行している、または IPv6 に移行する準備ができていないお客様専用です。すべての組織ができるだけ早く IPv6 に移行することをお勧めしますが、IPv4 を使用してコンテナワークロードをスケールするための代替アプローチを検討する必要がある場合もあります。このため、Amazon EKS クラスターで IPv4 (RFC1918) アドレス空間の消費量を最適化するためのアーキテクチャパターンについても説明します。
成長計画
IP の枯渇に対する第 1 の防御として、クラスターが使用可能なすべての IP アドレスを消費しないように、IPv4 VPCs とサブネットのサイズを増加を念頭に置くことを強くお勧めします。サブネットに十分な使用可能な IP アドレスがない場合、新しい Pod またはノードを作成することはできません。
VPC とサブネットを構築する前に、必要なワークロードスケールから逆算することをお勧めします。例えば、クラスターが eksctl
重要
VPCs とサブネットのサイズを設定する場合、ロードバランサー、RDS データベース、その他の VPC 内サービスなど、IP アドレスを消費できる要素が多数 (ポッドとノードを除く) 存在する可能性があります。
さらに、Amazon EKS は、コントロールプレーンへの通信を可能にするために必要な最大 4 つの Elastic Network Interface (X-ENI) を作成できます (詳細については、こちら）。クラスターのアップグレード中、Amazon EKS は新しい X-ENIs を作成し、アップグレードが成功すると古い X-ENI を削除します。このため、EKS クラスターに関連付けられたサブネットには、少なくとも /28 (16 IP アドレス) のネットマスクを使用することをお勧めします。
サンプル EKS サブネット計算ツール
カスタムネットワーキング
RFC1918 IP スペースを使い果たそうとする場合は、カスタムネットワーキングパターンを使用して、専用の追加サブネット内でポッドをスケジュールすることで、ルーティング可能な IPs を節約できます。カスタムネットワーキングではセカンダリ CIDR 範囲に有効な VPC 範囲を使用できますが、CG-NAT スペースの CIDRs (/16) を使用することをお勧めします。つまり、RFC1918 範囲よりも企業設定で使用される可能性が低い100.64.0.0/10198.19.0.0/16ためです。
詳細については、カスタムネットワーキングの専用セクションを参照してください。
拡張サブネット検出
拡張サブネット検出は、Amazon VPC CNI で検出できるように新しいサブネットにタグを付けることで、IP を使い果たすための効率的なネットワーク設定の代替手段を提供します。拡張サブネット検出を使用すると、現在のワークロードが同じサブネットで実行され続け、Amazon Elastic Kubernetes Service (Amazon EKS) は新しい「使用可能なサブネット (複数可）」で追加のポッドをスケジュールできるようになりました。
クラスターの現在のサブネットで IP アドレスが不足している場合は、次のように Amazon EKS クラスターにサブネットを追加するだけです。
-
新しい CIDR ブロックを VPC に関連付けます。
-
新しい CIDR ブロックに新しいサブネットを作成し、kubernetes.io/role/cni」 =「1」でタグ付けします。
-
Amazon VPC CNI アドオンの「true」への ENABLE_SUBNET_DISCOVERY 設定を有効にします (バージョン 1.18.0 以降のデフォルト）。
VPC および Amazon EKS クラスターで拡張サブネット検出を有効にすると、次の図に示すように、新しい Elastic Network Interface (ENIs) が Amazon EKS ノードにアタッチされます。
詳細については、AWS コンテナブログの「Amazon VPC CNI が拡張サブネット検出を導入
IPs ウォームプールの最適化
デフォルト設定では、VPC CNI は ENI 全体 (および関連する IPs) をウォームプールに保持します。これにより、特に大規模なインスタンスタイプでは、多数の IPs消費される可能性があります。
クラスターサブネットで使用できる IP アドレスの数に制限がある場合は、以下の VPC CNI 設定環境変数を精査します。
-
WARM_IP_TARGET -
MINIMUM_IP_TARGET -
WARM_ENI_TARGET
ノードで実行する予定の Pod の数に厳密に一致するMINIMUM_IP_TARGETように、 の値を設定できます。これにより、ポッドが作成されると、CNI は EC2 API を呼び出すことなくウォームプールから IP アドレスを割り当てることができます。
の値の設定が低WARM_IP_TARGETすぎると、EC2 API への追加の呼び出しが発生し、リクエストのスロットリングが発生する可能性があることに注意してください。大規模なクラスターでは、リクエストのスロットリングを避けるためMINIMUM_IP_TARGETに とともに を使用します。
これらのオプションを設定するには、aws-k8s-cni.yamlマニフェストをダウンロードし、環境変数を設定します。執筆時点では、最新のリリースはこちらにあります
警告
これらの設定は、CNI を更新するとデフォルトにリセットされます。更新する前に、CNI のバックアップを取得してください。設定を確認して、更新が成功した後に再適用する必要があるかどうかを確認します。
既存のアプリケーションのダウンタイムなしで CNI パラメータをその場で調整できますが、スケーラビリティのニーズをサポートする値を選択する必要があります。例えば、バッチワークロードを使用している場合は、WARM_ENI_TARGETポッドスケールのニーズに合わせてデフォルトを更新することをお勧めします。を高い値WARM_ENI_TARGETに設定すると、大規模なバッチワークロードの実行に必要なウォーム IP プールが常に維持されるため、データ処理の遅延を回避できます。
警告
VPC 設計の改善は、IP アドレスの枯渇に対する推奨応答です。IPv6 やセカンダリ CIDRs。これらの値を調整してウォーム IPs の数を最小限に抑えることは、他のオプションを除外した後の一時的な解決策である必要があります。これらの値を誤って設定すると、クラスターオペレーションが妨げられる可能性があります。本稼働システムに変更を加える前に、このページ
IP アドレスインベントリのモニタリング
上記のソリューションに加えて、IP 使用率を可視化することも重要です。CNI メトリクスヘルパー
-
クラスターがサポートできる ENIs の最大数
-
既に割り当てられている ENIsの数
-
Pod に現在割り当てられている IP アドレスの数
-
使用可能な IP アドレスの合計数と最大数
サブネットの IP アドレスが不足している場合に通知を受け取るように CloudWatch アラームを設定することもできます。
警告
VPC CNI の DISABLE_METRICS変数が false に設定されていることを確認します。
その他の考慮事項
IP の枯渇に役立つ、Amazon EKS に固有ではないアーキテクチャパターンが他にもあります。例えば、VPCs 間の通信を最適化したり、複数のアカウント間で VPC を共有して IPv4 アドレスの割り当てを制限したりできます。
これらのパターンの詳細については、以下を参照してください。
