Amazon EC2 ノードで使用可能な IP アドレスの量を増やす - Amazon EKS

Amazon EC2 ノードで使用可能な IP アドレスの量を増やす

各 Amazon EC2 インスタンスでは、Elastic Network Interface の最大数と、各ネットワークインターフェイスに割り当て可能な IP アドレスの最大数がサポートされています。各ノードには、ネットワークインターフェースごとに 1 つの IP アドレスが必要です。その他の使用可能な IP アドレスはすべて Pods に割り当てることができます。Pod それぞれに固有の IP アドレスが必要です。その結果、使用可能なコンピューティングリソースとメモリリソースはあるが、Pods に割り当てる IP アドレスが不足しているために追加の Pods に対応できないノードが存在する可能性があります。

このトピックでは、個別のセカンダリ IP アドレスではなく、IP プレフィックスをノードに割り当てて、ノードで Pods に割り当て可能な IP アドレスの数を大幅に増やす方法について説明します。各プレフィックスには複数の IP アドレスが含まれます。IP プレフィックスが割り当てられるようにクラスターを設定しない場合、クラスターは Pod 接続に必要なネットワークインターフェイスと IP アドレスを設定するために Amazon EC2 アプリケーションプログラミングインターフェイス (API) の呼び出しをさらに実行する必要があります。クラスターのサイズが大きくなるにつれて、これらの API コールの頻度が高くなるため、Pod とインスタンスの起動時間が長くなる場合があります。これにより、大規模でスパイク的なワークロードの需要を満たすためにスケーリングの遅延が発生します。また、スケーリング要件を満たすためには、追加のクラスターと VPC をプロビジョニングする必要があるため、コストと管理オーバーヘッドも増加します。詳細については、「GitHub」の「Kubernetes スケーラビリティ閾値」を参照してください。

考慮事項
  • 各 Amazon EC2 インスタンスタイプでは、Pods の最大数がサポートされています。マネージドノードグループが複数のインスタンスタイプで構成されている場合、クラスターのインスタンスで指定する Pods の最大数の内、最小の値がクラスター内のすべてのノードに適用されます。

  • デフォルトでは、1 つのノードで実行できる Pods の最大数は 110 ですが、この値は変更できます。数値を変更し、既存のマネージド型ノードグループがある場合、ノードグループの AMI または起動テンプレートを次に更新するときに、新しいノードで変更済みの値が適用されるようになります。

  • IP アドレスの割り当てから IP プレフィックスの割り当てに移行する場合は、既存のノードにローリング置換を実行するのではなく、新しいノードグループを作成して使用可能な IP アドレスの数を増やすことをお勧めします。IP アドレスと IP プレフィックスの両方が割り当てられているノードで Pods を実行すると、アドバタイズされた IP アドレスの容量に不一致が生じ、ノード上の将来のワークロードに影響する可能性があります。推奨される移行方法については、「Amazon EKS ベストプラクティスガイド」の「セカンダリ IP モードからプレフィックス委任モード、またはその逆への移行中にすべてのノードを置換する」を参照してください。

  • Linux ノードのみを含むクラスターの場合。

    • ネットワークインターフェイスにプレフィックスを割り当てるようにアドオンを設定すると、クラスター内のすべてのノードグループ内のすべてのノードを削除しない限り、Amazon VPC CNI plugin for Kubernetes アドオンを 1.9.0 (あるいは 1.10.1) より前のバージョンにダウングレードすることはできません。

    • Pods のセキュリティグループ (POD_SECURITY_GROUP_ENFORCING_MODE=standard および AWS_VPC_K8S_CNI_EXTERNALSNAT=false に設定) も使用している場合、Pods が VPC の外部のエンドポイントと通信するときに、Pods に割り当てたセキュリティグループではなく、ノードのセキュリティグループが使用されます。

      Pods のセキュリティグループ (POD_SECURITY_GROUP_ENFORCING_MODE=strict に設定) も使用している場合、Pods が VPC の外部のエンドポイントと通信するときに、Pod's セキュリティグループが使用されます。

