ポッドスパースまたは大規模ワークロードに関する考慮事項ノードクラスを作成するノードクラスのアクセスエントリを作成するノードクラスの指定考慮事項ポッドのサブネットとセキュリティグループを分離するポッドのセカンダリ IP モード IPv6 クラスター内の IPv6 ポッドからの IPv4 egress を無効にする。静的ネットワークインターフェイスの設定ノードで hugepages を設定するノードでの kubelet 設定の構成ノードでカーネル sysctl を設定する

Amazon EKS のノードクラスを作成する

Amazon EKS ノードクラスは、EKS Auto Mode マネージドノードの設定をきめ細かく制御できるテンプレートです。ノードクラスは、ネットワーク設定、ストレージ設定、リソースタグ付けなど、EKS クラスター内のノードのグループに適用されるインフラストラクチャレベルの設定を定義します。このトピックでは、特定の運用要件を満たすようにノードクラスを作成および設定する方法について説明します。

EKS Auto Mode がデフォルト設定を超えて EC2 インスタンスをプロビジョニングおよび設定する方法をカスタマイズする必要がある場合は、ノードクラスを作成すると、重要なインフラストラクチャパラメータを正確に制御できます。例えば、セキュリティを強化するためにプライベートサブネットの配置を指定したり、パフォーマンス重視のワークロード用にインスタンスエフェメラルストレージを設定したり、コスト配分のためにカスタムタグ付けを適用したりできます。

ポッドスパースまたは大規模ワークロードに関する考慮事項

EKS Auto Mode は、デフォルトでプレフィックス委任 (/28 プレフィックス) を使用します。各ノードは 16 個のポッド IP を予約します。これは、それらのスロットを使い切るポッド密度の高いワークロードに対して効率的です。アベイラビリティーゾーンあたり数百個を超えるノードをターゲットとするポッドスパースワークロード (ML または GPU ワークロードで一般的なノードあたり数個のポッド、またはアンチアフィニティが多いワークロード) の場合、セカンダリ IP モード ("32") はより最適化された設定です。ノードごとに 16 個を予約するのではなく、ポッドごとに 1 つの IP を割り当てることで、/20 ポッドサブネットの実効容量を拡張します。

詳細については、「ポッドのセカンダリ IP モード」を参照してください。ポッドをノードとは別のサブネットに保持するには (割り当てモードとは無関係)、「ポッドのサブネットとセキュリティグループを分離する」を参照してください。

ノードクラスを作成する

NodeClass を作成するには、次の手順に従います。

自分のノードクラス設定で YAML ファイル (nodeclass.yaml など) を作成します
kubectl を使用してこの設定をクラスターに適用します
ノードプール設定でノードクラスを参照します。詳細については、「EKS 自動モードl 用のノードプールを作成する」を参照してください。

kubectl がインストールおよび設定されている必要があります。詳細については、「Amazon EKS を使用するようにセットアップする」を参照してください。

基本的なノードクラスの例

ノードクラスの例を次に示します。


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
  ephemeralStorage:
    size: "160Gi"

この NodeClass により、ノード上のエフェメラルストレージの量が増加します。

次を使用してこの設定を適用します。


kubectl apply -f nodeclass.yaml

次に、ノードプール設定でノードクラスを参照します。詳細については、「EKS 自動モードl 用のノードプールを作成する」を参照してください。

ノードクラスのアクセスエントリを作成する

カスタムノードクラスを作成する場合は、ノードがクラスターに参加できるように EKS アクセスエントリを作成する必要があります。組み込みのノードクラスとノードプールを使用すると、EKS によってアクセスエントリが自動的に作成されます。

アクセスエントリがどのように機能するかについては、「EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する」を参照してください。

EKS Auto Mode ノードクラスのアクセスエントリを作成するときは、EC2 のアクセスエントリタイプを使用する必要があります。

CLI でアクセスエントリを作成する

EC2 ノードのアクセスエントリを作成して EKS Auto Node ポリシーを関連付けるには:

次の CLI コマンドを、使用するクラスター名とノードロール ARN で更新します。ノードロール ARN は、ノードクラス YAML で指定されます。


# Create the access entry for EC2 nodes
aws eks create-access-entry \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --type EC2

# Associate the auto node policy
aws eks associate-access-policy \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
  --access-scope type=cluster

CloudFormation でアクセスエントリを作成する

EC2 ノードのアクセスエントリを作成して EKS Auto Node ポリシーを関連付けるには:

次の CloudFormation を、使用するクラスター名とノードロール ARN で更新します。ノードロール ARN は、ノードクラス YAML で指定されます。


EKSAutoNodeRoleAccessEntry:
  Type: AWS::EKS::AccessEntry
  Properties:
    ClusterName: <cluster-name>
    PrincipalArn: <node-role-arn>
    Type: "EC2"
    AccessPolicies:
      - AccessScope:
          Type: cluster
        PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

CloudFormation スタックのデプロイの詳細については、「Getting started with CloudFormation」を参照してください

