**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # EKS Auto Mode での静的キャパシティノードプール Amazon EKS Auto Mode は、静的キャパシティノードプールをサポートしており、ポッドの需要に関係なく決まった数のノードを維持します。静的キャパシティノードプールは、予測可能なキャパシティ、リザーブドインスタンス、または一貫したインフラストラクチャフットプリントの維持が求められる特定のコンプライアンス要件を必要とするワークロードに有用です。 ポッドスケジューリングの需要に基づいてスケールする動的ノードプールとは異なり、静的キャパシティノードプールでは設定したノードの数が維持されます。 ## 静的キャパシティノードプールを設定する 静的キャパシティノードプールを作成するには、NodePool 仕様に `replicas` フィールドを設定します。`replicas` フィールドでは、ノードプールが維持するノードの正確な数を定義します。`replicas` の設定方法については、「[例](#static-capacity-examples)」を参照してください。 ## 静的キャパシティノードプールに関する考慮事項 静的キャパシティノードプールには、重要な制約と動作がいくつかあります。 **設定に関する制約:** + **モードを切り替えることができない**: ノードプールで `replicas` を設定したら、以後削除することはできません。ノードプールでは、静的モードと動的モードとを切り替えることができません。 + **リソースが制限されている**: 制限セクションでは、`limits.nodes` フィールドのみがサポートされています。CPU とメモリに関する制限は適用されません。 + **重みフィールドがない**: ノードの選択が優先度に基づいていないため、静的キャパシティノードプールに `weight` フィールドを設定することができません。 **オペレーション動作:** + **統合対象外**: 静的キャパシティプールのノードは、統合対象と見なされません。 + **スケールオペレーション**: スケールオペレーションでは、ノード中断の予算はバイパスされますが、PodDisruptionBudgets は引き続き考慮されます。 + **ノードの置き換え**: 設定に基づいてドリフト (AMI アップデートなど) と有効期限が発生した場合は、ノードが置き換えられます。 ## ベストプラクティス **容量プランニング:** + `limits.nodes` を `replicas` よりも高い値に設定すると、ノードの置き換えオペレーション中に一時的にスケールできるようになります。 + 制限を設定するときは、ノードドリフトや AMI アップデートに必要な最大キャパシティを考慮してください。 **インスタンス選択:** + リザーブドインスタンスがある場合や特定のハードウェア要件がある場合は、特定のインスタンスタイプを使用します。 + 制限を過度に厳しくしてスケール中にインスタンスの可用性が制限されるような要件は避けてください。 **中断の管理:** + 可用性とメンテナンスオペレーションとのバランスが取れるように、適切な中断の予算を設定します。 + 予算の割合を設定するときは、アプリケーションでノードの置き換えをどの程度許容するかを考慮してください。 **モニタリング:** + `status.nodes` フィールドを定期的にモニタリングして、必要なキャパシティが維持されていることを確認します。 + 実際のノード数が目的のレプリカから逸脱した場合に備えてアラートを設定します。 **ゾーンの分散:** + 高可用性を実現するには、静的キャパシティをいくつかのアベイラビリティーゾーンに分散させます。 + 複数のアベイラビリティーゾーンにまたがる静的キャパシティノードプールを作成すると、EKS Auto Mode により、指定されたゾーンにノードが分散しますが、その分散が均等であるとは限りません。 + アベイラビリティーゾーン間に想定の範囲内で均等に分散させるには、静的キャパシティノードプールを個別にいくつか作成し、`topology.kubernetes.io/zone` 要件を使用してそれぞれを特定のアベイラビリティーゾーンに固定します。 + 3 つのゾーンに 12 個のノードを均等に分散させる必要がある場合は、1 つのノードプールを作成して 3 つのゾーンに 12 個のレプリカを分散させるのではなく、3 つのノードプールを作成してそれぞれに 4 個のレプリカを分散させます。 ## 静的キャパシティノードプールをスケールする `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` の数と一致する必要があります。 ## トラブルシューティング **ノードが目的のレプリカに到達しない:** + `limits.nodes` の値が十分かどうかを確認します。 + 要件がインスタンス選択を過度に制限していないことを確認します。 + 使用しているインスタンスタイプとリージョンの AWS サービスクォータを確認します。 **ノードの置き換えに時間がかかりすぎる:** + 同時により多くの置き換えができるように中断予算を調整します。 + PodDisruptionBudgets がノードの終了を妨げていないかどうかを確認します。 **ノードが予期せずに終了する:** + `expireAfter` と `terminationGracePeriod` の設定を確認します。 + 手動によるノードの終了や AWS メンテナンスイベントを確認します。 ## 例 ### 基本的な静的キャパシティノードプール ``` 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% ``` ### キャパシティ予約による静的キャパシティ 以下の例は、EC2 キャパシティ予約で静的キャパシティノードプールを使用する方法を示しています。EKS Auto Mode での EC2 キャパシティ予約の使用の詳細については、「[EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する](auto-odcr.md)」を参照してください。 `capacityReservationSelectorTerms` を定義する `NodeClass` ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-reservation-nodeclass spec: role: AmazonEKSNodeRole securityGroupSelectorTerms: - id: sg-0123456789abcdef0 subnetSelectorTerms: - id: subnet-0123456789abcdef0 capacityReservationSelectorTerms: - id: cr-0123456789abcdef0 ``` 上記の `NodeClass` を参照し、`karpenter.sh/capacity-type: reserved` を使用する `NodePool` ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: static-capacity-reservation-nodepool spec: replicas: 5 limits: nodes: 8 # Allow scaling up to 8 during operations template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-reservation-nodeclass requirements: - key: karpenter.sh/capacity-type operator: In values: ['reserved'] ```