前提条件
  • 既存のクラスター。デプロイするには、「Amazon EKS クラスターの作成」を参照してください。

  • Amazon EKS ノードが配置されているサブネットでは、/28 個の連続ブロック (IPv4 クラスターの場合)、または /80 個の Classless Inter-Domain Routing (CIDR) ブロック (IPv6 クラスターの場合) が十分な数として必要になります。IPv6 クラスターに含めることができるのは Linux ノードだけです。IP アドレスがサブネット CIDR 全体に分散している場合、IP プレフィックスを使用すると失敗する可能性があります。次のことを推奨します。

    • サブネット CIDR 予約を使用すると、予約された範囲内の IP アドレスがまだ使用されている場合でも、解放時に IP アドレスが再割り当てされません。これにより、セグメンテーションなしでプレフィックスを割り当てることができます。

    • IP プレフィックスが割り当てられているワークロードの実行に特に使用される新しいサブネットを使用してください。IP プレフィックスを割り当てると、Windows と Linux 両方のワークロードを同じサブネットで実行できます。

  • ノードに IP プレフィックスを割り当てるには、ノードが AWS Nitro ベースである必要があります。Nitro ベースではないインスタンスでは、引き続き個別のセカンダリ IP アドレスが割り当てられますが、Pods に割り当てることのできる IP アドレスの数は Nitro-based のインスタンスよりも大幅に少なくなります。

  • Linux ノードのみのクラスターの場合 – クラスターが IPv4 ファミリーで設定されている場合は、バージョン 1.9.0 以降の Amazon VPC CNI plugin for Kubernetes アドオンがインストールされている必要があります。現在のバージョンは、次のコマンドで確認できます。

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

    クラスターが IPv6 ファミリーで設定されている場合は、バージョン 1.10.1 のアドオンがインストールされている必要があります。プラグインバージョンが必要なバージョンよりも古い場合は、更新する必要があります。詳細については、更新された「Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオンの使用」セクションを参照してください。

  • Windows ノードのみのクラスターの場合

    • クラスターとそのプラットフォームバージョンは、次の表のバージョン以降である必要があります。クラスターバージョンをアップグレードするには、「Amazon EKS クラスターの Kubernetes バージョンの更新」を参照してください。クラスターがプラットフォームの最小バージョンでない場合、Amazon EKS がプラットフォームバージョンを更新するまで、ノードに IP プレフィックスを割り当てることはできません。

      Kubernetes バージョン プラットフォームバージョン
      1.27 eks.3
      1.26 eks.4
      1.25 eks.5

      現在の Kubernetes バージョンとプラットフォームバージョンを確認するには、次のコマンドの my-cluster をクラスターの名前に置き換えて、変更したコマンド aws eks describe-cluster --name my-cluster --query 'cluster.{"Kubernetes Version": version, "Platform Version": platformVersion}' を実行します。

    • クラスターで Windows サポートが有効になっています。詳細については、「Amazon EKS クラスター の Windows サポートの有効化」を参照してください。

