CNI カスタムネットワーク - Amazon EKS

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

CNI カスタムネットワーク

デフォルトでは、新しいネットワークインターフェイスがポッドに割り当てられると、 はノードのプライマリネットワークインターフェイスのセキュリティグループとサブネットipamDを使用します。ポッドが、コントロールプレーンセキュリティグループと同じ VPC 内にある別のセキュリティグループまたはサブネットを使用するようにできます。以下に例を示します。

  • サブネットの使用できる IP アドレスの数は限られています。これにより、クラスター内に作成できるポッドの数が制限される場合があります。ポッドに別のサブネットを使用することで、使用可能な IP アドレスの数を増やすことができます。

  • セキュリティ上の理由から、ポッドはノードのプライマリネットワークインターフェイスとは異なるセキュリティグループまたはサブネットを使用する必要があります。

  • ノードはパブリックサブネットで設定され、NAT ゲートウェイを使用してポッドをプライベートサブネットに配置します。詳細については、を参照してください 外部ソースネットワークアドレス変換 (SNAT)

注記
  • カスタムネットワーキングは、セルフマネージド型ノードグループ、またはカスタム AMI を使用する起動テンプレートで作成されたマネージド型ノードグループに対して設定できます。このトピックの手順では、CNI Plug-in for Kubernetes バージョン 1.4.0 以降が必要です。Amazon VPCCNI のバージョンを確認して必要に応じて更新するには、「Amazon VPC CNI Plugin for Kubernetes のアップグレード」を参照してください。

  • カスタムネットワークを有効にすると、使用可能なネットワークインターフェイス (およびポッド用に使用可能なすべての IP アドレス) が、それを使用する各ノードから効率的に削除されます。カスタムネットワークが有効になると、ノードのプライマリネットワークインターフェイスはポッドの配置には使用されません。

  • このトピックの手順では、CNI プラグインに、インスタンスのプライマリネットワークインターフェイスに関連付けられているのとは異なるセキュリティグループをセカンダリネットワークインターフェイスに関連付けるように指示します。セカンダリネットワークインターフェイスを使用するすべてのポッドは、セカンダリネットワークインターフェイスの使用を共有し、すべてのポッドは同じセキュリティグループを使用します。個別のポッドに異なるセキュリティグループを割り当てる場合は、 ポッドのセキュリティグループ を使用できます。ポッドのセキュリティグループによって、それぞれに固有のセキュリティグループを割り当てることができる追加のネットワークインターフェイスが作成されます。ポッドのセキュリティグループは、カスタムネットワーキングの有無にかかわらず使用できます。