ノードクラスの指定


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields

  # role and instanceProfile are mutually exclusive fields.
  role: MyNodeRole  # IAM role for EC2 instances
  # instanceProfile: eks-MyNodeInstanceProfile  # IAM instance-profile for EC2 instances

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0123456789abcdef0"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
    # Alternative approaches:
    # - id: "sg-0123456789abcdef0"
    # - name: "eks-cluster-security-group"

  # Optional: Pod subnet selector for advanced networking
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0987654321fedcba0"
  # must include Pod security group selector also
  podSecurityGroupSelectorTerms:
    - tags:
        Name: "eks-pod-sg"
    # Alternative using direct security group ID
    # - id: "sg-0123456789abcdef0"

  # Optional: Selects on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        Name: "targeted-odcr"
      # Optional owning account ID filter
      owner: "012345678901"

  # Optional fields
  snatPolicy: Random  # or Disabled

  networkPolicy: DefaultAllow  # or DefaultDeny
  networkPolicyEventLogs: Disabled  # or Enabled

  ephemeralStorage:
    size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
    iops: 3000      # Range: 3000-16000
    throughput: 125 # Range: 125-1000
    # Optional KMS key for encryption
    kmsKeyID: "arn:aws:kms:region:account:key/key-id"
    # Accepted formats:
    # KMS Key ID
    # KMS Key ARN
    # Key Alias Name
    # Key Alias ARN

  advancedNetworking:
    # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
    # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
    associatePublicIPAddress: false

    # Optional: Forward proxy, commonly requires certificateBundles as well
    # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
    httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
    #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
    noProxy: #Max 50 entries
        - localhost #Max 255 characters each
        - 127.0.0.1
        #- ::1 # IPv6 localhost
        #- 0:0:0:0:0:0:0:1 # IPv6 localhost
        - 169.254.169.254 # EC2 Instance Metadata Service
        #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
        # Domains to exclude, put all VPC endpoints here
        - .internal
        - .eks.amazonaws.com
    # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
    ipv4PrefixSize: Auto # or "32"

    # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
    enableV4Egress: false

    # Optional: Static network interface configuration for EFA workloads
    networkInterfaces:
      # The primary ENI (networkCardIndex 0, deviceIndex 0) must use interfaceType: interface
      # secondaryIPv4Count and secondaryIPv4PrefixCount are only supported on networkCardIndex 0
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4Count: 10
    - deviceIndex: 1
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 2 # Only one of secondaryIPv4Count or secondaryIPv4PrefixCount per ENI
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1

  advancedSecurity:
    # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
    fips: false

  # Optional: Custom certificate bundles.
  certificateBundles:
    - name: "custom-cert"
      data: "base64-encoded-cert-data"

  # Optional: EC2 Placement Group
  placementGroupSelector:
    name: "targeted-pg"
    # Alternative use direct placement group ID
    # id: "pg-02465754522cda020"

  # Optional: Additional EC2 tags (with restrictions)
  tags:
    Environment: "production"
    Team: "platform"
    # Note: Cannot use restricted tags like:
    # - kubernetes.io/cluster/*
    # - karpenter.sh/provisioner-name
    # - karpenter.sh/nodepool
    # - karpenter.sh/nodeclaim
    # - karpenter.sh/managed-by
    # - eks.amazonaws.com/nodeclass

考慮事項

