翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # カスタムネットワーキング **ヒント** 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)ワークショップを通じてベストプラクティスをご覧ください。 デフォルトでは、Amazon VPC CNI はプライマリサブネットから選択された IP アドレスをポッドに割り当てます。プライマリサブネットは、プライマリ ENI がアタッチされているサブネット CIDR で、通常はノード/ホストのサブネットです。 サブネット CIDR が小さすぎる場合、CNI は Pod に割り当てるのに十分なセカンダリ IP アドレスを取得できない可能性があります。これは EKS IPv4 クラスターの一般的な課題です。 カスタムネットワークは、この問題の解決策の 1 つです。 カスタムネットワークは、セカンダリ VPC アドレススペース (CIDR) からノードとポッドの IPs を割り当てることで、IP の枯渇の問題に対処します。カスタムネットワークサポートはENIConfig カスタムリソースをサポートします。ENIConfig には、ポッドが属するセキュリティグループ (複数可) とともに、代替サブネット CIDR 範囲 (セカンダリ VPC CIDR から取得) が含まれます。カスタムネットワーキングを有効にすると、VPC CNI は ENIs ENIConfig を作成します。CNI は、ENIConfig CRD で定義された CIDR 範囲から IP アドレスをポッドに割り当てます。 プライマリ ENI はカスタムネットワークでは使用されないため、ノードで実行できる Pod の最大数は少なくなります。ホストネットワークポッドは、プライマリ ENI に割り当てられた IP アドレスを引き続き使用します。さらに、プライマリ ENI はソースネットワーク変換を処理し、Pod トラフィックをノード外にルーティングするために使用されます。 ## 構成例 カスタムネットワーキングはセカンダリ CIDR 範囲の有効な VPC 範囲を受け入れますが、CG-NAT スペースの CIDRs (/16) を使用することをお勧めします。つまり、100.64.0.0/10 または 198.19.0.0/16 は、他の RFC1918 範囲よりも企業設定で使用される可能性が低いためです。VPC で使用できる許可および制限された CIDR ブロックの関連付けの詳細については、VPC ドキュメントの「VPC とサブネットのサイズ設定」セクションの[IPv4 CIDR ブロックの関連付けの制限](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions)」を参照してください。 次の図に示すように、ワーカーノードのプライマリ Elastic Network Interface ([ENI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)) は引き続きプライマリ VPC CIDR 範囲 (この場合は 10.0.0.0/16) を使用しますが、セカンダリ ENIsセカンダリ VPC CIDR 範囲 (この場合は 100.64.0.0/16) を使用します。ここで、ポッドで 100.64.0.0/16 CIDR 範囲を使用するには、カスタムネットワークを使用するように CNI プラグインを設定する必要があります。[ここ](https://docs.aws.amazon.com/eks/latest/userguide/cni-custom-network-tutorial.html)に記載されている手順を実行できます。 ![セカンダリサブネット上のポッドの図](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/cn-image.png) CNI でカスタムネットワーキングを使用する場合は、`AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG`環境変数を に設定します`true`。 ``` kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true ``` の場合`AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true`、CNI は で定義されたサブネットから Pod IP アドレスを割り当てます`ENIConfig`。`ENIConfig` カスタムリソースは、ポッドがスケジュールされるサブネットを定義するために使用されます。 ``` apiVersion : crd.k8s.amazonaws.com/v1alpha1 kind : ENIConfig metadata: name: us-west-2a spec: securityGroups: - sg-0dff111a1d11c1c11 subnet: subnet-011b111c1f11fdf11 ``` `ENIconfig` カスタムリソースを作成するときは、新しいワーカーノードを作成し、既存のノードをドレインする必要があります。既存のワーカーノードとポッドは影響を受けません。 ## 推奨事項 ### 次の場合にカスタムネットワーキングを使用する IPv4 の枯渇に対処していて、まだ IPv6 を使用できない場合は、カスタムネットワークを検討することをお勧めします。Amazon EKS による [RFC6598](https://datatracker.ietf.org/doc/html/rfc6598) スペースのサポートにより、[RFC1918](https://datatracker.ietf.org/doc/html/rfc1918) を超えてポッドをスケーリングし、枯渇の問題に対処できます。ノードの Pod 密度を高めるために、カスタムネットワークでプレフィックス委任を使用することを検討してください。 セキュリティグループの要件が異なる別のネットワークで Pod を実行するセキュリティ要件がある場合は、カスタムネットワーキングを検討してください。カスタムネットワークを有効にすると、ポッドはノードのプライマリネットワークインターフェイスとは異なるサブネットまたはセキュリティグループを ENIConfig で定義して使用します。 カスタムネットワーキングは、複数の EKS クラスターとアプリケーションをデプロイしてオンプレミスのデータセンターサービスを接続するのに最適なオプションです。Amazon Elastic Load Balancing や NAT-GW などのサービスで VPC 内の EKS にアクセスできるプライベートアドレス (RFC1918) の数を増やすことができますが、複数のクラスターで Pod にルーティング不可能な CG-NAT スペースを使用します。[トランジットゲートウェイ](https://aws.amazon.com/transit-gateway/)と共有サービス VPC (高可用性のために複数のアベイラビリティーゾーンにまたがる NAT ゲートウェイを含む) とのカスタムネットワーキングにより、スケーラブルで予測可能なトラフィックフローを提供できます。この[ブログ記事](https://aws.amazon.com/blogs/containers/eks-vpc-routable-ip-address-conservation/)では、カスタムネットワークを使用して EKS Pod をデータセンターネットワークに接続するための最も推奨される方法の 1 つであるアーキテクチャパターンについて説明します。 ### カスタムネットワーキングを避ける #### IPv6 を実装する準備ができました カスタムネットワーキングは IP の枯渇の問題を軽減できますが、追加の運用オーバーヘッドが必要です。現在デュアルスタック (IPv4/IPv6) VPC をデプロイしている場合、またはプランに IPv6 サポートが含まれている場合は、代わりに IPv6 クラスターを実装することをお勧めします。IPv6 EKS クラスターをセットアップし、アプリケーションを移行できます。IPv6 EKS クラスターでは、Kubernetes と Pod の両方が IPv6 アドレスを取得し、IPv4 エンドポイントと IPv6 エンドポイントの両方に出入りできます。[IPv6 EKS クラスターを実行する](ipv6.md)ためのベストプラクティスを確認してください。 #### 枯渇した CG-NAT スペース さらに、現在 CG-NAT スペースの CIDRs を使用しているか、セカンダリ CIDR をクラスター VPC にリンクできない場合は、代替 CNI を使用するなど、他のオプションを検討する必要があります。商用サポートを受けるか、オープンソースの CNI プラグインプロジェクトにパッチをデバッグして送信するための社内知識を持つことを強くお勧めします。詳細については、[「代替 CNI プラグインユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html)」を参照してください。 #### プライベート NAT ゲートウェイを使用する Amazon VPC で[プライベート NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)機能が提供されるようになりました。Amazon のプライベート NAT Gateway を使用すると、プライベートサブネットのインスタンスは、重複する CIDR を持つ他の VPCs やオンプレミスネットワークに接続できます。 CIDRs この[ブログ記事](https://aws.amazon.com/blogs/containers/addressing-ipv4-address-exhaustion-in-amazon-eks-clusters-using-private-nat-gateways/)で説明されている方法を使用して、プライベート NAT ゲートウェイを採用してCIDRsこれは、クライアントが表明する重大な苦情です。カスタムネットワークは、重複する CIDR の問題に単独で対処できず、設定チャレンジに追加されます。 このブログ投稿実装で使用されるネットワークアーキテクチャは、Amazon VPC ドキュメントの[「重複するネットワーク間の通信を有効にする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#private-nat-overlapping-networks)」の推奨事項に従います。このブログ記事で示すように、RFC6598 アドレスと組み合わせてプライベート NAT ゲートウェイの使用を拡張して、顧客のプライベート IP 枯渇の問題を管理することができます。EKS クラスター、ワーカーノードはルーティング不可能な 100.64.0.0/16 VPC セカンダリ CIDR 範囲にデプロイされますが、プライベート NAT ゲートウェイ、NAT ゲートウェイはルーティング可能な RFC1918 CIDR 範囲にデプロイされます。このブログでは、ルーティング不可能な CIDR 範囲が重複する VPCs 間の通信を容易にするために、トランジットゲートウェイを使用して VPCs を接続する方法について説明します。VPC のルーティング不可能なアドレス範囲の EKS リソースが重複するアドレス範囲を持たない他の VPCs と通信する必要があるユースケースでは、VPC ピアリングを使用してそのような VPCs を相互接続できます。この方法は、VPC ピアリング接続を介したアベイラビリティーゾーン内のすべてのデータ転送が無料になったため、潜在的なコスト削減につながる可能性があります。 ![プライベート NAT ゲートウェイを使用したネットワークトラフィックの図](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/cn-image-3.png) #### ノードとポッドの一意のネットワーク セキュリティ上の理由からノードとポッドを特定のネットワークに分離する必要がある場合は、より大きなセカンダリ CIDR ブロック (100.64.0.0/8 など) からサブネットにノードとポッドをデプロイすることをお勧めします。VPC に新しい CIDR をインストールした後、セカンダリ CIDR を使用して別のノードグループをデプロイし、元のノードをドレインして、ポッドを新しいワーカーノードに自動的に再デプロイできます。これを実装する方法の詳細については、この[ブログ](https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/)記事を参照してください。 カスタムネットワークは、次の図に示すセットアップでは使用されません。代わりに、Kubernetes ワーカーノードは、100.64.0.0/10 など、VPC のセカンダリ VPC CIDR 範囲のサブネットにデプロイされます。EKS クラスターの実行は維持できますが (コントロールプレーンは元のサブネットに残ります）、ノードとポッドはセカンダリサブネットに移動されます。これは、VPC で IP が枯渇するリスクを軽減するための、従来とは異なる手法でもあります。ポッドを新しいワーカーノードに再デプロイする前に、古いノードをドレインすることをお勧めします。 ![セカンダリサブネット上のワーカーノードの図](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/cn-image-2.png) ### アベイラビリティーゾーンラベルを使用して設定を自動化する Kubernetes を有効にして、ワーカーノードアベイラビリティーゾーン (AZ) に対応する ENIConfig を自動的に適用できます。 Kubernetes はワーカーノード[http://topology.kubernetes.io/zone](http://topology.kubernetes.io/zone)に タグを自動的に追加します。Amazon EKS では、AZ ごとにセカンダリサブネット (代替 CIDR) が 1 つしかない場合、ENI 設定名としてアベイラビリティーゾーンを使用することをお勧めします。その後、ENI 設定名を検出するために使用されるラベルを に設定できます`topology.kubernetes.io/zone`。タグ`failure-domain.beta.kubernetes.io/zone`は廃止され、タグ に置き換えられることに注意してください`topology.kubernetes.io/zone`。 1. `name` フィールドを VPC のアベイラビリティーゾーンに設定します。 1. 次のコマンドを使用して自動設定を有効にする 1. 次のコマンドを使用して設定ラベルを設定します。 ``` kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true" kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone" ``` アベイラビリティーゾーンごとに複数のセカンダリサブネットがある場合は、特定の を作成する必要があります`ENI_CONFIG_LABEL_DEF`。ノード`ENI_CONFIG_LABEL_DEF`を [http://k8s.amazonaws.com/eniConfig](http://k8s.amazonaws.com/eniConfig)として設定し、 [http://k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1](http://k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1)や などのカスタム eniConfig 名でラベル付けすることを検討してください[http://k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2](http://k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2)。 ### セカンダリネットワークの設定時にポッドを置き換える カスタムネットワークを有効にしても、既存のノードは変更されません。カスタムネットワーキングは破壊的なアクションです。カスタムネットワーキングを有効にした後にクラスター内のすべてのワーカーノードをローリング置換するのではなく、[EKS 入門ガイド](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)の AWS CloudFormation テンプレートを、Lambda 関数を呼び出して環境変数で `aws-node` Daemonset を更新し、ワーカーノードがプロビジョニングされる前にカスタムネットワーキングを有効にするカスタムリソースで更新することをお勧めします。 カスタム CNI ネットワーキング機能に切り替える前に、クラスター内に実行中の Pod を持つノードがある場合は、[ノードをコーディングしてドレイン](https://aws.amazon.com/premiumsupport/knowledge-center/eks-worker-node-actions/)し、Pod を適切にシャットダウンしてからノードを終了する必要があります。ENIConfig ラベルまたは注釈に一致する新しいノードのみがカスタムネットワークを使用するため、これらの新しいノードでスケジュールされた Pod にセカンダリ CIDR の IP を割り当てることができます。 ### ノードあたりの最大ポッド数を計算する ノードのプライマリ ENI は Pod IP アドレスの割り当てに使用されなくなったため、特定の EC2 インスタンスタイプで実行できる Pod の数が減少します。この制限を回避するには、カスタムネットワーキングでプレフィックス割り当てを使用できます。プレフィックスを割り当てると、各セカンダリ IP はセカンダリ ENIs。 カスタムネットワーキングを使用する m5.large インスタンスの Pod の最大数を検討してください。 プレフィックスの割り当てなしで実行できるポッドの最大数は 29 です。 + ` 3 ENIs - 1) * (10 secondary IPs per ENI - 1 + 2 = 20` プレフィックスアタッチメントを有効にすると、ポッドの数は 290 に増加します。 + `(3 ENIs - 1) * ((10 secondary IPs per ENI - 1) * 16 + 2 = 290` ただし、インスタンスの仮想 CPUs の数はかなり少ないため、max-pods を 290 ではなく 110 に設定することをお勧めします。より大きなインスタンスでは、EKS は最大ポッド値を 250 にすることをお勧めします。より小さなインスタンスタイプ (m5.large など) のプレフィックスアタッチメントを使用する場合、インスタンスの CPU リソースとメモリリソースを IP アドレスの前に使い果たす可能性があります。 **注記** CNI プレフィックスが /28 プレフィックスを ENI に割り当てる場合、IP アドレスの連続したブロックである必要があります。プレフィックスの生成元のサブネットが高度に断片化されている場合、プレフィックスアタッチメントが失敗する可能性があります。これを回避するには、クラスター用の新しい専用 VPC を作成するか、サブネットに一連の CIDR をプレフィックスアタッチメント専用に予約します。このトピックの詳細については、[「サブネット CIDR 予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」を参照してください。 ### CG-NAT スペースの既存の使用状況を特定する カスタムネットワークを使用すると、IP の枯渇の問題を緩和できますが、すべての課題を解決することはできません。クラスターにすでに CG-NAT スペースを使用している場合、または単にセカンダリ CIDR をクラスター VPC に関連付ける機能がない場合は、代替 CNI の使用や IPv6 クラスターへの移行など、他のオプションを検討することをお勧めします。