Amazon EC2 ノードで使用可能な IP アドレスの量を増やす
  1. ノードに IP アドレスプレフィックスを割り当てるようにクラスターを設定します。ノードのオペレーティングシステムに対応するタブで手順を完了します。

    Linux
    1. パラメータを有効にして、Amazon VPC CNI DaemonSet のネットワークインターフェイスにプレフィックスを割り当てます。1.21 以降のクラスターをデプロイすると、バージョン 1.10.1 以降の Amazon VPC CNI plugin for Kubernetes アドオンも同時にデプロイされます。IPv6 ファミリーを使用してクラスターを作成している場合、この設定はデフォルトで true に設定されています。IPv4 ファミリーを使用してクラスターを作成している場合、この設定はデフォルトで false に設定されています。

      kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
      重要

      サブネットに使用可能な IP アドレスがある場合でも、サブネットに使用可能な /28 個の連続したブロックがない場合には、Amazon VPC CNI plugin for Kubernetes ログに次のエラーが記述されます。

      InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

      これは、サブネット全体に広がる既存のセカンダリ IP アドレスの断片化が原因で発生する可能性があります。このエラーを解決するには、新しいサブネットを作成してそこに Pods を起動するか、Amazon EC2 サブネットの CIDR 予約を使用して、プレフィックス割り当てで使用するためのサブネット内の領域を予約します。詳細については、Amazon VPC ユーザーガイドの「サブネット CIDR の予約」を参照してください。

    2. 前提条件のリストに記載されたバージョン以降の Amazon VPC CNI plugin for Kubernetes を使用しながら、起動テンプレートなしでマネージド型ノードグループをデプロイする場合、または AMI ID を指定していない起動テンプレートを使用してデプロイする場合には、このまま次のステップに進みます。マネージド型ノードグループが、Pods の最大数を自動的に計算します。

      AMI ID を指定した起動テンプレートを使用して、セルフマネージド型ノードグループまたはマネージド型ノードグループをデプロイする場合は、Amazon EKS でノードのために推奨される Pods の最大数を特定する必要があります。各 Amazon EC2 インスタンスタイプの Amazon EKS 推奨最大 Pods 数 の指示に従って、--cni-prefix-delegation-enabled をステップ 3に追加します。後のステップで使用するために、出力に注意してください。

      重要

      マネージド型ノードグループは、maxPods の値に最大数を適用します。vCPUs が 30 未満のインスタンスの場合、最大数は 110 で、その他すべてのインスタンスの最大数は 250 です。この最大数は、プレフィックス委任が有効かどうかにかかわらず適用されます。

    3. IPv6 用に設定された 1.21 以降のクラスターを使用している場合は、このまま次のステップに進みます。

      以下のオプションの内の 1 つでパラメータを指定します。どのオプションが適切で、どの値を提供するかを決定するには、GitHub のWARM_PREFIX_TARGETWARM_IP_TARGET、および MINIMUM_IP_TARGET を参照してください。

      example values をゼロより大きい値に置き換えることができます。

      • WARM_PREFIX_TARGET

        kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
      • WARM_IP_TARGET または MINIMUM_IP_TARGET – この値を設定した場合、WARM_PREFIX_TARGET に対し設定されている値はすべて上書きされます。

        kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
        kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
    4. 少なくとも 1 つの Amazon EC2 Nitro Amazon Linux 2 インスタンスタイプを使用して、次のいずれかのタイプのノードグループを作成します。Nitro インスタンスタイプのリストについては、Amazon EC2 Linux インスタンス用ユーザーガイドの「Nitro System 上に構築されたインスタンス」を参照してください。この機能は Windows ではサポートされていません。110 が含まれているオプションの場合は、ステップ 3 の値 (推奨) または独自の値に置き換えてください。

      • セルフマネージドセルフマネージド型の Amazon Linux ノードの起動 の手順に従ってノードグループをデプロイします。BootstrapArguments パラメータに、以下のテキストを指定します。

        --use-max-pods false --kubelet-extra-args '--max-pods=110'

        eksctl を使用してノードグループを作成する場合は、次のコマンドを使用できます。

        eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
      • マネージド型 — 次のいずれかのオプションを使用して、ノードグループをデプロイします。

        • 起動テンプレートがない場合、または AMI ID が指定されていない起動テンプレートを使用する場合 —「マネージド型ノードグループの作成」の手順を完了します。マネージド型ノードグループは、Amazon EKS で推奨される max-pods の値を自動的に計算します。

        • 指定した AMI ID を持つ起動テンプレート — 起動テンプレートで Amazon EKS 最適化 AMI ID を指定するか、Amazon EKS 最適化 AMI から構築されたカスタム AMI を指定してから、起動テンプレートを使用してノードグループをデプロイ起動テンプレートでは、次のユーザーデータを指定します。このユーザーデータは、引数を bootstrap.sh ファイルに渡します。ブートストラップファイルの詳細については、「GitHub」の「bootstrap.sh」を参照してください。

          /etc/eks/bootstrap.sh my-cluster \ --use-max-pods false \ --kubelet-extra-args '--max-pods=110'

          eksctl を使用してノードグループを作成する場合は、次のコマンドを使用できます。

          eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110

          Amazon EKS 最適化 AMI から構築されていないカスタム AMI を作成した場合は、自分で設定をカスタム作成する必要があります。

        注記

        また、インスタンスとは異なるサブネットの Pods に IP アドレスを割り当てる場合は、このステップで機能を有効化する必要があります。詳細については、「ポッド用のカスタムネットワーク」を参照してください。

    Windows
    1. IP プレフィックスの割り当てを有効にします。

      1. 編集する amazon-vpc-cni ConfigMap を開きます。

        kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
      2. data セクションに次の行を追加します。

        enable-windows-prefix-delegation: "true"
      3. ファイルを保存し、エディタを閉じます。

      4. ConfigMap に行が追加されたことを確認します。

        kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"

        返された出力が true でない場合は、エラーが発生した可能性があります。ステップをもう一度実行してみてください。

        重要

        サブネットに使用可能な IP アドレスがある場合でも、サブネットに使用可能な /28 個の連続したブロックがない場合には、ノードイベントに次のエラーが表示されます。

        "failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"

        これは、サブネット全体に広がる既存のセカンダリ IP アドレスの断片化が原因で発生する可能性があります。このエラーを解決するには、新しいサブネットを作成してそこに Pods を起動するか、Amazon EC2 サブネットの CIDR 予約を使用して、プレフィックス割り当てで使用するためのサブネット内の領域を予約します。詳細については、Amazon VPC ユーザーガイドの「サブネット CIDR の予約」を参照してください。

    2. (オプション) クラスターの事前スケーリング動作と動的スケーリング動作を制御するための追加設定を指定します。詳細については、「GitHub」の「Windows でのプレフィックス委任モードの設定オプション」を参照してください。

      1. 編集する amazon-vpc-cni ConfigMap を開きます。

        kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
      2. example values を 0 より大きい値に置き換え、必要なエントリを ConfigMap の data セクションに追加します。warm-ip-target または minimum-ip-target のいずれかに値を設定した場合、その値は warm-prefix-target に設定された値をオーバーライドします。

        warm-prefix-target: "1" warm-ip-target: "5" minimum-ip-target: "2"
      3. ファイルを保存し、エディタを閉じます。

    3. 少なくとも 1 つの Amazon EC2 Nitro インスタンスタイプで Windows ノードグループを作成します。Nitro インスタンスタイプのリストについては、「Windows インスタンス用 Amazon EC2 ユーザーガイド」の「Nitro System 上に構築されたインスタンス」を参照してください。デフォルトでは、1 つのノードにデプロイできる Pods の最大数は 110 です。この数値を増減させる場合は、ブートストラップ設定のユーザーデータに以下を指定します。max-pods-quantity を最大ポッド値に置き換えます。

      -KubeletExtraArgs '--max-pods=max-pods-quantity'

      マネージド型ノードグループをデプロイする場合は、この設定を起動テンプレートに追加する必要があります。詳細については、「起動テンプレートを使用したマネージドノードのカスタマイズ」を参照してください。Windows ブートストラップスクリプトの設定パラメータの詳細については、「ブートストラップスクリプトの設定パラメータ」を参照してください。

  2. ノードがデプロイされると、クラスター内のノードの表示が可能になります。

    kubectl get nodes

    出力例は次のとおりです。

    NAME STATUS ROLES AGE VERSION ip-192-168-22-103.region-code.compute.internal Ready <none> 19m v1.XX.X-eks-6b7464 ip-192-168-97-94.region-code.compute.internal Ready <none> 19m v1.XX.X-eks-6b7464
  3. いずれかのノードを記述して、そのノードの max-pods 値と使用可能な IP アドレスの数を決定します。前の出力で返されたいずれかのノードの名前の 192.168.30.193 を IPv4 アドレスに置き換えます。

    kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'

    出力例は次のとおりです。

    pods:                                  110
    vpc.amazonaws.com/PrivateIPv4Address:  144

    前の出力にある 110 は、144 個の IP アドレスが使用可能であるにもかかわらず、Kubernetes がノードにデプロイする Pods の最大数です。