インスタンスのローカルストレージの容量を確認したい場合は、ノードを記述してエフェメラルストレージリソースを表示できます。
ボリュームの暗号化 – インスタンスの読み取り専用ルートボリュームおよび読み取り/書き込みデータボリュームを暗号化するため、EKS は設定されたカスタム KMS キーを使用します。
ノード IAM ロールの置換 – NodeClass に関連付けられているノード IAM ロールを変更する場合は、新しいアクセスエントリを作成する必要があります。EKS は、クラスターの作成時にノード IAM ロールのアクセスエントリを自動的に作成します。ノード IAM ロールには AmazonEKSAutoNodePolicy EKS アクセスポリシーが必要です。詳細については、「EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する」を参照してください。
最大 Pod 密度 – EKS では、ノード上の Pod の最大数が 110 に制限されています。この制限は、既存の最大 Pod を計算した後に適用されます。詳細については、「最適な Amazon EC2 ノードインスタンスタイプを選択する」を参照してください。
タグ - Kubernetes から EC2 にタグを伝播させる場合は、追加の IAM アクセス許可を設定する必要があります。詳細については、「EKS Auto Mode での ID とアクセスについての説明」を参照してください。
デフォルトのノードクラス – カスタムノードクラスに default という名前を付けないでください。これは、EKS Auto Mode には、少なくとも 1 つの組み込み NodePool を有効にすると自動的にプロビジョニングされる default と呼ばれる NodeClass が含まれるためです。組み込み NodePools を有効にする方法については、「組み込み NodePool を有効または無効にする」を参照してください。
複数のサブネットを使用した subnetSelectorTerms 動作 – subnetSelectorTerms 条件に一致するサブネットまたは ID で指定したサブネットが複数ある場合、EKS Auto Mode はサブネット全体に分散されたノードを作成します。
- サブネットが異なるアベイラビリティーゾーン (AZ) にある場合、Pod トポロジスプレッド制約や Topology Aware Routing といった Kubernetes 機能を使用して、Pod とトラフィックをそれぞれゾーン間に分散できます。
- 同じ AZ 内に subnetSelectorTerms に一致するサブネットが複数ある場合、EKS Auto Mode はその AZ のサブネット全体に分散した各ノードに Pod を作成します。EKS Auto Mode は、同じ AZ 内の他のサブネットの各ノードにセカンダリネットワークインターフェイスを作成します。各サブネットで使用可能な IP アドレスの数に基づいて選択し、サブネットをより効率的に使用します。ただし、EKS Auto Mode が各 Pod に使用するサブネットを指定することはできません。特定のサブネットで Pod を実行する必要がある場合は、代わりにポッドのサブネットとセキュリティグループを分離するを使用してください。
プレイスメントグループ戦略の制限 – 各プレイスメントグループ戦略 (クラスター、パーティション、スプレッド) には、インスタンスタイプ、AZ、容量に特定の制限があります。詳細については、Amazon EC2 ユーザーガイドの「プレイスメントグループのプレイスメント戦略」を参照してください。
スプレッドプレイスメントグループ – 7 インスタンスの制限 – ラックレベルのスプレッドプレイスメントグループでは、1 グループあたり、アベイラビリティーゾーンごとに最大 7 つの実行中のインスタンスを使用できます。これにより、以下のエッジケースが作成されます。
- 容量不足によるドリフト置き換えのブロック – EKS Auto Mode は、古いノードを終了する前に代替ノードを起動します。¢ スプレッド PG が AZ に 7 つのインスタンスを持つ場合、置き換えの起動は失敗し、スロットが解放されるまでドリフトしたノードは実行されたままになります。
- すべての AZ が容量上限に達している場合 – スプレッド PG 内のすべての AZ が 7 インスタンスの制限に達している場合、置き換えをスケジュールすることはできません。ドリフトノードまたは統合候補ノードは無期限に実行され続けます。
- プレイスメントグループ外へのフォールバックなし – EKS Auto Mode はプレイスメントグループ外での代替インスタンスの起動を試みません。
- 回避策 – WhenEmpty 統合ポリシー (consolidationPolicy: WhenEmpty) を使用します。ノードは、デーモンセット以外のポッドがすべてドレインオフされた後にのみ削除されるため、先に置き換えを起動することなく、PG スロットを解放できます。ドリフトは常に統合ポリシーに関係なく replace-then-delete を使用するため、ドリフトは容量制限に達したままブロックされることに注意してください。
クラスタープレイスメントグループ AZ 固定 – 最初のインスタンスがクラスタープレイスメントグループで起動されると、PG はその AZ に固定されます。NodePool で複数の AZ が許可されている場合、初期スケールアップ中の並列起動が競合する可能性があります。1 つは成功し、AZ を固定します。残りは容量不足エラーで失敗します。NodePool 要件で AZ を固定して、一時的な障害を回避します。
パーティションプレイスメントグループ – パーティションプレイスメントグループは、標準の EC2 制限を超える追加の制約なしでサポートされています。
統合によってポッドがプレイスメントグループから移動されることがあります – ポッドにプレイスメントグループのスケジューリング制約 (eks.amazonaws.com/placement-group-id の nodeSelector など) がない場合、統合によってポッドが PG 外のノードに移動されることがあります。プレイスメントグループメンバーシップを必要とするアプリケーションは、これをポッドレベルの制約で表現する必要があります。
存在しない、または削除されたプレイスメントグループ – NodeClass が存在しない、または削除されたプレイスメントグループを参照する場合、インスタンスは起動されません。プレイスメントグループ ID 形式は登録時に検証されますが、存在は起動時にのみチェックされます。ノードの実行中にプレイスメントグループが削除された場合、既存のノードはドリフト済みとしてマークされますが、ドリフト置き換えの起動もブロックされるため、無期限に実行されたままになります。
Hugepages – ノードで hugepages を設定する方法については、「ノードで hugepages を設定する」を参照してください。
Kubelet 設定 – ポッド密度、エビクションしきい値、ログローテーションなどの kubelet 設定の上書きについては、「ノードでの kubelet 設定の構成」を参照してください。
カーネル sysctls – ノードでカーネル sysctls を設定する方法については、「ノードでカーネル sysctl を設定する」を参照してください。

ポッドのサブネットとセキュリティグループを分離する

podSubnetSelectorTerms と podSecurityGroupSelectorTerms フィールドにより、ポッドがノードとは異なるサブネットとセキュリティグループを使用できるようになるため、高度なネットワーク設定が可能になります。両方のフィールドを一緒に指定する必要があります。この分離により、ネットワークトラフィックのルーティングとセキュリティポリシーの制御が強化されます。

注記

この機能は、EKS Auto Mode 以外のコンピューティング用の VPC CNI で使用されるポッドのセキュリティグループ (SGPP) 機能とは異なります。SGPP は EKS Auto Mode ではサポートされていません。代わりに、NodeClass で podSecurityGroupSelectorTerms を使用して、ポッドトラフィックに個別のセキュリティグループを適用します。セキュリティグループは NodeClass レベルで適用されます。つまり、その NodeClass を使用するノード上のすべてのポッドは、同じのポッドセキュリティグループを共有します。

仕組み

podSubnetSelectorTerms と podSecurityGroupSelectorTerms を設定する場合:

ノードのプライマリ ENI は、subnetSelectorTerms および securityGroupSelectorTerms のサブネットとセキュリティグループを使用します。このインターフェイスには、ノード自身の IP アドレスのみが割り当てられます。
EKS Auto Mode では、podSubnetSelectorTerms に一致するサブネット内にセカンダリ ENI が作成され、podSecurityGroupSelectorTerms のセキュリティグループがそれらにアタッチされます。ポッド IP アドレスは、デフォルトで /28 プレフィックスを使用してこれらのセカンダリ ENI から割り当てられます。連続するプレフィックスブロックが使用できない場合、セカンダリ IP (/32) への自動フォールバックが行われます。advancedNetworking で ipv4PrefixSize が "32" に設定されている場合、セカンダリ IP のみが使用されます。
podSecurityGroupSelectorTerms で指定されたセキュリティグループは、VPC 内のポッドトラフィックに適用されます。VPC 外を送信先とするトラフィックの場合、ソースネットワークアドレス変換 (SNAT) はポッド IP をノード IP に変換するため、ポッドはノードのプライマリ ENI (およびそのセキュリティグループ) を使用します。この動作は、NodeClass の snatPolicy フィールドで変更できます。

