翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ネットワーキングのベストプラクティス **ヒント** 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)ワークショップを通じてベストプラクティスをご覧ください。 クラスターとアプリケーションを効率的に運用するには、Kubernetes ネットワークを理解することが重要です。ポッドネットワークはクラスターネットワークとも呼ばれ、Kubernetes ネットワークの中心です。Kubernetes は、クラスターネットワーキング用の [Container Network Interface](https://github.com/containernetworking/cni) (CNI) プラグインをサポートしています。 Amazon EKS は、Kubernetes Pod ネットワーキングを実装するために[Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) CNI プラグインを正式にサポートしています。VPC CNI は AWS VPC とのネイティブ統合を提供し、アンダーレイモードで動作します。アンダーレイモードでは、ポッドとホストは同じネットワークレイヤーに配置され、ネットワーク名前空間を共有します。Pod の IP アドレスは、クラスターと VPC の観点から一貫しています。 このガイドでは、Kubernetes クラスター[ネットワーキングのコンテキストで Amazon VPC Container Network Interface](https://github.com/aws/amazon-vpc-cni-k8s) (VPC CNI) を紹介します。VPC CNI は EKS でサポートされているデフォルトのネットワークプラグインであるため、ガイドの焦点です。VPC CNI は、さまざまなユースケースをサポートするように高度に設定できます。このガイドには、さまざまな VPC CNI ユースケース、操作モード、サブコンポーネント、推奨事項に関する専用セクションも含まれています。 Amazon EKS はアップストリーム Kubernetes を実行し、Kubernetes 準拠の認定を受けています。代替 CNI プラグインを使用できますが、このガイドでは代替 CNIs を管理するための推奨事項は提供していません。[EKS Alternate CNI ](https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html)ドキュメントで、代替 CNI CNIs を効果的に管理するためのパートナーとリソースのリストを確認してください。 ## Kubernetes ネットワーキングモデル Kubernetes は、クラスターネットワークに次の要件を設定します。 + 同じノードでスケジュールされたポッドは、NAT (ネットワークアドレス変換) を使用せずに他のポッドと通信できる必要があります。 + 特定のノードで実行されているすべてのシステムデーモン ([kubelet](https://kubernetes.io/docs/concepts/overview/components/) などのバックグラウンドプロセス) は、同じノードで実行されている Pod と通信できます。 + [ホストネットワーク](https://docs.docker.com/network/host/)を使用するポッドは、NAT を使用せずに、他のすべてのノードの他のすべてのポッドに接続できる必要があります。 互換性のある[ネットワーク実装に Kubernetes が期待することの詳細については、Kubernetes ネットワークモデル](https://kubernetes.io/docs/concepts/services-networking/#the-kubernetes-network-model)を参照してください。次の図は、Pod ネットワーク名前空間とホストネットワーク名前空間の関係を示しています。 ![\[ホストネットワークと 2 つのポッドネットワーク名前空間の図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/image.png) ## コンテナネットワークインターフェイス (CNI) Kubernetes は、Kubernetes ネットワークモデルを実装するための CNI 仕様とプラグインをサポートしています。CNI は、[仕様](https://github.com/containernetworking/cni/blob/main/SPEC.md) (現行バージョン 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](vpc-cni.md)」を参照してください。 Amazon EKS では、クラスターの作成時に少なくとも 2 つのアベイラビリティーゾーンにサブネットを指定することをお勧めします。Amazon VPC CNI は、ノードサブネットから Pod に IP アドレスを割り当てます。サブネットで使用可能な IP アドレスを確認することを強くお勧めします。EKS クラスターをデプロイする前に[、VPC とサブネット](subnets.md)の推奨事項を検討してください。 Amazon VPC CNI は、ノードのプライマリ ENIs にアタッチされたサブネットから ENI とセカンダリ IP アドレスのウォームプールを割り当てます。この VPC CNI モードは[セカンダリ IP モード](vpc-cni.md)と呼ばれます。IP アドレスの数、つまり Pod の数 (Pod 密度) は、インスタンスタイプで定義されている ENIs の数と ENI あたりの IP アドレス (制限) によって定義されます。セカンダリモードはデフォルトであり、インスタンスタイプが小さい小さなクラスターに適しています。ポッド密度の問題が発生した場合は[、プレフィックスモード](prefix-mode-linux.md)の使用を検討してください。ENIs にプレフィックスを割り当てることで、ポッドのノードで使用可能な IP アドレスを増やすこともできます。 Amazon VPC CNI は AWS VPC とネイティブに統合され、ユーザーは既存の AWS VPC ネットワークとセキュリティのベストプラクティスを適用して Kubernetes クラスターを構築できます。これには、VPC フローログ、VPC ルーティングポリシー、セキュリティグループを使用してネットワークトラフィックを分離する機能が含まれます。デフォルトでは、Amazon VPC CNI はノード上のプライマリ ENI に関連付けられたセキュリティグループを Pod に適用します。[Pod に異なるネットワークルールを割り当てる場合は、Pod のセキュリティグループ](sgpp.md)を有効にすることを検討してください。 デフォルトでは、VPC CNI はノードのプライマリ ENI に割り当てられたサブネットから Pod に IP アドレスを割り当てます。数千のワークロードで大規模なクラスターを実行すると、IPv4 アドレスが不足することがよくあります。AWS VPC では、IPs4 [ CIDRs](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions) ブロックの枯渇を回避するセカンダリ CIDR を割り当てることで、使用可能な IP を拡張できます。 IPv4 AWS VPC CNI では、ポッドに別のサブネット CIDR 範囲を使用できます。VPC CNI のこの機能では、[カスタムネットワーキング](custom-networking.md)と呼ばれます。カスタムネットワークを使用して EKS で `100.64.0.0/10`および `198.19.0.0/16` CIDRs (CG-NAT) を使用することを検討してください。これにより、Pod が VPC から RFC1918 IP アドレスを消費しなくなる環境を効果的に作成できます。 カスタムネットワークは IPv4 アドレスの枯渇問題に対処するための 1 つのオプションですが、運用上のオーバーヘッドが必要です。この問題を解決するには、カスタムネットワークではなく IPv6 クラスターを使用することをお勧めします。具体的には、VPC で使用可能なすべての [IPv6 クラスター](ipv6.md)に移行することをお勧めします。 IPv4 IPv6 をサポートする組織の計画を評価し、IPv6 への投資がより長期的な価値を持つかどうかを検討します。 EKS の IPv6 のサポートは、制限された IPv4 アドレス空間に起因する IP 枯渇の問題の解決に焦点を当てています。IPv4 の枯渇に関するお客様の問題に応じて、EKS はデュアルスタックポッドよりも IPv6-onlyポッドを優先しています。つまり、ポッドは IPv4 リソースにアクセスできますが、VPC CIDR 範囲からの IPv4 アドレスは割り当てられません。VPC CNI は、AWS マネージド VPC IPv6 CIDR ブロックから IPv6 アドレスを Pod に割り当てます。 ## サブネット計算ツール このプロジェクトには、[サブネット計算ツール Excel ドキュメント](https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx)が含まれています。この計算ドキュメントは、 `WARM_IP_TARGET`や など、さまざまな ENI 設定オプションで指定されたワークロードの IP アドレス消費をシミュレートします`WARM_ENI_TARGET`。このドキュメントには、2 つのシートが含まれています。1 つはウォーム ENI モード用、もう 1 つはウォーム IP モード用です。これらのモードの詳細については、[VPC CNI ガイダンス](vpc-cni.md)を参照してください。 入力: + サブネット CIDR サイズ + ウォーム ENI ターゲット*または*ウォーム IP ターゲット + インスタンスのリスト + インスタンスごとにスケジュールされたワークロードポッドのタイプ、数、数 出力: + ホストされているポッドの合計数 + 消費IPs の数 + 残りのサブネット IPsの数 + インスタンスレベルの詳細 + インスタンスあたりのウォーム IPs/ENIsの数 + インスタンスあたりのアクティブな IPs/ENIsの数