カスタムネットワーキング

デフォルトでは、Amazon VPCCNIはプライマリサブネットから選択された IP アドレスを Pods に割り当てます。プライマリサブネットは、プライマリENIがアタッチCIDRされているサブネットで、通常はノード/ホストのサブネットです。

サブネットCIDRが小さすぎる場合、はポッドに割り当てるのに十分なセカンダリ IP アドレスを取得できないCNI可能性があります。これはEKSIPv4クラスターの一般的な課題です。

カスタムネットワークは、この問題の解決策の 1 つです。

カスタムネットワークは、セカンダリVPCアドレススペース () IPsからノードと Pod を割り当てることで、IP の枯渇の問題に対処しますCIDR。カスタムネットワークサポートは、ENIConfigカスタムリソースをサポートします。ENIConfig には、ポッドが属するセキュリティグループ (複数可) とともに、代替サブネットCIDR範囲 (セカンダリ VPC から取得CIDR) が含まれます。カスタムネットワークを有効にすると、はで定義されているサブネットENIsにセカンダリVPCCNIを作成しますENIConfig。は、で定義されたCIDR範囲から IP アドレスをポッドにCNI割り当てますENIConfigCRD。

プライマリENIはカスタムネットワークでは使用されないため、ノードで実行できるポッドの最大数は少なくなります。ホストネットワークポッドは、プライマリに割り当てられた IP アドレスを引き続き使用しますENI。さらに、プライマリENIはソースネットワーク変換を処理し、Pods トラフィックをノードの外部にルーティングするために使用されます。

サンプルの構成

カスタムネットワークではセカンダリVPC範囲に有効なCIDR範囲が受け入れられますが、CG NATスペースから CIDRs (/16) を使用することをお勧めします。つまり、100.64.0.0/10 または 198.19.0.0/16 は、他のRFC1918範囲よりも企業設定で使用される可能性が低いためです。で使用できる許可および制限されたCIDRブロック関連付けの詳細についてはVPC、VPCドキュメントのVPC「」および「サブネットサイズ」セクションのIPv4CIDR「ブロック関連付けの制限」を参照してください。

次の図に示すように、ワーカーノードのプライマリ Elastic Network Interface (ENI) は引き続きプライマリVPCCIDR範囲 (この場合は 10.0.0.0/16) を使用しますが、セカンダリはセカンダリVPCCIDR範囲 (この場合は 100.64.0.0/16) ENIsを使用します。ここで、ポッドに 100.64.0.0/16 CIDRの範囲を使用させるには、カスタムネットワークを使用するようにCNIプラグインを設定する必要があります。https://docs.aws.amazon.com/eks/latest/userguide/cni-custom-network.html「」で説明されている手順を実行できます。

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 でのRFC6598スペースEKSのサポートにより、RFC1918枯渇の問題に対処するだけでなく、ポッドを拡張できます。ノードの Pods 密度を高めるために、カスタムネットワークでプレフィックス委任を使用することを検討してください。

セキュリティグループの要件が異なる別のネットワークで Pod を実行するセキュリティ要件がある場合は、カスタムネットワークを検討できます。カスタムネットワークを有効にすると、ポッドはノードのプライマリネットワークインターフェイスENIConfigとは異なるサブネットまたはセキュリティグループを使用します。

カスタムネットワーキングは、オンプレミスのデータセンターサービスに接続するために複数のEKSクラスターとアプリケーションをデプロイする理想的なオプションです。Amazon Elastic Load Balancing や NAT-GW などのサービスVPCで EKSからアクセス可能なプライベートアドレス (RFC1918) の数を増やすことができますが、複数のクラスターで Pod にルーティング不可能な CG-NAT スペースを使用します。トランジットゲートウェイと共有サービス VPC (高可用性のために複数のアベイラビリティーゾーンにまたがるNATゲートウェイを含む) とのカスタムネットワーキングにより、スケーラブルで予測可能なトラフィックフローを提供できます。このブログ記事では、カスタムネットワークを使用して Pod をデータセンターネットワークに接続する最も推奨される方法の 1 EKS つであるアーキテクチャパターンについて説明します。

カスタムネットワーキングを避ける

実装準備完了 IPv6