ユースケース

以下の場合に podSubnetSelectorTerms および podSecurityGroupSelectorTerms を使用します。

異なるセキュリティグループを適用して、ノードとポッドのトラフィックを個別に制御する必要がある場合。
インフラストラクチャトラフィック (ノード間の通信) とアプリケーショントラフィック (ポッド間の通信) を分離する必要がある場合。
Pod サブネットとは異なるネットワーク設定をノードサブネットに適用する。
Pod トラフィックに影響を与えずに、ノードトラフィック専用のリバースプロキシまたはネットワークフィルタリングを設定する。advancedNetworking と certificateBundles を使用して、リバースプロキシと、プロキシの自己署名証明書またはプライベート証明書を定義する。

設定例


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  # Subnets and security groups for EC2 instances (nodes)
  subnetSelectorTerms:
    - tags:
        Name: "node-subnet"
        kubernetes.io/role/internal-elb: "1"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  # Separate subnets and security groups for Pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

  podSecurityGroupSelectorTerms:
  - tags:
      Name: "eks-pod-sg"

個別のポッドサブネットとセキュリティグループに関する考慮事項

セキュリティグループの範囲: podSecurityGroupSelectorTerms のセキュリティグループはセカンダリ ENI にアタッチされ、VPC 内のポッドトラフィックに適用されます。SNAT が有効になっている場合 (デフォルトの snatPolicy: Random)、VPC から出るトラフィックはノードのプライマリ ENI IP アドレスに変換されるため、securityGroupSelectorTerms からのノードのセキュリティグループは代わりにそのトラフィックに適用されます。snatPolicy: Disabled を設定すると、ポッドはすべてのトラフィックに独自の IP アドレスを使用するため、ルーティンググループとセキュリティグループが適切に設定されていることを確認する必要があります。
NodeClass レベルの粒度: ポッドセキュリティグループは、NodeClass を使用してノードでスケジュールされたすべてのポッドに適用されます。異なるセキュリティグループを異なるワークロードに適用するには、個別の NodeClass リソースと NodePool リソースを作成し、テイント、許容範囲、またはノードセレクターを使用してワークロードを適切なノードにスケジュールします。
ポッド密度の低下: ノードのプライマリネットワークインターフェイスはノード IP 用に予約されており、ポッドに使用できないため、各ノードで実行できるポッドの数が少なくなります。
サブネットセレクターの制限: 標準 subnetSelectorTerms および securityGroupSelectorTerms 設定は、ポッドサブネットまたはセキュリティグループの選択には適用されません。
ネットワーク計画: ワークロード要件をサポートするために、ノードサブネットと Pod サブネットの両方に十分な IP アドレススペースを確保します。
ルーティング設定: ノードサブネットとポッドサブネット間の通信用に、ポッドサブネットのルートテーブルとネットワークアクセスコントロールリスト (ACL) が適切に設定されていることを確認します。
アベイラビリティーゾーン: 複数の AZ にわたって Pod サブネットを作成したことを確認します。特定のポッドサブネットを使用している場合、そのサブネットはノードサブネット AZ と同じ AZ に存在している必要があります。

ポッドのセカンダリ IP モード

ipv4PrefixSize フィールドは、ノードへのセカンダリ IP アドレスのみを割り当てることで、高度なネットワーク設定を有効にします。この機能はノードにプレフィックス (/28) を割り当てず、1 つのセカンダリ IP のみを MinimalIPTarget として維持します。

advancedNetworking.ipv4PrefixSize は、次の 2 つの値を受け入れます。Auto (デフォルト、プレフィックス委任、ポッド作成速度の向上、ノードごとに最低 16 個の IP を予約) および "32" (セカンダリ IP モード、ポッドごとに 1 個の IP、ポッドごとの AssignPrivateIpAddresses 呼び出しを追加、インスタンスタイプの ENI IP 制限によってノードあたりのポッド数が制限される)。

Auto モードでは、EKS Auto Mode は各ノードに /28 プレフィックス (16 個の IP) を事前に割り当て、ポッドの需要が現在のブロックの容量を超えたときに別の /28 を追加するため、16 はノードごとの上限ではなく最小値です。

計画には次の数値を使用しますが、実際のクラスターは異なります。ポッドサブネットがフラグメント化され、連続した /28 が解放されない場合、Auto モードはそのノードの IP ごとの割り当てにフォールバックします。ノードごとの IP 数は、以下に示すプレフィックスごとに 16 個のパターンを下回ります。

例 A — ノードに 1 つのポッド

セカンダリ IP モード: ポッドの IP 1 個 + ノードの IP 1 個 = 2 個の IP を使用。
プレフィックスモード: ノードの IP 1 個 + 最初の /28 プレフィックスからの IP 16 個 (うち 1 つはポッドで使用、15 個は将来のポッド用に確保) = 17 個の IP を割り当て、2 個を使用。

例 B — ノードに 18 個のポッド

