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

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

CNI カスタムネットワーク

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

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

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

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

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

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

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

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

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

  2. セカンダリ CIDR ブロックを使用して、アベイラビリティーゾーン ごとに VPC にサブネットを作成します。カスタムサブネットは、ノードが起動されるサブネットとは異なる VPC CIDR ブロックからのサブネットであることが必要です。詳細については、https://docs.aws.amazon.com/vpc/latest/userguide/;working-with-vpcs.html#AddaSubnet の「VPC でのサブネットの作成Amazon VPC ユーザーガイド」を参照してください。

  3. AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFGtrue 環境変数を aws-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.7.5
  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 の一意の値を持つ次の内容が含まれている必要があります。 サブネットの name と一致する アベイラビリティーゾーン の値を使用することを強くお勧めします。これにより、マルチ AZ Auto Scaling グループのデプロイが簡単になるためです (以下のステップ 6c を参照)。

      この例では、us-west-2a.yaml という名前のファイルが作成されます。、<example values>、namesubnet を独自の値に置き換えます。securityGroupsこの例では、ベストプラクティスに従い、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

      各インスタンスタイプのネットワークインターフェイスの最大数の詳細については、https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI の「各インスタンスタイプのネットワークインターフェイスごとの 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 ラベルで登録されている新しいノードでのみ使用されます。