**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # EKS 自動モードl 用のノードプールを作成する Amazon EKS ノードプールにより、Kubernetes クラスター内のコンピューティングリソースを柔軟に管理できます。このトピックでは、クラスターのスケーリングとリソース使用率を最適化するノードプロビジョニングツールである Karpenter を使用してノードプールを作成および設定する方法を示します。Karpenter の ノードプール リソースを使用すると、インスタンスタイプ、アベイラビリティーゾーン、アーキテクチャ、キャパシティータイプなど、コンピューティングリソースの特定の要件を定義できます。 組み込みの `system` および `general-purpose` ノードプールは変更できません。これらは、有効または無効にすることのみができます。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。 ノードプール の指定により、サポートされているさまざまなラベルと要件を通じて、EKS クラスターのコンピューティングリソースをきめ細かく制御できます。これには EC2 インスタンスカテゴリ、CPU 設定、アベイラビリティーゾーン、アーキテクチャ (ARM64/AMD64)、キャパシティタイプ (スポットまたはオンデマンド) を指定するためのオプションが含まれます。CPU とメモリの使用量のリソース制限を設定して、クラスターが必要な運用境界内に収まるようにすることもできます。 EKS 自動モードl は広く知られている Kubernetes ラベルを活用して、ノードの特性を識別する一貫性のある標準化された方法を提供します。アベイラビリティーゾーンの `topology.kubernetes.io/zone` や CPU アーキテクチャの `kubernetes.io/arch` といったこのラベルは確立された Kubernetes 規則に従います。さらに、EKS 固有のラベル (プレフィックスが `eks.amazonaws.com/`) により、インスタンスタイプ、CPU メーカー、GPU 機能、ネットワーク仕様などの AWS 固有の属性でこの機能が拡張されます。この標準化されたラベル付けシステムにより、既存の Kubernetes ツールとシームレスに統合できると同時に、緊密な AWS インフラストラクチャ統合が提供されます。 ## ノードプール を作成する Amazon EKS クラスターの ノードプール を作成するには次のステップに従います： 1. 必要な NodePool 設定で `nodepool.yaml` という名前の YAML ファイルを作成します。以下のサンプル設定を使用できます。 1. ノードプール をクラスターに適用します： ``` kubectl apply -f nodepool.yaml ``` 1. ノードプール が正常に作成されたことを確認します： ``` kubectl get nodepools ``` 1. (任意 ノードプール のステータスをモニタリングします： ``` kubectl describe nodepool default ``` ノードプール がクラスターに存在する有効な ノードクラス を参照していることを確認します。ノードクラス はコンピューティングリソースの AWS 固有の設定を定義します。詳細については「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。 ## サンプル ノードプール ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: my-node-pool spec: template: metadata: labels: billing-team: my-team spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "eks.amazonaws.com/instance-category" operator: In values: ["c", "m", "r"] - key: "eks.amazonaws.com/instance-cpu" operator: In values: ["4", "8", "16", "32"] - key: "topology.kubernetes.io/zone" operator: In values: ["us-west-2a", "us-west-2b"] - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"] limits: cpu: "1000" memory: 1000Gi ``` ## EKS Auto Mode でサポートされているラベル EKS 自動モードl は以下の広く知られてるラベルをサポートしています。 **注記** EKS 自動モードl は Karpenter とは異なるラベルを使用します。EC2 マネージドインスタンスに関連するラベルは`eks.amazonaws.com` で始まります。 | ラベル | 例 | 説明 | | --- | --- | --- | | topology.kubernetes.io/zone | us-east-2a | AWS リージョン | | node.kubernetes.io/インスタンス型 | g4dn.8xlarge | AWS インスタンスタイプ | | kubernetes.io/arch | amd64 | アーキテクチャはインスタンスの [GOARCH 値](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)によって定義されます | | karpenter.sh/capacity-type | spot | キャパシティータイプには `spot`、`on-demand` などがあります | | eks.amazonaws.com/instance-hypervisor | nitro | 特定のハイパーバイザーを使用するインスタンスタイプ | | eks.amazonaws.com/compute-type | 自動 | EKS 自動モードl マネージドノードを識別します | | eks.amazonaws.com/instance-encryption-in-transit-supported | 真 | 転送中の暗号化をサポートする (またはサポートしない) インスタンスタイプ | | eks.amazonaws.com/instance-category | g | 同じカテゴリのインスタンスタイプ、通常は生成番号の前の文字列 | | eks.amazonaws.com/instance-generation | 4 | インスタンスカテゴリ内のインスタンスタイプ生成番号 | | eks.amazonaws.com/instance-family | g4dn | プロパティが類似していてリソース量が異なるインスタンスタイプ | | eks.amazonaws.com/instance-size | 8xlarge | リソース量が類似していてプロパティが異なるインスタンスタイプ | | eks.amazonaws.com/instance-cpu | 32 | インスタンスにおける CPU の数 | | eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU メーカーの名前 | | eks.amazonaws.com/instance-memory | 131072 | インスタンスのメモリのメビバイト数 | | eks.amazonaws.com/instance-ebs-bandwidth | 9500 | インスタンスで使用できる EBS の[最大メガビット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance)数 | | eks.amazonaws.com/instance-network-bandwidth | 131072 | インスタンスで使用可能な[ベースラインメガビット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)数 | | eks.amazonaws.com/instance-gpu-name | t4 | インスタンス上の GPU の名前 (使用可能な場合) | | eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU メーカーの名前 | | eks.amazonaws.com/instance-gpu-count | 1 | インスタンスにおける GPU の数 | | eks.amazonaws.com/instance-gpu-memory | 16384 | GPU のメモリのメビバイト数 | | eks.amazonaws.com/instance-local-nvme | 900 | インスタンス上のローカル nvme ストレージのギビバイト数 | **注記** EKS Auto Mode は特定のインスタンスのみをサポートし、最小サイズ要件があります。詳細については、「[EKS Auto Mode でサポートされているインスタンスリファレンス](automode-learn-instances.md#auto-supported-instances)」を参照してください。 ## EKS Auto Mode でサポートされていないラベル EKS 自動モードl は次のラベルをサポートしていません。 + EKS 自動モードは Linux のみをサポートしています + `node.kubernetes.io/windows-build` + `kubernetes.io/os` ## 組み込みノードプールを無効にする カスタムノードプールを作成する場合は、組み込みノードプールを無効にすることができます。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。 ## 組み込みノードプールがないクラスター 組み込みノードプールがないクラスターを作成できます。これは、組織がカスタマイズしたノードプールを作成している場合に役立ちます。 **注記** 組み込みノードプールなしでクラスターを作成すると、`default` NodeClass は自動的にプロビジョニングされません。カスタム NodeClass を作成する必要があります。詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。 **概要：** 1. `nodePools` と `nodeRoleArn` の両方の値を空にして、EKS クラスターを作成します。 + eksctl `autoModeConfig` の例: ``` autoModeConfig: enabled: true nodePools: [] # Do not set a nodeRoleARN ``` 詳細については、[eksctl CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-eksctl.md)を参照してください。 1. ノードロール ARN を使用してカスタムノードクラスを作成します + 詳細については、[Amazon EKS のノードクラスを作成する](create-node-class.md)を参照してください。 1. カスタムノードクラスのアクセスエントリを作成します + 詳細については、[ノードクラスのアクセスエントリを作成する](create-node-class.md#auto-node-access-entry)を参照してください。 1. 前述のように、カスタムノードプールを作成します。 ## 中断 NodePool を介してノードを中断するように、EKS Auto Mode を複数の方法で設定できます。`spec.disruption.consolidationPolicy`、`spec.disruption.consolidateAfter`、または `spec.template.spec.expireAfter` を使用できます。NodePool の `spec.disruption.budgets` を使用して、EKS Auto Mode の中断をレート制限することもできます。中断される時間枠と同時ノード数を制御することもできます。この動作を設定する手順については、Karpenter ドキュメントの「[Disruption](https://karpenter.sh/docs/concepts/disruption/)」を参照してください。 ノードプールの中断は、次の目的で設定できます。 + インスタンスの使用率が低いタイミングを特定し、ワークロードを統合する。 + ノードプールの中断予算を作成して、ドリフト、空、統合が理由でのノードの終了をレート制限する。 デフォルトでは、EKS Auto Mode では以下が行われます。 + 使用率が低いインスタンスを統合します。 + 336 時間後にインスタンスを終了します。 + ノードの 10% の単一の中断予算を設定します。 + 新しい Auto Mode AMI がリリースされたときに、ドリフトを理由にノードを置き換えることを許可します。これは、およそ週に 1 回行われます。 ## 終了猶予期間 EKS Auto NodePool で `terminationGracePeriod` を明示的に定義していない場合、関連付けた NodeClaim に 24 時間 (デフォルト) の終了猶予期間が自動的に適用されます。EKS Auto のカスタム NodePool 設定では `terminationGracePeriod` がデフォルトであることを確認できませんが、NodeClaim には、このデフォルト値が表示されます。猶予期間を NodePool で明示的に設定済みか、NodeClaim でデフォルト設定を行ったかに関係なく、この機能には一貫性があり、予測可能なノード終了動作がクラスター全体で維持されます。