セカンダリ IP モード: ポッドの IP 18 個+ ノードの IP 1 個 = 19 個の IP を使用。
プレフィックスモード: ノードの IP 1 個 + 2 × /28 プレフィックス (合計 32 個の IP、最初の /28 は 16 ポッドに充当し、2 番目の /28 はポッド 17～18 を保持し、将来のポッド用に 14 個を確保) = 33 個の IP を割り当て、19 個を使用。

ポッドスパースワークロード向けにセカンダリ IP モード (ポッドごとに 1 IP、プレフィックス予約なし) に切り替えるには、advancedNetworking.ipv4PrefixSize: "32" を使用してカスタム NodeClass を作成し、カスタム NodePool でそれを参照します。組み込みの general-purpose および system ノードプールは、自動的にプロビジョニングされた default NodeClass を使用します。ipv4PrefixSize を上書きするには、カスタム NodePool とペアリングされたカスタム NodeClass が必要です。

ユースケース

サブネット IP アドレスの使用率の向上
プレフィックスの断片化なし

設定例


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    ipv4PrefixSize: "32"

セカンダリ IP モードに関する考慮事項

ポッド作成速度の低下: 1 つのセカンダリ IP のみがウォームアップされるため、より多くのポッドが作成された場合、IPAM サービスによる IP のプロビジョニングにより多くの時間がかかります。

IPv6 クラスター内の IPv6 ポッドからの IPv4 egress を無効にする。

デフォルトでは、enableV4Egress フィールドは true です。Auto Mode IPv6 クラスターの場合、この機能を無効にすることで、Auto Mode が IPv6 ポッドに対して egress 専用 IPv4 インターフェイスを作成しないようにすることができます。IPv4 egress インターフェイスはネットワークポリシーの適用対象外であるため、これは重要です。ネットワークポリシーは、ポッドのプライマリインターフェイス (eth0) にのみ適用されます。

ユースケース

次の場合に enableV4Egress を使用します:

IPv6 クラスターを使用する: IPv4 egress トラフィックはデフォルトで許可されています。
ネットワークポリシーを使用する: 現在、EKS ネットワークポリシーはデュアルスタックをサポートしていません。enableV4Egress を無効にすると、ポッドトラフィックが IPv4 経由で予期せず出力されるのを防ぐことができます。

設定例


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    enableV4Egress: false

enableV4Egress を無効にする際の考慮事項

IPv6 クラスターのネットワークポリシー: IPv6 クラスターでは、デフォルトで IPv4 トラフィックが許可されています。enableV4Egress: false に設定すると、IPv4 egress トラフィックがブロックされ、特にネットワークポリシーで使用する場合にセキュリティが強化されます。

静的ネットワークインターフェイスの設定

advancedNetworking の networkInterfaces フィールドを使用すると、起動時にインスタンスにアタッチされたネットワークインターフェイスを静的に定義できます。これは主に、分散トレーニングおよび推論ワークロードでの高性能なノード間通信用に Elastic Fabric Adapter (EFA) デバイスを設定するために使用されます。この機能は、静的キャパシティノードプールと組み合わせて、事前ウォーミングされた EFA 対応ノードを維持できます。EKS での EFA デバイス管理の詳細については、Amazon EKS で EFA デバイスを管理するを参照してください。特定のインスタンスタイプの推奨される EFA 設定については、「Amazon EC2 ユーザーガイド」の「EFA 対応インスタンスタイプのネットワーク帯域幅を最大化する」を参照してください。

仕組み

networkInterfaces の各エントリは、起動時にインスタンスにアタッチされるネットワークインターフェイスを定義します。各エントリは、networkCardIndex (ネットワークカード、ここで 0 はプライマリ)、deviceIndex (そのカード上のデバイス位置)、および interfaceType (標準 IP ベースのトラフィックの場合は interface、または IP アドレスのない RDMA トラフィック専用の EFA インターフェイスの場合は efa-only) を指定します。IP ベースのノード通信をサポートするには、プライマリ ENI (networkCardIndex: 0、deviceIndex: 0) が interfaceType: interface を使用する必要があります。efa-only インターフェイスは RDMA の EFA デバイス機能のみをサポートし、IP アドレスで設定することはできません。

secondaryIPv4Count (各ユニットは 1 つの IP アドレスを提供する) または secondaryIPv4PrefixCount (各ユニットは 16 個の IP アドレスを持つ /28 プレフィックスを提供する) を使用して、プライマリネットワークカード (networkCardIndex: 0) のインターフェイスに IP キャパシティを割り当てることができます。インターフェイスごとに使用できるのはこれらのうちの 1 つだけで、networkCardIndex: 0 でのみサポートされています。efa-only インターフェイスでは使用できません。

重要

networkInterfaces が設定されている場合、EKS Auto Mode はインスタンスの起動後に追加の IP、プレフィックス、または ENI をアタッチしません。起動時に設定されたインターフェイスと IP アドレスのみが Pod で使用できます。設定された IP の数に基づいてポッド密度を計画する必要があります。

考慮事項

IPv6 は、静的に定義されたネットワークインターフェイスではサポートされていません。associatePublicIPAddress は、複数のネットワークインターフェイスが定義されている場合は互換性がないため、複数のインターフェイスを使用するノードにパブリック IP (パブリック専用クラスターまたはパブリック/プライベートクラスターの混在) を含めることはできません。

静的ネットワークインターフェイスで podSubnetSelectorTerms と podSecurityGroupSelectorTerms を使用する場合は、プライマリ ENI を 0 個のセカンダリ IP で設定します。プライマリ ENI はノードサブネットとセキュリティグループを使用し、Pod トラフィックはセカンダリ ENI でポッドサブネット設定を使用します。

