EKS 自動モードでの静的キャパシティノードプール - Amazon EKS
基本的な例静的キャパシティノードプールを設定する静的キャパシティノードプールの制約静的キャパシティノードプールをスケールする静的キャパシティノードプールをモニタリングする設定例ベストプラクティストラブルシューティング

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EKS 自動モードでの静的キャパシティノードプール

Amazon EKS 自動モードは、静的キャパシティノードプールをサポートしており、ポッドの需要に関係なく決まった数のノードを維持します。静的キャパシティノードプールは、予測可能なキャパシティ、リザーブドインスタンス、または特定のコンプライアンス要件を必要とするワークロードで一貫したインフラストラクチャフットプリントを維持する必要がある場合に有用です。

ポッドスケジューリングの需要に基づいてスケールする動的ノードプールとは異なり、静的キャパシティノードプールでは設定したノードの数が維持されます。

基本的な例

以下に、5 つのノードを維持するシンプルな静的キャパシティノードプールを示します。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-static-nodepool
spec:
  replicas: 5  # Maintain exactly 5 nodes

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m", "c"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b"]

  limits:
    nodes: 8

静的キャパシティノードプールを設定する

静的キャパシティノードプールを作成するには、NodePool 仕様に replicas フィールドを設定します。replicas フィールドでは、ノードプールが維持するノードの正確な数を定義します。

静的キャパシティノードプールの制約

静的キャパシティノードプールには、重要な制約と動作がいくつかあります。

設定に関する制約:

  • モードを切り替えることができない: ノードプールで replicas を設定したら、以後削除することはできません。ノードプールでは、静的モードと動的モードとを切り替えることができません。

  • リソースが制限されている: 制限セクションでは、limits.nodes フィールドのみがサポートされています。CPU とメモリに関する制限は適用されません。

  • 重みフィールドがない: ノードの選択が優先度に基づいていないため、静的キャパシティノードプールに weight フィールドを設定することができません。

オペレーション動作:

  • 統合対象外: 静的キャパシティプールのノードは、使用率に基づく統合対象と見なされません。

  • スケールオペレーション: スケールオペレーションでは、ノード中断の予算はバイパスされますが、PodDisruptionBudgets は引き続き考慮されます。

  • ノードの置き換え: 設定に基づいてドリフト (AMI アップデートなど) と有効期限が発生した場合は、ノードが置き換えられます。

静的キャパシティノードプールをスケールする

kubectl scale コマンドを使用すると、静的キャパシティノードプール内のレプリカの数を変更できます。

# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5

スケールダウンすると、EKS 自動モードはノードを適切に終了し、PodDisruptionBudgets を考慮のうえ、実行中のポッドを残りのノードに再スケジュールできるようにします。

静的キャパシティノードプールをモニタリングする

次のコマンドを使用すると、静的キャパシティノードプールをモニタリングできます。

# View node pool status
kubectl get nodepool static-nodepool

# Get detailed information including current node count
kubectl describe nodepool static-nodepool

# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'

status.nodes フィールドは、ノードプールで管理されているノードの現在の数を示し、通常の条件下で必要になる replicas の数と一致する必要があります。

設定例

基本的な静的キャパシティノードプール

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: basic-static
spec:
  replicas: 5

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a"]

  limits:
    nodes: 8  # Allow scaling up to 8 during operations

特定のインスタンスタイプの静的キャパシティ

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: reserved-instances
spec:
  replicas: 20

  template:
    metadata:
      labels:
        instance-type: reserved
        cost-center: production
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.2xlarge"]  # Specific instance type
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b", "us-west-2c"]

  limits:
    nodes: 25

  disruption:
    # Conservative disruption for production workloads
    budgets:
      - nodes: 10%

マルチゾーンの静的キャパシティノードプール

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: multi-zone-static
spec:
  replicas: 12  # Will be distributed across specified zones

  template:
    metadata:
      labels:
        availability: high
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: In
          values: ["8", "16"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b", "us-west-2c"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]

  limits:
    nodes: 15

  disruption:
    budgets:
      - nodes: 25%

ベストプラクティス

容量計画。

  • limits.nodes を replicas よりも高い値に設定すると、ノードの置き換えオペレーション中に一時的にスケールできるようになります。

  • 制限を設定するときは、ノードドリフトや AMI アップデートに必要な最大キャパシティを考慮してください。

インスタンス選択:

  • リザーブドインスタンスがある場合や特定のハードウェア要件がある場合は、特定のインスタンスタイプを使用します。

  • 制限を過度に厳しくしてスケール中にインスタンスの可用性が制限されるような要件は避けてください。

中断の管理:

  • 可用性とメンテナンスオペレーションとのバランスが取れるように、適切な中断の予算を設定します。

  • 予算の割合を設定するときは、アプリケーションでノードの置き換えをどの程度許容するかを考慮してください。

のモニタリング

  • status.nodes フィールドを定期的にモニタリングして、必要なキャパシティが維持されていることを確認します。

  • 実際のノード数が目的のレプリカから逸脱した場合に備えてアラートを設定します。

ゾーンの分散:

  • 高可用性を実現するには、静的キャパシティをいくつかのアベイラビリティーゾーンに分散させます。

  • 複数のアベイラビリティーゾーンにまたがる静的キャパシティノードプールを作成すると、EKS 自動モードにより、指定されたゾーンにノードが分散しますが、その分散が均等であるとは限りません。

  • アベイラビリティーゾーン間に想定の範囲内で均等に分散させるには、静的キャパシティノードプールを個別にいくつか作成し、topology.kubernetes.io/zone 要件を使用してそれぞれを特定のアベイラビリティーゾーンに固定します。

  • 3 つのゾーンに 12 個のノードを均等に分散させる必要がある場合は、1 つのノードプールを作成して 3 つのゾーンに 12 個のレプリカを分散させるのではなく、3 つのノードプールを作成してそれぞれに 4 個のレプリカを分散させます。

トラブルシューティング

ノードが目的のレプリカに到達しない:

  • limits.nodes の値が十分かどうかを確認します。

  • 要件がインスタンス選択を過度に制限していないことを確認します。

  • 使用しているインスタンスタイプとリージョンの AWS サービスクォータを確認します。

ノードの置き換えに時間がかかりすぎる:

  • 同時により多くの置き換えができるように中断予算を調整します。

  • PodDisruptionBudgets がノードの終了を妨げていないかどうかを確認します。

ノードが予期せずに終了する:

  • expireAfter と terminationGracePeriod の設定を確認します。

  • 手動によるノードの終了や AWS メンテナンスイベントを確認します。