翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
IPv6 モードの EKS は、大規模な EKS クラスターでよく現れる IPv4 枯渇の問題を解決します。EKS の IPv6 のサポートは、IPv4 アドレス空間のサイズが限られていることに起因する IPv4 の枯渇問題の解決に焦点を当てています。これは多くのお客様から寄せられる重大な懸念事項であり、Kubernetes IPv4/IPv6 デュアルスタック
IPv6 EKS クラスターでは、ポッドとサービスはレガシー IPv4 エンドポイントとの互換性を維持しながら IPv6 アドレスを受け取ります。 IPv4 これには、外部 IPv4 エンドポイントがクラスター内サービスにアクセスしたり、Pod が外部 IPv4 エンドポイントにアクセスしたりするための機能が含まれます。
Amazon EKS IPv6 サポートは、ネイティブ VPC IPv6 機能を活用します。各 VPC には、IPv4 アドレスプレフィックス (CIDR ブロックサイズは /16 ～ /28) と、Amazon の GUA (グローバルユニキャストアドレス) 内からの一意の /56 IPv6 アドレスプレフィックス (固定) が割り当てられます。VPC 内の各サブネットに /64 アドレスプレフィックスを割り当てることができます。ルートテーブル、ネットワークアクセスコントロールリスト、ピアリング、DNS 解決などの IPv4 機能は、IPv6 対応 VPC でも同じように機能します。次に、VPC はデュアルスタック VPC と呼ばれ、次の図は、EKS/IPV4IPv6IPv6 VPC 基盤パターンを示しています。
IPv6 の世界では、すべてのアドレスがインターネットルーティング可能です。デフォルトでは、VPC はパブリック GUA 範囲から IPv6 CIDR を割り当てます。ただし、2024 年 8
次の図は、EKS/IPv6 クラスター内の Pod IPv6 インターネット出力フローを示しています。
IPv6 サブネットを実装するためのベストプラクティスは、VPC ユーザーガイドに記載されています。
IPv6 EKS クラスターでは、ノードと Pod はパブリック IPv6 アドレスを受け取ります。EKS は、一意のローカル IPv6 ユニキャストアドレス (ULA) に基づいて IPv6 アドレスをサービスに割り当てます。IPv6 クラスターの ULA サービス CIDR は、クラスター作成段階で自動的に割り当てられ、IPv4 とは異なり、指定することはできません。次の図は、EKS/IPv6 ベースのクラスターコントロールプレーンのデータプラン基盤パターンを示しています。
概要
EKS/IPv6 はプレフィックスモード (VPC-CNI プラグイン ENI IP 割り当てモード) でのみサポートされています。プレフィックスモードの詳細については、「」を参照してください。
プレフィックスの割り当ては Nitro ベースの EC2 インスタンスでのみ機能するため、EKS/IPv6 はクラスターデータプレーンが EC2 Nitro ベースのインスタンスを使用する場合にのみサポートされます。
簡単に言うと、IPv6 プレフィックス /80 (ワーカーノードあたり) は最大 10^14 個の IPv6 アドレスを生成するため、制限要因は IPs ではなくポッド密度 (リソース単位) になります。
IPv6 プレフィックスの割り当ては、EKS ワーカーノードブートストラップ時にのみ発生します。この動作は、プライベート IPv4 アドレスをタイムリーに割り当てることを目的とした VPC CNI プラグイン (ipamd) によって生成されたスロットリングされた API コールが原因で、Pod チャーンが高い EKS/IPv4 クラスターが Pod スケジューリングで遅延することがよくあるシナリオを軽減することが知られています。また、VPC-CNI プラグインの高度なつまみが WARM_IP/ENI、MINIMUM_IP
次の図は、IPv6 ワーカーノードの Elastic Network Interface (ENI) を拡大したものです。
すべての EKS ワーカーノードには、対応する DNS エントリとともに IPv4 アドレスと IPv6 アドレスが割り当てられます。特定のワーカーノードでは、デュアルスタックサブネットの単一の IPv4 アドレスのみが消費されます。IPv6 の EKS サポートにより、高度に評価された Egress Only IPv4 モデルを通じて IPv4 エンドポイント (AWS、オンプレミス、インターネット) と通信できます。EKS は、VPC CNI プラグインのセカンダリであるホストローカル CNI プラグインを実装します。これにより、Pod の IPv4 アドレスが割り当ておよび設定されます。CNI プラグインは、169.254.172.0/22 の範囲からポッドのホスト固有のルーティング不可能な IPv4 アドレスを設定します。Pod に割り当てられた IPv4 アドレスは、ワーカーノードに固有であり、ワーカーノードを超えてアドバタイズされません。 169.254.172.0/22 は、大規模なインスタンスタイプをサポートできる最大 1024 個の一意の IPv4 アドレスを提供します。
次の図は、クラスター境界 (非インターネット) 外の IPv4 エンドポイントに接続する IPv6 Pod のフローを示しています。 IPv4
上記の図では、Pod はエンドポイントの DNS ルックアップを実行し、IPv4 の「A」レスポンスを受信すると、Pod のノードのみの一意の IPv4 アドレスは、ソースネットワークアドレス変換 (SNAT) を介して EC2 ワーカーノードにアタッチされたプライマリネットワークインターフェイスのプライベート IPv4 (VPC) アドレスに変換されます。
EKS/IPv6 Pod は、同様のフローが存在するように、パブリック IPv4 アドレスを使用してインターネット経由で IPv4 エンドポイントに接続する必要があります。次の図は、クラスターの境界外の IPv4 エンドポイントに接続する IPv6 Pod のフローを示しています (インターネットのルーティング可能）。 IPv4
上記の図では、Pod はエンドポイントの DNS ルックアップを実行し、IPv4 の「A」レスポンスを受信すると、Pod のノードのみの一意の IPv4 アドレスは、ソースネットワークアドレス変換 (SNAT) を介して EC2 ワーカーノードにアタッチされたプライマリネットワークインターフェイスのプライベート IPv4 (VPC) アドレスに変換されます。その後、Pod IPv4 アドレス (ソース IPv4: EC2 プライマリ IP) は IPv4 NAT ゲートウェイにルーティングされ、EC2 プライマリ IP は有効なインターネットルーティング可能な IPv4 パブリック IP アドレス (NAT ゲートウェイ割り当てパブリック IP) に変換 (SNAT) されます。
ノード間の Pod-to-Pod通信では、常に IPv6 アドレスが使用されます。VPC CNI は、IPv4 接続をブロックしながら IPv6 を処理するように iptables を設定します。 IPv4
Kubernetes サービスは、一意のローカル IPv6 ユニキャストアドレス (ULA) から IPv6 アドレス (ClusterIP) のみを受け取ります。 IPv6
サービスは、AWS ロードバランサーを使用してインターネットに公開されます。ロードバランサーは、パブリック IPv4 アドレスと IPv6 アドレス、a.k.a デュアルスタックロードバランサーを受け取ります。IPv6 クラスター kubernetes サービスにアクセスする IPv64 クライアントの場合、ロードバランサーは IPv4 から IPv6 への変換を行います。
Amazon EKS では、プライベートサブネットでワーカーノードとポッドを実行することをお勧めします。パブリックサブネットにパブリックロードバランサーを作成して、プライベートサブネットにあるノードで実行されている Pod にトラフィックをロードバランシングできます。次の図は、EKS/IPv6 Ingress ベースのサービスにアクセスするインターネット IPv4 ユーザーを示しています。IPv6
注記
上記のパターンでは、AWS ロードバランサーコントローラーの最新バージョン
EKS コントロールプレーンのデータプレーン通信
EKS は、デュアルスタックモード (IPv4/IPv6) でクロスアカウント ENIs (X-ENIs) をプロビジョニングします。kubelet や kube-proxy などの Kubernetes ノードコンポーネントは、デュアルスタックをサポートするように設定されています。Kubelet と kube-proxy は hostNetwork モードで実行され、ノードのプライマリネットワークインターフェイスにアタッチされた IPv4 アドレスと IPv6 アドレスの両方にバインドされます。Kubernetes API サーバーは、X-ENIs を介して Pod とノードコンポーネントと通信しますIPv6 ベースです。ポッドは X-ENIs を介して API サーバーと通信し、ポッドから API サーバーへの通信は常に IPv6 モードを使用します。
レコメンデーション
コンピューティングリソースに基づくスケジュール
1 つの IPv6 プレフィックスは、1 つのノードで多くの Pod を実行するのに十分です。これにより、ノード上のポッドの最大数に対する ENI と IP の制限も効果的に削除されます。IPv6 は max-Pod への直接的な依存関係を削除しますが、m5.large などの小さなインスタンスタイプでプレフィックスアタッチメントを使用する場合、IP アドレスを使い果たす前にインスタンスの CPU リソースとメモリリソースを使い果たす可能性があります。セルフマネージド型ノードグループまたはカスタム AMI ID を持つマネージド型ノードグループを使用している場合は、EKS が推奨する最大 Pod 値を手動で設定する必要があります。
次の式を使用して、IPv6 EKS クラスターのノードにデプロイできる Pod の最大数を決定できます。
((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2
((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)
マネージド型ノードグループは、Pod の最大数を自動的に計算します。リソースの制限によるポッドスケジューリングの失敗を避けるため、ポッドの最大数に対する EKS の推奨値を変更しないでください。
既存のカスタムネットワークの目的を評価する
カスタムネットワーク
EKS/IPv6 クラスターの Fargate Pod
EKS は、Fargate で実行されているポッドの IPv6 をサポートしています。Fargate で実行されているポッドは、VPC CIDR 範囲 (IPv6) からカービングされた IPv4IPv6 アドレスを使用します。 IPv4 簡単に言うと、EKS/Fargate Pods クラスター全体の密度は、使用可能な IPv4 アドレスと IPv6 アドレスに制限されます。将来の成長に備えて、デュアルスタックサブネット/VPC CIDRsのサイズを設定することをお勧めします。基盤となるサブネットに使用可能な IPv4 アドレスが含まれていない場合、IPv6 の使用可能なアドレスに関係なく、新しい Fargate Pod をスケジュールすることはできません。
AWS Load Balancer Controller (LBC) をデプロイする
アップストリームのツリー内 Kubernetes サービスコントローラーは IPv6 をサポートしていません。AWS Load Balancer Controller アドオンの最新バージョン"alb.ingress.kubernetes.io/ip-address-type: dualstack"します。 "alb.ingress.kubernetes.io/target-type: ip"
AWS Network Load Balancer は、デュアルスタック UDP プロトコルアドレスタイプをサポートしていません。低レイテンシー、リアルタイムストリーミング、オンラインゲーム、IoT に対する強力な要件がある場合は、IPv4 クラスターを実行することをお勧めします。UDP サービスのヘルスチェックの管理の詳細については、「UDP トラフィックを Kubernetes にルーティングする方法
