翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ネットワーキングのベストプラクティス
クラスターとアプリケーションを効率的に運用するには、Kubernetes ネットワークを理解することが重要です。ポッドネットワーキングはクラスターネットワーキングとも呼ばれ、Kubernetes ネットワーキングの中心です。Kubernetes は、クラスターネットワーキング用の Container Network Interface
Amazon EKS は、Kubernetes Pod ネットワーキングを実装するためにAmazon Virtual Private Cloud (VPC) CNI プラグインを正式にサポートしています。VPC CNI は AWS VPC とのネイティブ統合を提供し、アンダーレイモードで動作します。アンダーレイモードでは、ポッドとホストは同じネットワークレイヤーに配置され、ネットワーク名前空間を共有します。Pod の IP アドレスは、クラスターと VPC の観点から一貫しています。
このガイドでは、Kubernetes クラスターネットワーキングのコンテキストで Amazon VPC Container Network Interface
Amazon EKS はアップストリーム Kubernetes を実行し、Kubernetes 準拠の認定を受けています。代替 CNI プラグインを使用できますが、このガイドでは代替 CNIs を管理するための推奨事項は提供していません。EKS Alternate CNI ドキュメントで、代替 CNI CNIs を効果的に管理するためのパートナーとリソースのリストを確認してください。
Kubernetes ネットワーキングモデル
Kubernetes は、クラスターネットワークに次の要件を設定します。
互換性のあるネットワーク実装に Kubernetes が期待することの詳細については、Kubernetes ネットワークモデル