CNI カスタムネットワークを設定するには

  1. セカンダリ CIDR ブロックをクラスターの VPC に関連付けます。詳細については、の「VPC とセカンダリ CIDR ブロックを関連付ける」を参照してくださいIPv4。Amazon VPC ユーザーガイド

  2. セカンダリ CIDR ブロックを使用して、 アベイラビリティーゾーン ごとに VPC にサブネットを作成します。カスタムサブネットは、ノードが起動されたサブネットとは異なる VPC CIDR ブロックからのものである必要があります。詳細については、次のガイドの「VPC でサブネットを作成する」を参照してくださいAmazon VPC ユーザーガイド。

  3. AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG環境変数を に設定しますtrueaws-node。DaemonSet

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  4. 現在インストールされている CNI バージョンを表示します。

    kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

    出力:

    amazon-k8s-cni:1.6.3
  5. バージョン 1.3 以降の CNI がインストールされている場合は、ステップ 6 に進むことができます。クラスター用に新しい ENIConfig カスタムリソースを定義します。

    1. ENIConfig.yaml というファイルを作成して、次の内容を貼り付けます。

      apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: eniconfigs.crd.k8s.amazonaws.com spec: scope: Cluster group: crd.k8s.amazonaws.com version: v1alpha1 names: plural: eniconfigs singular: eniconfig kind: ENIConfig
    2. 次のコマンドを使用して、クラスターにファイルを適用します。

      kubectl apply -f ENIConfig.yaml
  6. ポッドをスケジュールするサブネットごとに ENIConfig カスタムリソースを作成します。

    1. 各ネットワークインターフェイス設定に一意のファイルを作成します。各ファイルには、 の一意の値を持つ次の内容が含まれている必要がありますname。 サブネットと一致する の値を使用することを強くお勧めします。これにより、マルチ AZ Auto Scaling グループのデプロイが簡単になるためです (以下のステップ 6c を参照)。nameアベイラビリティーゾーン

      この例では、us-west-2a.yaml という名前のファイルが作成されます。<example values>、 name 、および subnetsecurityGroupsを独自の値に置き換えます。この例では、ベストプラクティスに従い、name の値を、サブネットが存在する アベイラビリティーゾーン に設定します。ポッドにアタッチする特定のセキュリティグループがない場合、現時点ではその値を空のままにしておくことができます。後で、 でノードのセキュリティグループを指定しますENIConfig。

      apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: <us-west-2a> spec: securityGroups: - <sg-0dff111a1d11c1c11> subnet: <subnet-011b111c1f11fdf11>
      注記

      サブネットとセキュリティグループの組み合わせごとに、独自のカスタムリソースが必要です。同じ アベイラビリティーゾーン に複数のサブネットがある場合は、次のコマンドを使用して、一致する設定名を持つ各サブネットのノードに注釈を付けます。

      kubectl annotate node <node-name>.<region>.compute.internal k8s.amazonaws.com/eniConfig=<subnet1ConfigName>
    2. 以下のコマンドを使用して、作成したカスタムリソースファイルをそれぞれクラスターに適用します。

      kubectl apply -f <us-west-2a>.yaml
    3. (オプション、ただしマルチアベイラビリティーゾーンノードグループには推奨) デフォルトでは、Kubernetes はノードの をアベイラビリティーゾーンラベルに適用します。failure-domain.beta.kubernetes.io/zoneステップ 6a で推奨されているように VPC 内でそれぞれENIConfigに名前を付けた場合は、以下のコマンドを使用して、Kubernetes によってノードの対応する が自動的に適用されるようにできます。アベイラビリティーゾーンENIConfigアベイラビリティーゾーン

      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone
      注記

      ENI_CONFIG_ANNOTATION_DEF 環境変数のキーが k8s.amazonaws.com/eniConfig になっている注釈が、aws-node デーモンセットのコンテナ仕様にないことを確認します。その注釈がある場合は、ENI_CONFIG_LABEL_DEF 値が上書きされるため、削除する必要があります。kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF コマンドを使用して、その変数が設定されているかどうかを確認できます。出力が返されない場合、その変数は設定されていません。

  7. 新しいセルフマネージド型ノードグループを作成します。マネージド型ノードグループの場合は、カスタム AMI を起動テンプレートで使用します

    1. 次の式を使用して、各ノードでスケジュールできるポッドの最大数を決定します。

      maxPods = (number of interfaces - 1) * (max IPv4 addresses per interface - 1) + 2

      たとえば、m5.largeインスタンスタイプは、3 つのネットワークインターフェイスと各インターフェイス用の 10 個のIPv4アドレスをサポートします。次の計算に示すように、式に値を挿入すると、インスタンスは最大 20 のポッドをサポートできます。

      maxPods = (3 - 1) * (10 - 1) + 2 = 20

      各インスタンスタイプのネットワークインターフェイスの最大数の詳細については、 のインスタンスタイプごとに、ネットワークインターフェイスあたりの IP アドレス数を参照してくださいLinux インスタンス用 Amazon EC2 ユーザーガイド。

    2. 新しいセルフマネージド型ノードグループを作成するには、 のセルフマネージド型ノードのステップに従います。セルフマネージド型Amazon Linuxノードの起動AWS CloudFormation テンプレートを開いた後、指示に従って値を入力します。デプロイしたENIConfigリソースで指定したサブネットを指定します。BootstrapArgumentsフィールドに、次の値を入力します。

      --use-max-pods false --kubelet-extra-args '--max-pods=<20>'
  8. ノードグループが作成されたら、サブネット用に作成されたセキュリティグループを記録し、関連する にセキュリティグループを適用しますENIConfig。 次のコマンドENIConfigでそれぞれを編集します<eniconfig-name>。実際の値に置き換えてください。

    kubectl edit eniconfig.crd.k8s.amazonaws.com/<eniconfig-name>

    ステップ 6a および 6c のベストプラクティスに従った場合、 eniconfig-nameはアベイラビリティーゾーン名前に対応します。

    spec セクションは、次のようになります。

    spec: securityGroups: - <sg-0dff222a2d22c2c22> subnet: <subnet-022b222c2f22fdf22>
  9. この手順を完了する前にポッドが配置されているノードがクラスターにある場合は、それらを終了する必要があります。k8s.amazonaws.com/eniConfig新しいカスタムのネットワーキング機能は、ラベルに登録される新しいノードでのみ使用されます。