例: GPU トレーニング用の EFA 専用インターフェイス

次の例は、分散トレーニングで使用される GPU インスタンスの EFA 専用インターフェイスで設定された NodeClass を示しています。プライマリインターフェイスには /28 プレフィックス (16 個のポッド IP) があり、4 個の追加の EFA 専用インターフェイスは RDMA 接続を提供します。この設定は、静的キャパシティノードプールと組み合わせて、事前ウォーミングされた EFA 対応ノードを維持できます。


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: efa-training
spec:
  role: MyNodeRole
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
  securityGroupSelectorTerms:
    - tags:
        Name: "efa-security-group"
  placementGroupSelector:
    name: "ml-training-pg"
  advancedNetworking:
    networkInterfaces:
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 1
    - deviceIndex: 1
      interfaceType: efa-only
      networkCardIndex: 0
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 2
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 3

ノードで hugepages を設定する

advancedCompute.hugepages フィールドを使用すると、NodeClass のノードに hugepages を設定できます。hugepages は、ハイパフォーマンスコンピューティング (HPC)、データベース、ネットワーク負荷の高いアプリケーションなど、レイテンシーに敏感なワークロードのメモリアクセス性能を向上させます。2 つの独立した hugepages 設定を個別に、または組み合わせて使用できます。

静的な hugepages – pages フィールドを使用して、各ノードで固定数の 2Mi または 1Gi hugepages、あるいは両方のサイズの組み合わせを事前に割り当てます。静的な hugepages は、スケジューリング可能なノードリソースです。使用するには、hugepages-2Mi や hugepages-1Gi などの hugepage リソースを明示的にリクエストするようにポッドを設定します。詳細については、Kubernetes ドキュメントの「HugePages を管理する」を参照してください。
Transparent hugepages (THP) – transparent フィールドを使用してカーネルの THP ポリシーを設定します。THP は、割り当て可能なリソースではなく、カーネル全体のポリシーです。スケジューリングやノード容量には影響せず、ポッドからリクエストすることもありません。詳細については、Linux カーネルドキュメントの「Transparent Hugepage Support」を参照してください。

設定例


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: hugepages-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    hugepages:
      # Static hugepage reservations: up to one entry for each size
      pages:
        - size: "2Mi"
          count: 512
        - size: "1Gi"
          count: 2
      # Transparent hugepages (THP) kernel policy
      transparent:
        enabled: always  # or madvise, never
        defrag: defer    # or always, defer+madvise, madvise, never

Transparent hugepage の設定

どちらの transparent 設定もオプションです。設定を省略すると、ノードはカーネルのデフォルト (madvise) を使用します。

enabled – enabled を使用して THP 割り当てポリシーを制御します。THP をシステム全体に適用するには、これを always に設定します。madvise(MADV_HUGEPAGE) でオプトインするメモリリージョンにのみ THP を適用するには、madvise に設定します。THP を無効にするには、never に設定します。
defrag – defrag を使用して、THP 割り当てを満たすためにカーネルがメモリをどの程度積極的に圧縮するかを制御します。有効な値は、always、defer、defer+madvise、madvise、never です。

THP を無効にすることを推奨するデータベースワークロードなどで THP を無効にするには、enabled: never を設定します。enabled が never の場合、defrag を未設定のままにするか、never に設定します。NodeClass 検証は他の組み合わせを拒否します。

hugepages に関する考慮事項

NodeClass で hugepages を設定する際は、次の点を考慮してください。

静的な hugepage サイズ – pages フィールドを使用して、hugepage サイズ (2Mi および 1Gi) ごとに最大 1 つのエントリを指定します。同じノードで両方のサイズを予約できます。
メモリ予約 – 静的 hugepage はインスタンスの総メモリに対して不利になります。すべてのページサイズにわたる hugepage の予約の合計が総メモリの 80% を超える場合、Amazon EKS はそのインスタンスタイプを NodeClass と互換性がないものとしてマークします。
EFA の相互排他 – Elastic Fabric Adapter (EFA) と静的 hugepage は同じ NodeClass で共存できません。interfaceType: efa-only と pages を同時に設定すると、NodeClass の検証が失敗します。Amazon EKS は、静的 hugepage が設定された NodeClass から vpc.amazonaws.com/efa をリクエストするポッドをプロビジョニングしません。EFA ワークロードには別の NodeClass を使用してください。Transparent hugepages は EFA と競合しません。EFA インターフェイスを使用する NodeClass で transparent を設定できます。

ノードでの kubelet 設定の構成

advancedCompute.kubelet フィールドを使用して、NodeClass 内のノードの kubelet 設定を上書きします。これらの上書きを使用すると、ポッド密度、リソースプレッシャーによるエビクション、コンテナログのローテーション、out-of-memory (OOM) の動作を調整できます。Amazon EKS はデフォルトの kubelet 設定を Auto Mode ノードに適用するため、ワークロードで異なる動作が必要な場合にのみこのフィールドを設定してください。基盤となる設定の詳細については、Kubernetes ドキュメントの「Kubelet 設定」を参照してください。

以下の kubelet 設定を使用できます。