コンテナネットワーキングインターフェイス (CNI)
Kubernetes は、Kubernetes ネットワークモデルを実装するための CNI 仕様とプラグインをサポートしています。CNI は、仕様
CNI プラグインは、kubelet に--network-plugin=cni
コマンドラインオプションを渡すことで有効になります。Kubelet は --cni-conf-dir
(デフォルトは /etc/cni/net.d) からファイルを読み取り、そのファイルからの CNI 設定を使用して各 Pod のネットワークを設定します。CNI 設定ファイルは CNI 仕様 (最小 v0.4.0) と一致する必要があり、設定で参照される必要な CNI プラグインは --cni-bin-dir
ディレクトリに存在する必要があります (デフォルトは /opt/cni/bin)。ディレクトリに複数の CNI 設定ファイルがある場合、kubelet は名前が最初に来る設定ファイルを辞書順に使用します。
Amazon Virtual Private Cloud (VPC) CNI
AWS が提供する VPC CNI は、EKS クラスターのデフォルトのネットワークアドオンです。EKS クラスターをプロビジョニングすると、VPC CNI アドオンがデフォルトでインストールされます。VPC CNI は Kubernetes ワーカーノードで実行されます。VPC CNI アドオンは、CNI バイナリと IP アドレス管理 (ipamd) プラグインで構成されます。CNI は VPC ネットワークから Pod に IP アドレスを割り当てます。ipamd は、各 Kubernetes ノードへの AWS Elastic Networking Interface (ENIs) を管理し、IPsのウォームプールを維持します。VPC CNI には、ポッドの起動時間を短縮するための ENIsと IP アドレスを事前に割り当てるための設定オプションが用意されています。推奨されるプラグイン管理のベストプラクティスについては、「Amazon VPC CNI」を参照してください。
Amazon EKS では、クラスターの作成時に少なくとも 2 つのアベイラビリティーゾーンにサブネットを指定することをお勧めします。Amazon VPC CNI は、ノードサブネットから Pod に IP アドレスを割り当てます。サブネットで使用可能な IP アドレスを確認することを強くお勧めします。EKS クラスターをデプロイする前に、VPC とサブネットの推奨事項を検討してください。
Amazon VPC CNI は、ノードのプライマリ ENIs にアタッチされたサブネットから ENI とセカンダリ IP アドレスのウォームプールを割り当てます。この VPC CNI モードはセカンダリ IP モードと呼ばれます。IP アドレスの数、つまり Pod の数 (Pod 密度) は、インスタンスタイプで定義されている ENIs の数と ENI あたりの IP アドレス (制限) によって定義されます。セカンダリモードはデフォルトであり、インスタンスタイプが小さい小さなクラスターに適しています。ポッド密度の問題が発生した場合は、プレフィックスモードの使用を検討してください。ENIs にプレフィックスを割り当てることで、ポッドのノードで使用可能な IP アドレスを増やすこともできます。
Amazon VPC CNI は AWS VPC とネイティブに統合され、ユーザーは既存の AWS VPC ネットワークとセキュリティのベストプラクティスを適用して Kubernetes クラスターを構築できます。これには、VPC フローログ、VPC ルーティングポリシー、セキュリティグループを使用してネットワークトラフィックを分離する機能が含まれます。デフォルトでは、Amazon VPC CNI はノード上のプライマリ ENI に関連付けられたセキュリティグループを Pod に適用します。Pod に異なるネットワークルールを割り当てる場合は、Pod のセキュリティグループを有効にすることを検討してください。
デフォルトでは、VPC CNI はノードのプライマリ ENI に割り当てられたサブネットから Pod に IP アドレスを割り当てます。数千のワークロードで大規模なクラスターを実行すると、IPv4 アドレスが不足することがよくあります。AWS VPC では、IPs4 CIDRs ブロックの枯渇を回避するセカンダリ CIDR を割り当てることで、使用可能な IP を拡張できます。 IPv4 AWS VPC CNI では、ポッドに別のサブネット CIDR 範囲を使用できます。VPC CNI のこの機能をカスタムネットワーキングと呼びます。EKS で 100.64.0.0/10
および 198.19.0.0/16
CIDRs (CG-NAT) を使用するには、カスタムネットワークの使用を検討してください。これにより、Pod が VPC から RFC1918 IP アドレスを消費しなくなる環境を効果的に作成できます。
カスタムネットワークは、IPv4 アドレスの枯渇問題に対処するための 1 つのオプションですが、運用上のオーバーヘッドが必要です。この問題を解決するには、カスタムネットワークよりも IPv6 クラスターを使用することをお勧めします。具体的には、VPC で使用可能なすべての IPv6 クラスターに移行することをお勧めします。 IPv4 IPv6 をサポートする組織の計画を評価し、IPv6 への投資がより長期的な価値を持つかどうかを検討します。
EKS の IPv6 のサポートは、IPv4 アドレス空間の制限によって発生する IP 枯渇の問題の解決に焦点を当てています。IPv4 の枯渇に関するお客様の問題に応じて、EKS はデュアルスタックポッドよりも IPv6-onlyポッドを優先しています。つまり、Pod は IPv4 リソースにアクセスできますが、VPC CIDR 範囲から IPv4 アドレスが割り当てられていない可能性があります。VPC CNI は、AWS マネージド VPC IPv6 CIDR ブロックから IPv6 アドレスを Pod に割り当てます。
サブネット計算ツール
このプロジェクトには、サブネット計算ツール Excel ドキュメントWARM_IP_TARGET
や など、さまざまな ENI 設定オプションで指定されたワークロードの IP アドレス消費をシミュレートしますWARM_ENI_TARGET
。このドキュメントには、2 つのシートが含まれています。1 つはウォーム ENI モード用、もう 1 つはウォーム IP モード用です。これらのモードの詳細については、VPC CNI ガイダンスを参照してください。
入力:
-
サブネット CIDR サイズ
-
ウォーム ENI ターゲットまたはウォーム IP ターゲット
-
インスタンスのリスト
-
インスタンスごとにスケジュールされたワークロードポッドのタイプ、数、数
-
出力:
-
ホストされているポッドの合計数
-
消費IPs の数
-
残りのサブネット IPsの数
-
インスタンスレベルの詳細
-
インスタンスあたりのウォーム IPs/ENIsの数
-
インスタンスあたりのアクティブな IPs/ENIsの数
-