カスタムネットワークは IP の枯渇の問題を軽減できますが、追加の運用オーバーヘッドが必要です。現在デュアルスタック (IPv4/IPv6) をデプロイしている場合、VPCまたはプランにIPv6サポートが含まれている場合は、代わりにIPv6クラスターを実装することをお勧めします。IPv6 EKS クラスターをセットアップし、アプリケーションを移行できます。IPv6 EKS クラスターでは、Kubernetes と Pod の両方がIPv6アドレスを取得し、 IPv4 と IPv6 エンドポイントの両方とやり取りできます。IPv6 EKS クラスターを実行するためのベストプラクティスを確認してください。

枯渇した CG-NAT スペース

さらに、現在 CG-NAT スペースCIDRsからを使用している場合や、セカンダリをクラスター CIDRにリンクできない場合はVPC、代替を使用するなど、他のオプションを検討する必要がありますCNI。商用サポートを得るか、オープンソースCNIプラグインプロジェクトにパッチをデバッグして送信するための社内知識を持っていることを強くお勧めします。詳細については、代替CNIプラグインユーザーガイドを参照してください。

プライベートNATゲートウェイを使用する

Amazon はプライベートNATゲートウェイ機能を提供するVPCようになりました。Amazon のプライベートNATゲートウェイを使用すると、プライベートサブネット内のインスタンスは、重複するを使用して他のネットワークVPCsやオンプレミスネットワークに接続できますCIDRs。このブログ記事で説明されている方法を使用して、クライアントによって表明された重大な苦情CIDRsであるの重複によって引き起こされるEKSワークロードの通信問題を克服するためにプライベートNATゲートウェイを採用することを検討してください。カスタムネットワークは、重複するCIDR問題に単独で対処できず、設定上の課題に追加されます。

このブログ記事の実装で使用されるネットワークアーキテクチャは、Amazon VPCドキュメントの重複するネットワーク間の通信を有効にするの推奨事項に従います。このブログ記事で説明されているように、プライベートNATゲートウェイの使用をRFC6598アドレスと組み合わせて拡張して、顧客のプライベート IP の枯渇の問題を管理することができます。EKS クラスター、ワーカーノードはルーティング不可能な 100.64.0.0/16 VPCセカンダリCIDR範囲にデプロイされますが、プライベートNATゲートウェイ、NATゲートウェイはルーティング可能なRFC1918CIDR範囲にデプロイされます。このブログでは、ルーティング不可能なCIDR範囲VPCsが重複する間の通信を容易にVPCsするために、Transit Gateway を使用して接続する方法を説明します。VPCのルーティング不可能なアドレス範囲のEKSリソースが、重複VPCsするアドレス範囲を持たない他のリソースと通信する必要がある場合、お客様はVPCピアリングを使用してそのようなを相互接続できますVPCs。この方法では、VPCピアリング接続を介したアベイラビリティーゾーン内のすべてのデータ転送が無料になったため、コスト削減につながる可能性があります。

ノードとポッドの一意のネットワーク

セキュリティ上の理由からノードとポッドを特定のネットワークに分離する必要がある場合は、より大きなセカンダリCIDRブロック (100.64.0.0/8 など) からサブネットにノードとポッドをデプロイすることをお勧めします。CIDR に新しいをインストールした後VPC、セカンダリを使用して別のノードグループをデプロイCIDRし、元のノードをドレインして、ポッドを新しいワーカーノードに自動的に再デプロイできます。この実装方法の詳細については、このブログ記事を参照してください。

カスタムネットワークは、次の図に示すセットアップでは使用されません。Kubernetes ワーカーノードは、100.64.0.0/10 など、 VPCのセカンダリVPCCIDR範囲のサブネットにデプロイされます。EKS クラスターの実行を継続できます (コントロールプレーンは元のに残りますsubnet/s), but the nodes and Pods will be moved to a secondary subnet/s。これは、での IP の使い果たしのリスクを軽減するための、従来の手法ではありませんが、もう 1 つの手法ですVPC。ポッドを新しいワーカーノードに再デプロイする前に、古いノードをドレインすることをお勧めします。

アベイラビリティーゾーンラベルを使用して設定を自動化する