maxPods: 1 つのノードで実行できるポッドの最大数。
podPidsLimit: ポッドあたりのプロセス ID (PID) の最大数。
idsPerPod: kubelet が各ポッドのユーザー名前空間に割り当てる UID と GID の数。
singleProcessOOMKill: kubelet OOM がグループとしてではなく、コンテナ内のプロセスを個別に強制終了するかどうか。
eviction: リソースプレッシャーシグナルのハードエビクションしきい値とソフトエビクションしきい値。
logging: コンテナログのローテーションサイズとファイル数。
allowedUnsafeSysctls: ノードでスケジュールされたポッドが設定できる、安全でない sysctl のリスト、または * で終わる名前空間パターンのリスト。

設定例


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: kubelet-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    kubelet:
      # Range: 1-110
      maxPods: 60
      # -1 disables the limit, or specify 100 or greater
      podPidsLimit: 4096
      # Multiple of 65536, range: 65536-4294967295. Requires
      # advancedCompute.kernel.sysctl.user.max_user_namespaces > 0.
      idsPerPod: 65536
      singleProcessOOMKill: false
      eviction:
        # Valid signals: memory.available, nodefs.available, nodefs.inodesFree,
        # imagefs.available, imagefs.inodesFree, pid.available
        hard:
          memory.available: "100Mi"
          nodefs.available: "10%"
        soft:
          memory.available: "500Mi"
          nodefs.available: "15%"
        # Required when soft thresholds are set
        softGracePeriod:
          memory.available: "1m30s"
          nodefs.available: "2m"
        # 0 uses each Pod's terminationGracePeriodSeconds
        maxPodGracePeriod: 60
      logging:
        containerLogMaxSize: "10Mi"
        # Minimum: 2
        containerLogMaxFiles: 5
      # Up to 64 entries. Allowed patterns: kernel.shm*, kernel.msg*,
      # kernel.sem, fs.mqueue.*, net.*
      allowedUnsafeSysctls:
        - "net.core.somaxconn"
        - "kernel.shm*"

Kubelet 設定に関する考慮事項

NodeClass で kubelet 設定を行う際は、次の点を考慮してください。

ノード置換: 既存の NodeClass で kubelet 設定を変更すると、それを使用するノードがドリフトとしてマークされます。Amazon EKS は、これらのノードを、更新された設定を使用する新しいノードに置き換えます。Amazon EKS は、実行中のノードに kubelet 設定をインプレースで適用しません。
maxPods クランプ: 設定した値は上限であり、保証ではありません。実行時に、Amazon EKS は 3 つの値のうち最も低い値を適用します。それは、maxPods の値、インスタンスタイプで使用できる IP アドレス数、ノードあたり 110 ポッドの Auto Mode 制限です。詳細については、「最適な Amazon EC2 ノードインスタンスタイプを選択する」を参照してください。
podPidsLimit 値: -1 を指定して制限を無効にするか、100 以上の値を指定します。NodeClass 検証は 0～99 の値を拒否します。
idsPerPod 要件: 値は 65536～4294967295 で 65536 の倍数である必要があります。idsPerPod を設定するには、同じ NodeClass 上で advancedCompute.kernel.sysctl.user.max_user_namespaces を正の値に設定する必要があります。NodeClass アドミッションは、user.max_user_namespaces を 0 より大きい値に設定せずに idsPerPod を設定する構成を拒否します。user.max_user_namespaces の詳細については、「サポートされている sysctl」を参照してください。
ソフトエビクションしきい値: ソフトしきい値は、同じシグナルのハードしきい値よりも緩やかである必要があります。つまり、より早くトリガーされます。ソフトしきい値を設定する場合は、シグナルごとに softGracePeriod も設定する必要があります。ソフトしきい値とハードしきい値では、パーセンテージと絶対数量など、異なる単位を使用できます。この場合、Amazon EKS はインスタンスタイプごとに両方の値を解決します。その後、Amazon EKS は比較に違反するインスタンスタイプを NodeClass と互換性がないものとしてマークします。
singleProcessOOMKill バージョン要件: この設定には Kubernetes バージョン 1.32 以降が必要です。以前のバージョンでは、Amazon EKS は NodeClass に警告イベントを発行し、設定は効果がありません。
allowedUnsafeSysctls 制限: 最大 64 個のエントリを指定できます。各エントリは、kernel.shm*、kernel.msg*、kernel.sem、fs.mqueue.、または net. の許可されたパターンのいずれかと一致する必要があります。ノードで安全でない sysctl を許可しても、ポッドがそれをリクエストできるようになるだけです。各ポッドは引き続き sysctl を securityContext.sysctls にリストする必要があります。詳細については、Kubernetes ドキュメントの「Kubernetes クラスターで sysctl を使用する」を参照してください。

ノードでカーネル sysctl を設定する

advancedCompute.kernel.sysctl フィールドを使用して、NodeClass のノードに Linux カーネル sysctl を設定します。sysctl は、より高いネットワーク制限、異なるメモリ管理ポリシー、または特定の TCP 設定を必要とするワークロードのランタイムカーネル動作を調整します。sysctl フィールドのプロパティ名は、基盤となるカーネル sysctl 名と完全に一致します (例: vm.swappiness および net.core.somaxconn)。Amazon EKS はノードの起動時に sysctl 値を適用します。既存の NodeClass で sysctl を変更すると、Amazon EKS は新しい値を有効にするためにノードの置き換えを開始します。

設定例


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: tuned-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    kernel:
      sysctl:
        vm.swappiness: 30
        net.core.somaxconn: 4096
        net.ipv4.tcp_congestion_control: "cubic"
        vm.dirty_background_ratio: 10
        vm.dirty_ratio: 20

サポートされている sysctl

