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 CIDR ブロックと VPC を関連付ける」を参照してくださいAmazon VPC ユーザーガイド

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

  3. AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG デーモンセットで true 環境変数を aws-node に設定します。

    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の アベイラビリティーゾーン と一致する の値を使用することを強くお勧めします。これにより、マルチアベイラビリティーゾーンAuto Scalingグループのデプロイが簡単になるためです (以下のステップ 6c を参照)。

      この例では、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>
      • VPC に有効なセキュリティグループを指定しない場合、VPC のデフォルトのセキュリティグループはセカンダリ ENI に割り当てられます。

    2. 以下のコマンドを使用して、作成したカスタムリソースファイルをそれぞれクラスターに適用します。

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

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

      k8s.amazonaws.com/eniConfig 環境変数のキーが ENI_CONFIG_ANNOTATION_DEF になっている注釈が、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ノードの起動、新しいセルフマネージド型ノードグループを作成します。デプロイしたENIConfigリソースで指定したサブネットを指定しないでください。AWS CloudFormation テンプレートを開いた後、指示に従って値を入力します。[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. カスタム CNI ネットワーキング機能に切り替える前に、実行中の Pod があるクラスターにノードがある場合は、ノードを切り離して、Pod を適切にシャットダウンしてからノードを終了する必要があります。k8s.amazonaws.com/eniConfig ラベルに登録されている新しいノードのみが、カスタムネットワーキング機能を使用します。