Kubernetes を有効にして、ワーカーノードのアベイラビリティーゾーン (AZ) ENIConfigに対応するを自動的に適用できます。

Kubernetes は、ワーカーノードtopology.kubernetes.io/zoneにタグを自動的に追加します。Amazon では、AZ ENI ごとにセカンダリサブネットが 1 つしかない場合 (代替 CIDR）、アベイラビリティーゾーンを構成名として使用するEKSことを推奨します。タグfailure-domain.beta.kubernetes.io/zoneは廃止され、タグに置き換えられることに注意してくださいtopology.kubernetes.io/zone。

name フィールドをのアベイラビリティーゾーンに設定しますVPC。
このコマンドで自動設定を有効にします。

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

アベイラビリティーゾーンごとに複数のセカンダリサブネットがある場合は、特定のを作成する必要がありますENI_CONFIG_LABEL_DEF。ノードENI_CONFIG_LABEL_DEFをとして設定k8s.amazonaws.com/eniConfigし、 k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 やなどのカスタム eniConfig 名でノードにラベルを付けることを検討できますk8s.amazonaws.com/eniConfig=us-west-2a-subnet-2。

セカンダリネットワークの設定時にポッドを置き換える

カスタムネットワークを有効にしても、既存のノードは変更されません。カスタムネットワークは破壊的なアクションです。カスタムネットワーキングを有効にした後にクラスター内のすべてのワーカーノードをローリング置換するのではなく、EKS「入門ガイド」のAWS CloudFormation テンプレートを、Lambda 関数を呼び出して環境変数で aws-node Daemonset を更新し、ワーカーノードがプロビジョニングされる前にカスタムネットワーキングを有効にするカスタムリソースで更新することをお勧めします。

カスタムCNIネットワーク機能に切り替える前に、クラスター内に Pods を実行しているノードがある場合は、ノードをコードしてドレインし、ポッドを正常にシャットダウンしてからノードを終了する必要があります。ENIConfig ラベルまたは注釈に一致する新しいノードのみがカスタムネットワークを使用するため、これらの新しいノードでスケジュールされた Pod にセカンダリから IP を割り当てることができますCIDR。

ノードあたりの最大ポッド数を計算する

ノードのプライマリENIは Pod IP アドレスの割り当てに使用されなくなったため、特定のEC2インスタンスタイプで実行できる Pod の数が減少します。この制限を回避するには、カスタムネットワークでプレフィックス割り当てを使用できます。プレフィックスを割り当てると、各セカンダリ IP はセカンダリの /28 プレフィックスに置き換えられますENIs。

カスタムネットワークを使用する m5.large インスタンスの最大ポッド数を検討してください。

プレフィックスの割り当てなしで実行できるポッドの最大数は 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

ただし、インスタンスにはかなり少数の仮想があるため、max-pods を 290 ではなく 110 に設定することをお勧めしますCPUs。より大きなインスタンスでは、は最大ポッド値を 250 にEKSすることをお勧めします。インスタンスタイプが小さいプレフィックスアタッチメント (例: m5.large) を使用する場合、インスタンスCPUとメモリリソースを IP アドレスよりもかなり前に使い果たす可能性があります。

注記

CNI プレフィックスが /28 プレフィックスをに割り当てる場合ENI、IP アドレスの連続ブロックである必要があります。プレフィックスが生成されるサブネットが高度に断片化されている場合、プレフィックスアタッチメントが失敗する可能性があります。これは、クラスターVPC用の新しい専用を作成するか、プレフィックスアタッチメントCIDR専用にのセットをサブネットに予約することで軽減できます。このトピックの詳細については、サブネットCIDR予約を参照してください。

CG-NAT Space の既存の使用状況を特定する

カスタムネットワークを使用すると、IP の使い果たしの問題を軽減できますが、すべての課題を解決することはできません。クラスターに既に CG-NAT スペースを使用している場合、または単にセカンダリをクラスター CIDRに関連付ける機能がない場合はVPC、代替の使用CNIやIPv6クラスターへの移行など、他のオプションを検討することをお勧めします。

📝 でこのページを編集する GitHub

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

IPv6 クラスターの実行

Linux のプレフィックスモード