Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

ネットワーキングのベストプラクティス - Amazon EKS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ネットワーキングのベストプラクティス

クラスターとアプリケーションを効率的に運用するには、Kubernetes ネットワークを理解することが重要です。ポッドネットワーキングはクラスターネットワーキングとも呼ばれ、Kubernetes ネットワーキングの中心です。Kubernetes は、クラスターネットワーキング用の Container Network Interface (CNI) プラグインをサポートしています。

Amazon EKS は、Kubernetes Pod ネットワーキングを実装するためにAmazon Virtual Private Cloud (VPC) CNI プラグインを正式にサポートしています。VPC CNI は AWS VPC とのネイティブ統合を提供し、アンダーレイモードで動作します。アンダーレイモードでは、ポッドとホストは同じネットワークレイヤーに配置され、ネットワーク名前空間を共有します。Pod の IP アドレスは、クラスターと VPC の観点から一貫しています。

このガイドでは、Kubernetes クラスターネットワーキングのコンテキストで Amazon VPC Container Network Interface (VPC CNI) を紹介します。VPC CNI は EKS でサポートされているデフォルトのネットワークプラグインであるため、ガイドの焦点です。VPC CNI は、さまざまなユースケースをサポートするように高度に設定できます。このガイドには、さまざまな VPC CNI ユースケース、運用モード、サブコンポーネント、推奨事項に関する専用セクションも含まれています。

Amazon EKS はアップストリーム Kubernetes を実行し、Kubernetes 準拠の認定を受けています。代替 CNI プラグインを使用できますが、このガイドでは代替 CNIs を管理するための推奨事項は提供していません。EKS Alternate CNI ドキュメントで、代替 CNI CNIs を効果的に管理するためのパートナーとリソースのリストを確認してください。

Kubernetes ネットワーキングモデル

Kubernetes は、クラスターネットワークに次の要件を設定します。

  • 同じノードでスケジュールされたポッドは、NAT (ネットワークアドレス変換) を使用せずに他のポッドと通信できる必要があります。

  • 特定のノードで実行されているすべてのシステムデーモン (kubelet などのバックグラウンドプロセス) は、同じノードで実行されている Pod と通信できます。

  • ホストネットワークを使用するポッドは、NAT を使用せずに、他のすべてのノードの他のすべてのポッドに接続できる必要があります。

互換性のあるネットワーク実装に Kubernetes が期待することの詳細については、Kubernetes ネットワークモデルを参照してください。次の図は、Pod ネットワーク名前空間とホストネットワーク名前空間の関係を示しています。

ホストネットワークと 2 つのポッドネットワーク名前空間の図

コンテナネットワーキングインターフェイス (CNI)

Kubernetes は、Kubernetes ネットワークモデルを実装するための CNI 仕様とプラグインをサポートしています。CNI は、仕様 (現行バージョン 1.0.0) と、コンテナ内のネットワークインターフェイスを設定するためのプラグインを記述するためのライブラリと、サポートされている多数のプラグインで構成されます。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の数

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.