Amazon EKS は、次の表の sysctl のみをサポートしています。各数値 sysctl は、示された最小値と最大値を適用し、NodeClass アドミッションはその範囲外の値を拒否します。文字列 sysctl は、リストされた値のみを受け入れます。

sysctl	説明	許可される値
`fs.aio-max-nr`	非同期 I/O リクエストの最大数。	`65536`–`4194304`
`fs.inotify.max_user_instances`	実際のユーザー ID あたりの inotify インスタンスの最大数。	`8192`–`1048576`
`fs.inotify.max_user_watches`	実際のユーザー ID あたりの inotify ウォッチの最大数。	`8192`–`1048576`
`fs.nr_open`	プロセスが割り当てることができるファイルハンドルの最大数。	`1048576`–`2147483584`
`kernel.perf_event_paranoid`	パフォーマンスイベントシステムへの非特権アクセスを制御します。	`-1`–`2`
`net.core.netdev_max_backlog`	CPU あたりの INPUT 側でキューに入れられるパケットの最大数。	`1000`–`3240000`
`net.core.rmem_max`	受信ソケットバッファの最大サイズ (バイト単位)。	`212992`–`134217728`
`net.core.somaxconn`	listen syscall のバックログ引数の最大値。	`4096`–`3240000`
`net.core.wmem_max`	送信ソケットバッファの最大サイズ (バイト単位)。	`212992`–`134217728`
`net.ipv4.neigh.default.gc_thresh1`	ガベージコレクションを実行できるようになるまでの最小 ARP キャッシュエントリ数。	`0`–`262144`
`net.ipv4.neigh.default.gc_thresh2`	ARP キャッシュエントリのソフト最大数。	`512`–`524288`
`net.ipv4.neigh.default.gc_thresh3`	ARP キャッシュエントリのハード最大数。	`1024`–`1048576`
`net.ipv4.tcp_congestion_control`	新しい接続に対する TCP 輻輳制御アルゴリズム。	`cubic`, `reno`
`net.ipv4.tcp_fin_timeout`	孤立した接続がローカルエンドで中止されるまで FIN_WAIT_2 状態に留まる時間 (秒単位)。	`5`–`120`
`net.ipv4.tcp_keepalive_time`	キープアライブが有効になっている場合に、TCP がキープアライブメッセージを送信する頻度 (秒単位)。	`30`–`432000`
`net.ipv4.tcp_max_syn_backlog`	許可される未処理の SYN リクエストの最大数。この値を超えるリクエストはカーネルによってドロップされます。	`128`–`3240000`
`net.ipv4.tcp_tw_reuse`	プロトコルの観点から安全であれば、新しい接続に対して TIME-WAIT ソケットの再利用を有効にします。`0` は無効、`1` はグローバルに有効、`2` はループバックのみ有効にします。	`0`–`2`
`user.max_user_namespaces`	ユーザーが作成できるユーザー名前空間の最大数。`0` の値を指定すると、ユーザー名前空間が無効になります。	`0`–`2147483647`
`vm.dirty_background_ratio`	カーネルフラッシャースレッドがダーティページのディスクへの書き戻しを開始する、使用可能なメモリの割合。	`1`–`20`
`vm.dirty_expire_centisecs`	ダーティページが書き戻しの対象になるまでの 100 分の 1 秒単位の時間。	`0`–`6000`
`vm.dirty_ratio`	書き込みプログラムが書き込み時に強制的にブロックされる、使用可能なメモリの割合。	`5`–`40`
`vm.dirty_writeback_centisecs`	フラッシャースレッド呼び出し間の 100 分の 1 秒単位の時間。	`0`–`1000`
`vm.max_map_count`	1 つのプロセスが保持できるメモリマップ領域の最大数。	`65530`–`2147483647`
`vm.swappiness`	スワップとファイルシステムのページングの相対的な IO コスト。	`0`–`200`
`vm.watermark_scale_factor`	メモリ再利用のウォーターマーク比率 (10,000 分の 1 単位)。	`10`–`3000`

sysctl に関する考慮事項

NodeClass でカーネル sysctl を設定する際は、次の点を考慮してください。

サポートされている sysctl – サポートされている sysctl にリストされている sysctl のみがサポートされています。各フィールドはドキュメント化された最小値と最大値を適用し、NodeClass アドミッションはその範囲外の値を拒否します。
起動時に適用 – sysctl はノード起動時に Bottlerocket の [settings.kernel.sysctl] に書き込まれます。spec.advancedCompute.kernel.sysctl へのランタイムの変更により、既存のノードはドリフトとしてマークされます。新しい値は置き換えられたノードでのみ有効になります。
vm.dirty_background_ratio と vm.dirty_ratio – この 2 つのフィールドは両方とも設定するか、両方とも省略する必要があり、vm.dirty_background_ratio は vm.dirty_ratio より必ず小さくなければなりません。NodeClass アドミッションは、いずれかのルールに違反する設定を拒否します。
net.ipv4.neigh.default.gc_thresh1、gc_thresh2、および gc_thresh3 – 3 つの ARP キャッシュしきい値はすべて一緒に設定するか、すべて省略する必要があり、その値は gc_thresh1 < gc_thresh2 < gc_thresh3 を満たす必要があります。NodeClass アドミッションは、いずれかのルールに違反する設定を拒否します。
net.ipv4.tcp_congestion_control – cubic と reno のみが受け入れられます。

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

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

ドキュメントの表記規則

コンピューティングとスケーリング

ノードプールの作成