**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# マネージドノードグループを使用してノードライフサイクルを簡素化する
Amazon EKS マネージド型ノードグループは、Amazon EKS Kubernetes クラスターのノード (Amazon EC2 インスタンス) のプロビジョニングとライフサイクル管理を自動化します。
Amazon EKS マネージド型ノードグループでは、Kubernetes アプリケーションを実行するためのコンピューティング性能を提供する Amazon EC2 インスタンスを個別にプロビジョニングまたは登録する必要はありません。1 回の操作で、クラスターのノードを作成、自動的に更新、または終了できます。ノードを更新し、終了させることで、ノードを自動的にドレーンし、アプリケーションを利用できる状態にしておきます。
すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。各ノードグループは、定義された複数のアベイラビリティーゾーンで実行できます。
マネージド型ノードグループは、ノードのヘルスを継続的にモニタリングするノード自動修復をオプションで利用することもできます。検出された問題に自動的に対応し、可能な場合はノードを置き換えます。これにより、最小限の手動操作でクラスターの全体的な可用性が向上します。詳細については、「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。
Amazon EKS コンソール、`eksctl`、AWS CLI、AWS API、または AWS CloudFormation を含む Infrastructure as Code ツールを使用し、新規または既存のクラスターにマネージド型ノードグループを追加できます。マネージド型ノードグループの一部として起動されたノードは、自動的に Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) によって自動検出用にタグ付けされます。ノードグループを使用して、Kubernetes ラベルをノードに適用し、いつでも更新できます。
Amazon EKS マネージド型ノードグループの使用に追加料金はかかりません。お支払いいただくのはプロビジョニングした AWS リソースの分だけです。これには、Amazon EC2 インスタンス、Amazon EBS ボリューム、Amazon EKS クラスター時間、その他の AWS インフラストラクチャが含まれます。最低料金や前払いの義務は発生しません。
新しい Amazon EKS クラスターおよびマネージド型ノードグループの使用を開始するには、「[Amazon EKS の使用を開始する – AWS マネジメントコンソール と AWS CLI](getting-started-console.md)」を参照してください。
既存のクラスターにマネージド型ノードグループを追加するには、「[クラスターのマネージドノードグループを作成する](create-managed-node-group.md)」を参照してください。
## マネージド型ノードグループの概念
+ Amazon EKS マネージド型ノードグループは、Amazon EC2 インスタンスを作成し、管理します。
+ すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。さらに、Amazon EC2 インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。
+ マネージド型ノードグループの Auto Scaling グループは、グループの作成時に指定するすべてのサブネットにまたがります。
+ Amazon EKS は、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) の使用を設定するようにマネージド型ノードグループリソースをタグ付けします。
**重要**
Amazon EBS ボリュームによってバックアップされ、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、`--balance-similar-node-groups` 機能を有効にする必要があります。
+ カスタム起動テンプレートを使用すると、マネージド型ノードをデプロイするときに、柔軟性とカスタマイズのレベルを向上させることができます。例えば、追加の `kubelet` 引数を指定して、カスタム AMI を使用できます。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。マネージド型ノードグループを最初に作成するときにカスタム起動テンプレートを使用しない場合は、自動生成された起動テンプレートを使用できます。自動生成されたテンプレートを手動で変更しないでください。エラーが発生します。
+ Amazon EKS は、マネージド型ノードグループで CVE およびセキュリティパッチの責任共有モデルに従います。マネージド型ノードが Amazon EKS 最適化 AMI を実行する場合、バグや問題が報告されると、Amazon EKS が AMI のパッチ適用バージョンの構築を担当します。修正を公開できます。ただし、これらのパッチが適用された AMI バージョンのマネージド型ノードグループへのデプロイはユーザーが担当します。マネージド型ノードでカスタム AMI を実行する場合、バグや問題が報告され、AMI をデプロイする場合は、ユーザーがパッチ適用バージョンの構築を担当します。詳細については、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。
+ Amazon EKS マネージド型ノードグループは、パブリックサブネットとプライベートサブネットの両方で起動できます。2020 年 4月 22 日 以降にパブリックサブネットでマネージド型ノードグループを起動した場合、インスタンスがクラスターに正常に参加するには、サブネットで `MapPublicIpOnLaunch` を true に設定する必要があります。パブリックサブネットが `eksctl`、または 2020 年 3 月 26 日以降に [Amazon EKS が販売した AWS CloudFormation テンプレート](creating-a-vpc.md)を使用して作成された場合、この設定はすでに true に設定されています。パブリックサブネットが 2020 年 3 月 26 日 より前に作成されている場合は、設定を手動で変更する必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。
+ マネージド型ノードグループをプライベートサブネットにデプロイする場合、Amazon ECR にアクセスしてコンテナイメージをプルできることを確認します。これを行うには、NAT ゲートウェイをサブネットのルートテーブルに接続するか、次の [AWS PrivateLink VPC エンドポイント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)を追加します。
+ Amazon ECR API のエンドポイントインターフェイス — `com.amazonaws.region-code.ecr.api`
+ Amazon ECR Docker レジストリ API のエンドポイントインターフェイス — `com.amazonaws.region-code.ecr.dkr`
+ Amazon S3 ゲートウェイのエンドポイント - `com.amazonaws.region-code.s3`
その他の一般的に使用されるサービスとエンドポイントについては、「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。
+ マネージドノードグループは、[AWS Outposts](eks-outposts.md) または [AWS Wavelength](https://docs.aws.amazon.com/wavelength/) にはデプロイできません。マネージドノードグループは、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) で作成できます。詳細については、「[AWS Local Zones を使用して低レイテンシーの EKS クラスターを起動する](local-zones.md)」を参照してください。
+ 1 つのクラスター内に複数のマネージド型ノードグループを作成できます。例えば、一部のワークロード用に、標準 Amazon EKS 最適化 Amazon Linux AMI を使用するノードグループを作成し、GPU サポートを必要とするワークロード用に GPU バリアントを使用する別のノードグループを作成できます。
+ マネージド型ノードグループで [Amazon EC2 インスタンスのステータスチェック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html)に障害が発生した場合、Amazon EKS は問題の診断に役立つエラーコードを返します。詳細については、「[マネージド型ノードグループのエラー](troubleshooting.md#troubleshoot-managed-node-groups)」を参照してください。
+ Amazon EKS は、マネージド型ノードグループインスタンスに Kubernetes ラベルを追加します。これらの Amazon EKS 提供のラベルには、プレフィックス `eks.amazonaws.com` が付きます。
+ Amazon EKS は、終了または更新時に Kubernetes API を使用してノードを自動的にドレーンします。
+ `AZRebalance` を使用してノードを終了、または目的のノード数を減らす際には、ポッドの停止状態の予算は考慮されません。これらのアクションはノード内にある Pod を削除しようとします。ただし、15 分が経過すると、ノード内のすべての Pod が終了しているかどうかにかかわらず、ノードは終了します。ノードが終了するまでの期間を延長するには、Auto Scaling グループにライフサイクルフックを追加します。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[ライフサイクルフックの追加](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html)」を参照してください。
+ スポット中断通知またはキャパシティリバランス通知を受け取った後、ドレインプロセスを正しく実行するには、`CapacityRebalance` を `true` に設定する必要があります。
+ マネージドノードグループを更新すると、Pod に設定した Pod 中断予算が考慮されます。詳細については、「[ノードの更新の各フェーズを理解する](managed-node-update-behavior.md)」を参照してください。
+ Amazon EKS マネージド型ノードグループの使用に、追加料金はかかりません。プロビジョニングした AWS リソースに対してのみ料金が発生します。
+ ノードの Amazon EBS ボリュームを暗号化する場合は、起動テンプレートを使用してノードをデプロイできます。起動テンプレートを使用せずに、暗号化された Amazon EBS ボリュームを持つマネージド型ノードをデプロイするには、アカウントに作成された新しい Amazon EBS ボリュームをすべて暗号化してください。詳細については、*「Amazon EC2 ユーザーガイド*」の「[Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)」を参照してください。
## マネージド型ノードグループのキャパシティータイプ
マネージド型ノードグループを作成する場合、キャパシティータイプをオンデマンドまたはスポットのいずれかから選択できます。Amazon EKS は、Amazon EC2 Auto Scaling グループを使用して、マネージド型ノードグループをデプロイします。これにはオンデマンドのみか、Amazon EC2 スポットインスタンスのみが含まれます。単一の Kubernetes クラスター内で、耐障害性のあるアプリケーションの Pod をスポットのマネージド型ノードグループにスケジュールし、非フォールトトレラントなアプリケーションの Pod をオンデマンドのノードグループにスケジュールできます。デフォルトでは、マネージド型ノードグループはオンデマンド Amazon EC2 インスタンスをデプロイします。
### オンデマンド
オンデマンドインスタンスでは、長期契約なしで、コンピューティング性能に対して秒単位で支払います。
デフォルトでは、**キャパシティータイプ**を指定しない場合、マネージド型ノードグループはオンデマンドインスタンスでプロビジョニングされます。マネージド型ノードグループは、ユーザーの代わりに Amazon EC2 Auto Scaling グループを次のように設定します。
+ オンデマンドキャパシティーをプロビジョニングするための配分戦略は、`prioritized` に設定されます。マネージド型ノードグループは、API 内部で渡されたインスタンスタイプの優先度を使用して、オンデマンドキャパシティーを満たすときに最初に使用するインスタンスタイプを決定します。例えば、3 つのインスタンスタイプを `c5.large`、`c4.large`、`c3.large` の順序で指定するとします。オンデマンドインスタンスが起動されると、マネージド型ノードグループは `c5.large`、`c4.large`、`c3.large` の順でオンデマンドキャパシティーを満たします。詳しくは、*Amazon EC2 Auto Scaling ユーザーガイド*の [Amazon EC2 Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)を参照してください。
+ Amazon EKS は、キャパシティータイプを `eks.amazonaws.com/capacityType: ON_DEMAND` に指定しているマネージド型ノードグループ内のすべてのノードに、次の Kubernetes ラベルを追加します。このラベルを使用すると、オンデマンドノードで、ステートフルまたは非フォールトトレラントなアプリケーションをスケジュールできます。
### Spot
Amazon EC2 スポットインスタンスは、オンデマンドの料金から大きな割引で提供される、Amazon EC2 の予備容量です。Amazon EC2 スポットインスタンスは、EC2 から容量の返却を求められると 2 分間の中断通知をもって中断されることがあります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)」を参照してください。Amazon EC2 スポットインスタンスを使用してマネージド型ノードグループを構成し、Amazon EKS クラスターで実行されているコンピューティングノードのコストを最適化できます。
マネージド型ノードグループ内でスポットインスタンスを使用するには、キャパシティータイプを `spot` に設定してマネージド型ノードグループを作成してください。マネージド型ノードグループは、ユーザーの代わりに Amazon EC2 Auto Scaling グループを設定し、次のようなスポットベストプラクティスを適用します。
+ Spot ノードが最適な Spot キャパシティプールにプロビジョニングされるように、割り当て戦略を以下のいずれかに設定します。
+ `price-capacity-optimized` (PCO) – Kubernetes バージョン `1.28` 以降のクラスターに新しいノードグループを作成すると、割り当てストラテジーは `price-capacity-optimized` に設定されます。ただし、Amazon EKS マネージドノードグループが PCO をサポートし始める前に `capacity-optimized` で作成済みのノードグループの割り当て戦略は変更されません。
+ `capacity-optimized` (CO) – Kubernetes バージョン `1.27` 以前のクラスターに新しいノードグループを作成すると、割り当て戦略は `capacity-optimized` に設定されます。
容量を割り当てるために利用可能なスポットキャパシティープールの数を増やすには、複数のインスタンスタイプを使用するようにマネージド型ノードグループを設定します。
+ スポットノードが中断するリスクが高い場合に、Amazon EKS がスポットノードを適切にドレーンおよび再調整して、アプリケーションの中断を最小限に抑えられるように、Amazon EC2 Spot Capacity Rebalancing が有効化されています。詳細については、*Amazon EC2 Auto Scaling ユーザーガイド*の [Amazon EC2 Auto Scaling キャパシティーの再調整](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html)を参照してください。
+ スポットノードが再調整の推奨事項を受け取ると、Amazon EKS は自動的に新しい代替スポットノードの起動を試みます。
+ 代替スポットノードが `Ready` 状態になる前にスポットの 2 分間の中断通知が到着すると、Amazon EKS は再調整に関する推奨事項を受け取ったスポットノードのドレーンを開始します。Amazon EKS はベストエフォートベースでノードをドレインします。そのため、Amazon EKS が既存のノードをドレインする前に、代替ノードがクラスターに参加するのを待機するという保証はありません。
+ 代替スポットノードがブートストラップされ、Kubernetes 上で `Ready` 状態になると、Amazon EKS は再調整に関する推奨事項を受信したスポットノードを遮断し、ドレインします。スポットノードを遮断すると、サービスコントローラーがこのスポットノードに新しいリクエストを送信しないようにします。正常でアクティブなスポットノードのリストからも削除されます。スポットノードをドレインすると、実行中の Pod が適切に削除されます。
+ Amazon EKS は、キャパシティータイプを `eks.amazonaws.com/capacityType: SPOT` に指定しているマネージド型ノードグループ内のすべてのノードに、次の Kubernetes ラベルを追加します。このラベルを使用して、スポットノードで耐障害性のあるアプリケーションをスケジュールできます。
**重要**
EC2 は、スポットインスタンスを終了する 2 分前に[スポットの中断通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)を発行します。ただし、スポットノード上のポッドは、正常なシャットダウンのために 2 分間すべてを確保できない場合があります。EC2 が通知を発行すると、Amazon EKS がポッドのエビクションを開始するまでに遅延が発生します。エビクションは Kubernetes API サーバーを保護するために順次実行されるため、複数のスポット回収が同時に発生した場合、一部のポッドではエビクション通知の受信が遅れることがあります。特にポッド密度が高いノード上、同時回収中、または長い終了猶予期間を使用している場合、ポッドは終了シグナルを受信せずに強制終了される場合があります。スポットワークロードでは、中断耐性のあるアプリケーションを設計し、30 秒以下の終了猶予期間を使用し、長時間実行される preStop フックを回避し、ポッドエビクションメトリクスをモニタリングして、クラスターで実際に適用される猶予期間を把握することをお勧めします。正常な終了が保証される必要があるワークロードについては、代わりにオンデマンドキャパシティーを使用することをお勧めします。
オンデマンドキャパシティーとスポットキャパシティーのどちらでノードグループをデプロイするかを決定するときは、次の条件を考慮する必要があります。
+ スポットインスタンスは、ステートレスかつフォールトトレラントで、柔軟性の高いアプリケーションに適しています。これには、バッチトレーニングワークロード、機械学習トレーニングワークロード、Apache Spark などのビッグデータ ETL、キュー処理アプリケーション、ステートレス API エンドポイントなどがあります。スポットは Amazon EC2 の予備容量であり、時間の経過とともに変化する可能性があるため、中断されても問題ないワークロードには、スポットキャパシティーを使用することをお勧めします。具体的には、スポット容量は、必要な容量が使用できない期間を許容できるワークロードに適しています。
+ 非フォールトトレラントなアプリケーションには、オンデマンドを使用することをお勧めします。これには、モニタリングツールやオペレーションツールなどのクラスター管理ツール、`StatefulSets` を必要とするデプロイ、データベースなどのステートフルなアプリケーションなどが含まれます。
+ スポットインスタンスの使用中にアプリケーションの可用性を最大化するには、スポットのマネージド型ノードグループが複数のインスタンスタイプを使用するように構成することをお勧めします。複数のインスタンスタイプを使用する場合は、次のルールを適用することをお勧めします。
+ マネージド型ノードグループ内で [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用している場合、同じサイズの vCPU とメモリリソースを持つインスタンスタイプを柔軟に組み合わせて使用することをお勧めします。これは、クラスター内のノードが期待どおりにスケールされるようにするためです。例えば、4 つの vCPU と 8 GiB のメモリが必要な場合は、`c3.xlarge`、`c4.xlarge`、`c5.xlarge`、`c5d.xlarge`、`c5a.xlarge`、`c5n.xlarge`、またはその他の同等なインスタンスタイプを使用してください。
+ アプリケーションの可用性を高めるために、複数のスポットマネージド型ノードグループをデプロイすることをお勧めします。これを行うには、各グループが、同じ vCPU とメモリリソースを持つ、インスタンスタイプの柔軟な組み合わせを使用する必要があります。例えば、4 つの vCPU および 8 GiB のメモリが必要な場合は、`c3.xlarge`、`c4.xlarge`、`c5.xlarge`、`c5d.xlarge`、`c5a.xlarge`、`c5n.xlarge`、または他の同等なインスタンスタイプのマネージド型ノードグループを 1 つ作成し、`m3.xlarge`、`m4.xlarge`、`m5.xlarge`、`m5d.xlarge`、`m5a.xlarge`、`m5n.xlarge`、または他の同等なインスタンスタイプで 2 つ目のマネージド型ノードグループを作成することをお勧めします。
+ カスタム起動テンプレートを使用しているスポットキャパシティータイプでノードグループをデプロイする場合、API を使用して複数のインスタンスタイプを渡します。起動テンプレートを使って 1 つのインスタンスタイプを渡さないでください。起動テンプレートを使用したノードグループのデプロイについての詳細は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」をご覧ください。
# クラスターのマネージドノードグループを作成する
このトピックでは、Amazon EKS クラスターに登録しているノードの、Amazon EKS マネージド型ノードグループを起動する方法を説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。
Amazon EKS マネージド型ノードグループを初めて起動する場合は、[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従うことをお勧めします。このガイドでは、ノードを使用して Amazon EKS クラスターを作成するためのウォークスルーを説明します。
**重要**
Amazon EKS ノードは、標準の Amazon EC2 インスタンスです。通常の Amazon EC2 料金に基づいて請求されます。詳細については、[Amazon EC2 の料金表](https://aws.amazon.com/ec2/pricing/)を参照してください。
AWS Outposts または AWS Wavelength が有効になっている AWS リージョンでは、マネージドノードを作成できません。ユーザーは代わりに、セルフマネージド型ノードを作成できます。詳細については[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)、[セルフマネージド Microsoft Windows ノードの作成](launch-windows-workers.md)、および[セルフマネージド Bottlerocket ノードの作成](launch-node-bottlerocket.md)を参照してください。また、Outpost に自己管理型 Amazon Linux ノードグループを作成することもできます。詳細については、「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。
Amazon EKS 最適化 Linux または Bottlerocket に含まれる `bootstrap.sh` ファイル用に [AMI ID を指定](launch-templates.md#launch-template-custom-ami)しない場合、マネージドノードグループは `maxPods` の値に最大数を適用します。vCPU が 30 未満のインスタンスの場合、最大数は `110` です。30 を超える vCPU を持つインスタンスの場合、最大数は `250` に跳ね上がります。この適用は、`maxPodsExpression` を含む他の `maxPods` 設定を上書きします。`maxPods` の決定方法とカスタマイズ方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
+ ノードが使用する既存の IAM ロール。作成する場合は「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。この役割に VPC CNI のポリシーがどちらも含まれていない場合、VPC CNI ポッドには以下の別の役割が必要です。
+ (オプションですが推奨) 必要な IAM ポリシーがアタッチされた独自の IAM ロールで構成された Amazon VPC CNI plugin for Kubernetes アドオン。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
+ 「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」に記載されている考慮事項に精通していること。選択したインスタンスタイプによってはクラスターと VPC に関する追加の前提条件がある場合もあります。
+ Windows マネージドノードグループを追加するには、まずクラスターの Windows サポートを有効にする必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。
マネージド型ノードグループを作成するには、以下のいずれかを使用します。
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [AWS マネジメントコンソール](#console_create_managed_nodegroup)
## `eksctl`
**eksctl を使用してマネージド型ノードグループを作成する**
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. (オプション) **[AmazonEKS\$1CNI\$1Policy]** マネージド IAM ポリシーが [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合は、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. カスタム起動テンプレートの有無にかかわらず、マネージド型ノードグループを作成します。起動テンプレートを手動で指定すると、ノードグループをより詳細にカスタマイズできます。たとえば、カスタム AMI をデプロイしたり、Amazon EKS 最適化 AMI の `boostrap.sh` スクリプトの引数を指定したりできます。すべての使用可能なオプションとデフォルト値の一覧を表示するには、次のコマンドを入力します。
```
eksctl create nodegroup --help
```
次のコマンドで、*my-cluster* をクラスターの名前に置き換え、*my-mng* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
**重要**
マネージド型ノードグループを最初に作成する際にカスタム起動テンプレートを使用しない場合は、後でノードグループに使用しないでください。カスタム起動テンプレートを指定しなかった場合、システムにより起動テンプレートが自動生成されます。これを手動で変更することはお勧めしません。自動生成された起動テンプレートを手動で変更すると、エラーが発生する場合があります。
**起動テンプレートなし**
`eksctl` は、デフォルトの Amazon EC2 起動テンプレートをアカウント内に作成し、指定したオプションに基づいて作成した起動テンプレートを使用してノードグループをデプロイします。`--node-type` の値を指定する前に「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
*ami-family* を許可されているキーワードに置き換えます。詳細については、「`eksctl` ドキュメント」の「[Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family)」(ノード AMI ファミリーの設定) を参照してください。*my-key* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。
**注記**
Windows の場合、このコマンドは SSH を有効にしません。代わりに Amazon EC2 キーペアをインスタンスに関連付け、インスタンスに RDP できるようにします。
Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。Linux の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。Windows の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。
次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
IMDS への Pod のアクセスをブロックするには、`--disable-pod-imds` オプションを次のコマンドに追加します。
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
ご使用のインスタンスでは、オプションで大量の IP アドレスをポッドに割り当てることや、インスタンスではなく CIDR ブロックから Pod に IP アドレスを割り当てることができます。また、そのインスタンスはインターネットにアクセスできないクラスターにデプロイすることも可能です。詳細については、追加オプションの[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)、[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)および [インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md) を参照して、前のコマンドに追加します。
マネージドノードグループは、インスタンスタイプに基づいて、ノードグループの各ノードで実行できる Pod の最大数に対して 1 つの値を計算して適用します。異なるインスタンスタイプを持つノードグループを作成する場合、すべてのインスタンスタイプで計算された最小値が、ノードグループ内のすべてのインスタンスタイプで実行できる Pod の最大数として適用されます。マネージドノードグループは、で参照するスクリプトを使用して値を計算します。
**起動テンプレートの使用**
起動テンプレートがすでに存在している必要があり、また、「[起動テンプレート設定の基本](launch-templates.md#launch-template-basics)」で指定されている要件を満たしている必要があります。次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
IMDS への Pod のアクセスをブロックするには、起動テンプレートで必要な設定を行います。
1. 次のコンテンツをデバイスにコピーします。サンプル値を置き換えたら、変更したコマンドを実行して `eks-nodegroup.yaml` ファイルを作成します。起動テンプレートなしでデプロイしたときに指定したいくつかの設定は、起動テンプレートに移動されます。`version` を指定しない場合は、テンプレートのデフォルトバージョンが使用されます。
```
cat >eks-nodegroup.yaml <
**AWS マネジメントコンソール を使用してマネージド型ノードグループを作成する**
1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。まだ `ACTIVE` ではないクラスターにはマネージド型ノードグループを作成できません。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. マネージド型ノードグループを作成するクラスターの名前を選択します。
1. **[コンピューティング]** タブを選択します。
1. **[ノードグループを追加]** を選択します。
1. **[ノードグループの設定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。
+ **[名前]** – マネージド型ノードグループの一意の名前を入力します。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
+ **[ノード IAM ロール]** – ノードグループで使用するノードインスタンスロールを選択します。詳細については、「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。
**重要**
クラスターの作成に使用したロールは使用できません。
セルフマネージド型ノードグループによって現在使用されていないロールを使用することをお勧めします。それ以外の場合は、新しいセルフマネージド型ノードグループで使用します。詳細については、「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」を参照してください。
+ **起動テンプレートを使用する** — (オプション) 既存の起動テンプレートを使用するかどうかを選択します。**[起動テンプレート名]** を選択します。次に、**[起動テンプレートのバージョン]** を選択します。バージョンを選択しない場合、Amazon EKS はテンプレートのデフォルトのバージョンを使用します。起動テンプレートを使用すると、ノードグループを詳細にカスタマイズできます。これにより、カスタム AMI のデプロイ、ポッドへの大量の IP アドレスの割り当て、インスタンスのブロックとは異なる CIDR ブロックからのポッドに対する IP アドレスの割り当て、さらにアウトバウンドのインターネットアクセスのないクラスターに対するノードのデプロイが可能になります。詳細については[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)、[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)、および[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)を参照してください。
起動テンプレート は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」の要件を満たしている必要があります。独自の起動テンプレートを使用しない場合、Amazon EKS API はデフォルトの Amazon EC2 起動テンプレートをアカウントに作成し、デフォルトの起動テンプレートを使用してノードグループをデプロイします。
[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を実装する場合は、AWS サービスへのアクセス許可を必要とするすべての Pod に必要なアクセス許可を直接割り当て、クラスター内の Pod が、現在の AWS リージョンを取得するなどの理由で IMDS にアクセスしないようにします。また、起動テンプレートでホストネットワークを使用しないポッドの、IMDS へのアクセスを無効にすることもできます。詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
+ [**Kubernetes ラベル**]: (オプション) マネージド型ノードグループ内のノードに Kubernetes ラベルを適用するように選択できます。
+ **Kubernetes テイント** - (オプション) 管理対象ノードグループ内のノードに Kubernetes テイントを適用することを選択できます。**[効果]** メニューでの利用可能なオプションは ` NoSchedule `、` NoExecute `、および ` PreferNoSchedule ` です。詳細については、「[レシピ: 特定のノードでポッドがスケジュールされないようにする](node-taints-managed-node-groups.md)」を参照してください。
+ **[タグ]** – (オプション) Amazon EKS マネージド型ノードグループにタグを付けることを選択できます。これらのタグは、Auto Scaling グループやインスタンスなど、ノードグループ内の他のリソースには伝達されません。詳細については、「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。
1. **[コンピューティング構成とスケーリングの設定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。
+ **[AMI タイプ]** – AMI タイプを選択します。Arm インスタンスをデプロイする場合は、デプロイする前に「[Amazon EKS optimized Arm Amazon Linux AMIs](eks-optimized-ami.md#arm-ami)」の考慮事項を確認してください。
前のページで起動テンプレートを指定し、起動テンプレートで AMI を指定した場合は、値を選択できません。テンプレートの値が表示されます。テンプレートで指定された AMI は、「[AMI の指定](launch-templates.md#launch-template-custom-ami)」の要件を満たしている必要があります。
+ **[キャパシティータイプ]** – キャパシティタイプを選択します。キャパシティータイプの選択の詳細については、「[マネージド型ノードグループのキャパシティータイプ](managed-node-groups.md#managed-node-group-capacity-types)」を参照してください。同じノードグループ内で、異なるキャパシティータイプを混在させることはできません。両方のキャパシティータイプを使用したい場合は、キャパシティータイプとインスタンスタイプをそれぞれに持つ、別々のノードグループを作成します。GPU アクセラレーテッドワーカーノードのプロビジョニングとスケーリングについては、「[マネージドノードグループの GPU を予約する](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html)」を参照してください。
+ **[インスタンスタイプ]** – デフォルトで 1 つまたは複数のインスタンスタイプが指定されています。デフォルトのインスタンスタイプを削除するには、インスタンスタイプの右側にある `X` を選択します。マネージド型ノードグループで使用するインスタンスタイプを選択します。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
コンソールには、一般的に使用されるインスタンスタイプのセットが表示されます。表示されてないインスタンスタイプを持つマネージド型ノードグループの作成が必要な場合は、`eksctl`、AWS CLI、AWS CloudFormation、または SDK を使用して、ノードグループを作成します。前のページで起動テンプレートを指定した場合、起動テンプレートでインスタンスタイプを指定する必要があるため、値を選択できません。起動テンプレートの値が表示されます。[**キャパシティータイプ**] で [**スポット**] を選択した場合は、可用性を高めるために、複数のインスタンスタイプを指定することをお勧めします。
+ **[ディスクサイズ]** – ノードのルートボリュームに使用するディスクサイズ (GiB 単位) を入力します。
前のページで起動テンプレートを指定した場合は、値を起動テンプレートで指定する必要があるため、値を選択できません。
+ **[必要なサイズ]** – マネージド型ノードグループが起動時に保持する必要があるノードの現在の数を指定します。
**注記**
Amazon EKS は、ノードグループを自動的にスケールインまたはスケールアウトしません。ただし、これを行うように Kubernetes Cluster Autoscaler を設定することはできます。詳細については、「[AWS の Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)」を参照してください。
+ **[最小サイズ]** – マネージド型ノードグループがスケールインできるノードの最小数を指定します。
+ **[最大サイズ]** – マネージド型ノードグループがスケールアウトできるノードの最大数を指定します。
+ **ノードグループの更新設定** – (オプション) 並行して更新するノードの数または割合を選択できます。これらのノードは、更新中は使用できません。**[使用できない最大値]** で、次のいずれかのオプションを選択し、その **[値]** を指定します:
+ **[数値]** – 並行して更新できるノードグループ内のノード数を選択して指定します。
+ **[パーセンテージ]** – 並行して更新できるノードグループ内のノードの割合を選択して指定します。ノードグループに多数のノードがある場合に便利です。
+ **ノードの自動修復設定** – (オプション) **[ノードの自動修復を有効にする]** チェックボックスを有効にすると、Amazon EKS は検出された問題が発生したときにノードを自動的に置き換えます。詳細については、「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。
1. **[ネットワーキングを指定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。
+ **[サブネット]**: マネージド型ノードを起動するサブネットを選択します。
**重要**
Amazon EBS ボリュームによってバックアップされ、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、`--balance-similar-node-groups` 機能を有効にする必要があります。
**重要**
パブリックサブネットを選択し、クラスターでパブリック API サーバーのエンドポイントのみが有効になっている場合は、サブネットの `MapPublicIPOnLaunch` に `true` をセットして、インスタンスがクラスターに正常に参加できるようにします。サブネットが 2020 年 3 月 26 日以降に `eksctl` または [Amazon EKS で発行された AWS CloudFormation テンプレート](creating-a-vpc.md)を使用して作成された場合は、この設定はすでに `true` に設定されています。サブネットが 2020 年 3 月 26 日より前に `eksctl` または AWS CloudFormation テンプレートを使用して作成されている場合は、設定を手動で変更する必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。
起動テンプレートを使用しており、複数のネットワークインターフェイスを指定している場合には、たとえ `MapPublicIpOnLaunch` が `true` に設定されていても、Amazon EC2 はパブリック `IPv4` アドレスの自動的な割り当てを行いません。このシナリオでノードがクラスターに参加するには、クラスターのプライベート API サーバーエンドポイントを有効にするか、NAT ゲートウェイなどの別の方法によってアウトバウンドインターネットアクセスを提供する、プライベートサブネットでノードを起動する必要があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスの IP アドレス指定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)」を参照してください。
+ **ノードへの SSH アクセスの設定** (オプション)。SSH を有効にすることにより、インスタンスに接続し、問題がある場合に診断情報を収集できます。ノードグループを作成するときは、リモートアクセスを有効にすることを強くお勧めします。ノードグループの作成後にリモートアクセスを有効にすることはできません。
起動テンプレートの使用を選択した場合、このオプションは表示されません。ノードへのリモートアクセスを有効にするには、起動テンプレートでキーペアを指定し、起動テンプレートで指定したセキュリティグループのノードに対して適切なポートが開いていることを確認します。詳細については、「[カスタムセキュリティグループを使用する](launch-templates.md#launch-template-security-groups)」を参照してください。
**注記**
Windows の場合、このコマンドは SSH を有効にしません。代わりに Amazon EC2 キーペアをインスタンスに関連付け、インスタンスに RDP できるようにします。
+ **[SSH キーペア]** (オプション) の場合は、使用する Amazon EC2 SSH キーを選択します。Linux の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。Windows の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。起動テンプレートを使用することを選択した場合、選択することはできません。Bottlerocket AMI を使用するノードグループに Amazon EC2 SSH キーが提供されると、管理コンテナも有効になります。詳細については、GitHub の [Admin container](https://github.com/bottlerocket-os/bottlerocket#admin-container) を参照してください。
+ **[次からの SSH リモートアクセスを許可する]** の場合、特定のインスタンスへのアクセスを制限するには、それらのインスタンスに関連付けられているセキュリティグループを選択します。特定のセキュリティグループを選択しないと、インターネット上のどの場所 (`0.0.0.0/0`) からでも SSH アクセスが許可されます。
1. **[確認と作成]** ページで、マネージド型ノードグループの設定を確認し、**[作成]** を選択してください。
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
1. (GPU ノードのみ) GPU インスタンスタイプと Amazon EKS 最適化高速 AMI を選択した場合は、クラスター上の DaemonSet として [Kubernetes 用の NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)を適用する必要があります。次のコマンドを実行する前に、*vX.X.X* を必要となる [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) バージョンに置き換えます。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
## Kubernetes アドオンをインストールする
ノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックはクラスターの機能を拡張するのに役立ちます。
+ クラスターを作成した [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)は、`kubectl` または AWS マネジメントコンソール を使用して Kubernetes API サーバーを呼び出すことができる唯一のプリンシパルです。他の IAM プリンシパルがクラスターにアクセスできるようにする場合はそれらを追加する必要があります。詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」および「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
+ 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
+ ノードグループ内のノード数を自動的に調整するように Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を設定します。
+ [サンプルアプリケーション](sample-deployment.md)をクラスターにデプロイします。
+ クラスターを管理するための重要なツールを使用して、[クラスターリソースを整理およびモニタリング](eks-managing.md)します。
# クラスターのためにマネージドノードグループを更新する
マネージド型ノードグループの更新を開始すると、Amazon EKS はノードを自動的に更新し、「[ノードの更新の各フェーズを理解する](managed-node-update-behavior.md)」でリストされた手順を完了します。Amazon EKS 最適化 AMI を使用している場合、Amazon EKS は最新のセキュリティパッチとオペレーティングシステムの更新を、最新の AMI リリースバージョンの一部として自動的にノードに適用します。
いくつかのシナリオでは、Amazon EKS マネージド型ノードグループのバージョンや設定を更新すると便利です。
+ Amazon EKS クラスターの Kubernetes バージョンを更新し、同じ Kubernetes バージョンを使用するようにノードを更新する場合。
+ マネージド型ノードグループでは、新しい AMI リリースバージョンを使用できます。AMI バージョンの詳細については、次のセクションを参照してください。
+ [Amazon Linux AMI のバージョン情報を取得する](eks-linux-ami-versions.md)
+ [最適化された Bottlerocket AMI を使用してノードを作成する](eks-optimized-ami-bottlerocket.md)
+ [Windows AMI バージョンに関する情報を取得する](eks-ami-versions-windows.md)
+ マネージド型ノードグループ内のインスタンスの最小数、最大数、または必要な数を調整する場合。
+ マネージド型ノードグループのインスタンスで Kubernetes ラベルを追加または削除する場合。
+ マネージド型ノードグループに AWS タグを追加または削除する場合。
+ カスタム AMI の更新などの設定の変更を伴う、新しいバージョンの起動テンプレートをデプロイする必要があります。
+ Amazon VPC CNI アドオンのバージョン `1.9.0` 以降をデプロイし、プレフィックス委任用のアドオンを有効にし、ノードグループ内の新しい AWS Nitro System インスタンスで大幅に増加した Pod の数をサポートしたい場合。詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
+ Windows ノードの IP プレフィックスの委任を有効にし、ノードグループ内の新しい AWS Nitro System インスタンスで、大幅に増加したポッドをサポートした場合。詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
マネージドノードグループの Kubernetes バージョンに対して、新しい AMI リリースバージョンがある場合は、ノードグループのバージョンを更新して、新しい AMI バージョンを使用することができます。同様に、クラスターがノードグループより新しい Kubernetes バージョンを実行している場合、クラスターの Kubernetes バージョンに一致する最新の AMI リリースバージョンを使用するようにノードグループを更新できます。
スケーリングオペレーションまたは更新によってマネージドノードグループ内のノードが終了すると、そのノードの Pod が最初にドレインされます。詳細については、「[ノードの更新の各フェーズを理解する](managed-node-update-behavior.md)」を参照してください。
## ノードグループバージョンの更新
ノードグループのバージョンは、次のいずれかを使用して更新できます。
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [AWS マネジメントコンソール](#console_update_managed_nodegroup)
更新するバージョンは、コントロールプレーンバージョンよりも新しいバージョンにすることはできません。
## `eksctl`
**`eksctl` を使用してマネージドノードグループを更新する**
次のコマンドを使用して、マネージドノードグループを、ノードに現在デプロイされているのと同じ Kubernetes バージョンの最新 AMI リリースに更新します。各*サンプル値*は独自の値に置き換えます。
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**注記**
起動テンプレートでデプロイされたノードグループを、新しい起動テンプレートのバージョンにアップグレードする場合は、上記のコマンドに `--launch-template-version version-number ` を追加します。起動テンプレート は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」に記載されている要件を満たしている必要があります。起動テンプレートにカスタム AMI が含まれている場合、AMI は「[Specifying an AMI](launch-templates.md#launch-template-custom-ami)」(AMI の指定) の要件を満たしている必要があります。ノードグループを新しいバージョンの起動テンプレートにアップグレードすると、指定した起動テンプレートバージョンの新しい設定と一致するように、すべてのノードがリサイクルされます。
起動テンプレートなしでデプロイしたノードグループを、新しい起動テンプレートバージョンに直接アップグレードすることはできません。代わりに、起動テンプレートを使用して新しいノードグループをデプロイし、新しい起動テンプレートバージョンにノードグループを更新する必要があります。
コントロールプレーンの Kubernetes バージョンと同じバージョンにノードグループをアップグレードできます。例えば、Kubernetes `1.35` を実行しているクラスターがある場合、次のコマンドを使用して、現在 Kubernetes `1.34` を実行しているノードをバージョン `1.35` にアップグレードできます。
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## AWS マネジメントコンソール
**AWS マネジメントコンソール を使用してマネージドノードグループを更新する**
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 更新するノードグループを含むクラスターを選択します。
1. 少なくとも 1 つのノードグループに利用可能な更新がある場合、ページの上部に利用可能な更新について通知するボックスが表示されます。**[Compute]** (コンピューティング) タブを選択すると、利用可能な更新があるノードグループの **[Node Groups]** (ノードグループ) 表の、**[AMI release version]** (AMI リリースバージョン) 列に、**[Update now]** (今すぐ更新) が表示されます。ノードグループを更新するには、**[Update now]** (今すぐ更新) を選択します。
カスタム AMI でデプロイされたノードグループの通知は表示されません。ノードがカスタム AMI でデプロイされている場合は、次の手順を実行して、新しく更新されたカスタム AMI をデプロイします。
1. AMI の新しいバージョンを作成します。
1. 新しい AMI ID を使用して、新しい起動テンプレートのバージョンを作成します。
1. 起動テンプレートの新しいバージョンにノードを更新する
1. **[Update node group version]** (ノードグループバージョンの更新) ダイアログボックスで、次のオプションを有効または無効にします。
+ **[Update node group version]** (ノードグループのバージョンの更新) - カスタム AMI をデプロイした場合、あるいは Amazon EKS に最適化された AMI が現在のクラスターで最新のバージョンである場合には、このオプションは利用できません。
+ **[Change launch template version]** (起動テンプレートバージョンの変更) - ノードグループがカスタムの起動テンプレートを使用せずにデプロイされている場合、このオプションは利用できません。カスタム起動テンプレートを使用してデプロイされたノードグループの、起動テンプレートのバージョンのみ更新できます。ノードグループを更新する **[Launch template version]** (起動テンプレートバージョン) を選択します。ノードグループがカスタム AMI で設定されている場合は、選択するバージョンも AMI を指定する必要があります。新しいバージョンの起動テンプレートにアップグレードすると、指定した起動テンプレートバージョンの新しい設定と一致するように、すべてのノードがリサイクルされます。
1. **[Update strategy]** (更新戦略) で、次のいずれかのオプションを選択します。
+ **[ローリング更新]**: このオプションは、クラスターの Pod の中断予算を尊重します。Pod 中断予算の問題により、Amazon EKS がこのノードグループで実行されている Pod を正常にドレインできない場合、更新が失敗します。
+ **[強制更新]**: このオプションは Pod の中断予算を尊重しません。ノードの再起動を強制的に実行することにより、Pod の中断予算の問題に関係なく更新が行われます。
1. **[更新]** を選択します。
## ノードグループ設定の編集
マネージド型ノードグループの設定の一部を変更できます。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 編集するノードグループを含むクラスターを選択します。
1. **[Compute]** (コンピューティング) タブを選択します。
1. 編集するノードグループを選択し、次に **[Edit]** (編集) を選択します。
1. (オプション) **[Edit Node Group]** (ノードグループの編集) ページで以下を実行します。
1. **ノードグループのスケーリング設定**を編集します。
+ **[Desired size]** (必要なサイズ) - マネージド型ノードグループが保持する必要があるノードの現在の数を指定します。
+ **[最小サイズ]** – マネージド型ノードグループがスケールインできるノードの最小数を指定します。
+ [**最大サイズ**]: マネージド型ノードグループがスケールアウトできるノードの最大数を指定します。ノードグループでサポートされるノードの最大数については、「[Amazon EKS と Fargate Service Quotas を表示して管理する](service-quotas.md)」を参照してください。
1. (オプション) ノードグループ内のノードに **[Kubernetes ラベル]** を追加または削除します。ここに示すラベルは、Amazon EKS で適用したラベルのみです。ここには表示されていない他のラベルがノードに存在する可能性があります。
1. (オプション) ノードグループ内のノードに **[Kubernetes テイント]** を追加または削除します。追加されたテイントは、` NoSchedule `、` NoExecute `、または ` PreferNoSchedule ` の影響があります。詳細については、「[レシピ: 特定のノードでポッドがスケジュールされないようにする](node-taints-managed-node-groups.md)」を参照してください。
1. (オプション) ノードグループリソースに**[Tags]** (タグ) を追加または削除します。これらのタグは、Amazon EKS ノードグループにのみ適用されます。これらは、Amazon EC2 インスタンスやサブネットなど、ノードグループの他のリソースには伝達されません。
1. (オプション) **ノードグループの更新設定**を編集します。**[Number]** (数値) または **[Percentage]** (パーセンテージ) のいずれかを選択します。
+ **[数値]**: 並行して更新できるノードグループ内のノード数を選択して指定します。これらのノードは、更新中は使用できません。
+ **[パーセンテージ]**: 並行して更新できるノードグループ内のノードの割合を選択して指定します。これらのノードは、更新中は使用できません。ノードグループに多数のノードがある場合に便利です。
1. 編集が終了したら、**[変更の保存]** を選択します。
**重要**
ノードグループ設定を更新する場合、[https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html) を変更しても Pod 中断予算 (PDB) は考慮されません。[ノードグループの更新](managed-node-update-behavior.md)プロセス (アップグレードフェーズ中にノードをドレインし、PDB を考慮する) とは異なり、スケーリング設定を更新すると、Auto Scaling グループ (ASG) スケールダウンコールによってノードがすぐに終了します。これは、スケールダウン先のターゲットサイズに関係なく、PDB を考慮せずに発生します。つまり、Amazon EKS マネージドノードグループの `desiredSize` を減らすと、ノードが終了するとすぐに、PDB を尊重せずに Pod が削除されます。
# ノードの更新の各フェーズを理解する
Amazon EKS マネージド型ワーカーノードのアップグレード戦略には、次のセクションで説明する 4 つの異なるフェーズがあります。
## セットアップフェーズ
セットアップフェーズには、次の手順があります。
1. ノードグループに関連付けられた Auto Scaling グループ用に新しい Amazon EC2 起動テンプレートバージョンを作成します。新しい起動テンプレートバージョンでは、ターゲットの AMI またはカスタム起動テンプレートバージョンを更新に使用します。
1. 最新の起動テンプレートバージョンを使用するように、Auto Scaling グループを更新します。
1. ノードグループの `updateConfig` プロパティを使用して、並列でアップグレードするノードの最大数を決定します。使用不可の最大値には、クォータとして 100 ノードがあります。デフォルト値は 1 ノードです。詳細については、Amazon EKS API リファレンス内の [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) プロパティを参照してください。
## スケールアップフェーズ
マネージド型ノードグループ内のノードをアップグレードするとき、アップグレードされたノードは、アップグレードされているノードと同じアベイラビリティーゾーンで起動されます。この配置を保証するために、Amazon EC2 のアベイラビリティーゾーンの再調整を使用します。詳細については、[Amazon EC2 Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)の*アベイラビリティーゾーンの再調整*を参照してください。この要件を満たすために、マネージド型ノードグループのアベイラビリティーゾーンごとに最大 2 つのインスタンスを起動できます。
スケールアップフェーズには、次の手順があります。
1. Auto Scaling グループの最大サイズと希望のサイズを、次のうちいずれか大きい方だけ増加させます。
+ Auto Scaling グループがデプロイされているアベイラビリティーゾーン数の最大 2 倍。
+ アップグレードができない最大値。
たとえば、ノードグループのアベイラビリティーゾーンが 5 つで、`maxUnavailable` が 1 である場合、アップグレードプロセスで最大 10 個のノードを起動できます。しかし、`maxUnavailable` が 20 (または 10 より大きいいずれかの値) である場合、プロセスにより起動される新しいノードは 20 個です。
1. Auto Scaling グループのスケーリング後、最新の設定を使用するノードがノードグループに存在するかどうかをチェックします。この手順は、次の基準を満たす場合にのみ成功します。
+ ノードが存在するすべてのアベイラビリティーゾーンで、少なくとも 1 つの新しいノードが起動されます。
+ 新しいノードはすべて、`Ready` 状態である必要があります。
+ 新しいノードには Amazon EKS 適用ラベルが必要です。
これは、通常のノードグループのワーカーノード上の Amazon EKS 適用ラベルです。
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
これは、カスタム起動テンプレートまたは AMI ノードグループのワーカーノード上の Amazon EKS 適用ラベルです。
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
1. 新しい Pod がスケジュールされないように、ノードをスケジュール不可としてマークします。古いノードを終了する前にロードバランサーからノードを削除するため、ノードに `node.kubernetes.io/exclude-from-external-load-balancers=true` のラベルを付けます。
このフェーズで `NodeCreationFailure` エラーが発生する既知の原因を次に示します。
**アベイラビリティーゾーンの容量が不十分です**
アベイラビリティーゾーンに、リクエストされたインスタンスタイプの容量がない可能性があります。マネージド型ノードグループを作成するときは、複数のインスタンスタイプを設定することをお勧めします。
**アカウント内の EC2 インスタンス制限**
Service Quotas を使用してアカウントが同時に実行できる Amazon EC2 インスタンスの数を増やす必要がある場合があります。詳細については、*Linux インスタンス向け Amazon Elastic Compute Cloud ユーザーガイド*の [EC2 の Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) を参照してください。
**カスタムユーザーデータ**
カスタムユーザーデータは、ブートストラッププロセスを中断することがあります。このシナリオでは、ノードで `kubelet` が起動しないか、ノードで想定される Amazon EKS ラベルが取得されない可能性があります。詳細については、「[AMI を指定する](launch-templates.md#launch-template-custom-ami)」を参照してください。
**ノードを異常な状態または準備ができていない状態にする変更**
ノードのディスク負荷、メモリ負荷、および同様の条件により、ノードが `Ready` 状態にならない可能性があります。
**各ノードのブートストラップにかかる時間は通常 15 分以内**
ブートストラップしてクラスターに加わるまでに 15 分以上かかるノードがあると、アップグレードがタイムアウトします。この時間は、新しいノードが必要になってからクラスターに加わるまで、新しいノードのブートストラップに要した合計時間です。マネージドノードグループをアップグレードする場合は、Auto Scaling グループのサイズが大きくなると、すぐに時間の測定が始まります。
## アップグレードフェーズ
アップグレードフェーズの動作には 2 通りの方法があり、*更新戦略*によって異なります。**デフォルト**と**最小**という 2 つの更新戦略があります。
通常は、デフォルト戦略をお勧めします。古いノードを終了する前に新しいノードを作成するという戦略で、アップグレードフェーズ中も使用可能な容量が維持されます。最小は、リソースやコスト (例えば、GPU などのハードウェアアクセラレーター) が限られている場合に便利な戦略です。新しいノードを作成する前に古いノードを終了するため、合計容量が設定しておいた数量を超えることはありません。
*デフォルト*更新戦略のステップは次のとおりです。
1. Auto Scaling グループ内のノード数を (必要な数だけ) 増やして、ノードグループに追加でノードを作成します。
1. ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。
1. ノードから Pod をドレインします。Pod が 15 分以内にノードを離れず、強制フラグがない場合は、`PodEvictionFailure` というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、`update-nodegroup-version` リクエストで強制フラグを適用して Pod を削除できます。
1. すべての Pod が削除されたらノードを遮断し、60 秒間待機します。これは、サービスコントローラーがこのノードに新しくリクエストを送信しないようにするためと、アクティブなノードのリストからこのノードを削除するために行われます。
1. 遮断されたノードの Auto Scaling グループに終了リクエストを送信します。
1. 以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。
*最小*更新戦略のステップは次のとおりです。
1. ノードグループのすべてのノードを最初に遮断して、サービスコントローラーがこれらのノードに新しいリクエストを送信しないようにします。
1. ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。
1. 選択したノードからポッドをドレインします。Pod が 15 分以内にノードを離れず、強制フラグがない場合は、`PodEvictionFailure` というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、`update-nodegroup-version` リクエストで強制フラグを適用して Pod を削除できます。
1. すべてのポッドを削除し 60 秒間待機すると、終了リクエストが、選択したノードの Auto Scaling グループに送信されます。Auto Scaling グループは、不足分の容量を補うために (選択したノードと同数の) 新しいノードを作成します。
1. 以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。
### アップグレードフェーズ中の `PodEvictionFailure` エラー
このフェーズで `PodEvictionFailure` エラーが発生する既知の原因を次に示します。
**アグレッシブ PDB**
Pod にアグレッシブ PDB が定義されているか、同じ Pod を指す複数の PDB が存在します。
**すべてのテイントを許容するデプロイ**
すべての Pod が削除されたら、前のステップでノードが[テイント](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)されているため、ノードは空になるはずです。ただし、デプロイがすべてのテイントを許容する場合、ノードが空でない可能性が高くなり、Pod のエビクションが失敗します。
## スケールダウンフェーズ
スケールダウンフェーズでは、Auto Scaling グループの最大サイズと希望するサイズが 1 ずつ減り、更新が開始される前の値に戻ります。
ワークフローのスケールダウンフェーズ中に Cluster Autoscaler がノードグループをスケールアップしているとアップグレードワークフローが判断した場合、ノードグループを元のサイズに戻すことなく、すぐに終了します。
# 起動テンプレートを使用してマネージドノードをカスタマイズする
このページの手順に基づいて自分の起動テンプレートを使用することで、マネージド型ノードをデプロイでき、最高レベルのカスタマイズを実現できます。起動テンプレートを使用すると、ノードのデプロイ中にブートストラップ引数 (追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数など) を指定したり、ノードに割り当てられた IP アドレスとは異なる CIDR ブロックからポッドに IP アドレスを割り当てたり、独自のカスタム AMI をノードにデプロイしたり、独自のカスタム CNI をノードにデプロイしたりできます。
最初にマネージドノードグループを作成するときに独自の起動テンプレートを指定する場合にも、後で高い柔軟性を得ることができます。自分の起動テンプレートを使用してマネージド型ノードグループをデプロイする限り、同じ起動テンプレートの異なるバージョンとして繰り返し更新できます。ノードグループを別のバージョンの起動テンプレートに更新すると、指定した起動テンプレートバージョンの新しい設定と一致するように、グループ内のすべてのノードがリサイクルされます。
マネージド型ノードグループは常に アマゾン EC2 自動スケーリング グループで使用する起動テンプレートでデプロイされます。起動テンプレートを指定しない場合、アマゾン EKS API はアカウントのデフォルト値を使用して起動テンプレートを自動的に作成します。ただし、自動生成された起動テンプレートを変更することは推奨しません。さらに、カスタム起動テンプレートを使用していない既存のノードグループは直接更新できません。代わりに、カスタム起動テンプレートを使用して、新しいノードグループを作成する必要があります。
## 起動テンプレート設定の基本
AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して、アマゾン EC2 自動スケーリング 起動テンプレートを作成できます。詳細については*「アマゾン EC2 自動スケーリング ユーザーガイド」*の「[自動スケーリング グループの起動テンプレートを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)」を参照してください。起動テンプレートの一部の設定はマネージド型ノードで使われている設定と似ています。起動テンプレートを使用してノードグループをデプロイまたは更新する場合、一部の設定はノードグループ設定または起動テンプレートのいずれかで指定する必要があります。両方の場所で設定を指定しないでください。存在してはいけない場所に設定が存在する場合、ノードグループの作成や更新などの操作は失敗します。
次の表に、起動テンプレートで禁止されている設定を示します。また、マネージド型ノードグループの設定に必要な同様の設定がある場合はその設定も示します。リスト化されている設定はコンソールに表示される設定です。AWS CLI と SDK では類似するが異なる名前がある場合があります。
| 起動テンプレート — 禁止 | アマゾン EKS ノードグループ設定 |
| --- | --- |
| [**ネットワークインターフェイス**] ([**ネットワークインターフェイスを追加**]) の下の [**サブネット**] | **[Specify networking]** (ネットワーキングを指定) ページの **[Node group network configuration]** (ノードグループのネットワーク設定) の下の **[Subnets]** (サブネット) |
| [**高度な詳細**] の下の [**IAM インスタンスプロファイル**] | **[Configure Node group]** (ノードグループを設定) ページの **[Node group configuration]** (ノードグループ設定) の下の **[Node IAM role]** (ノード IAM 役割) |
| [**高度な詳細**] の下の [**シャットダウン動作**] および [**停止 – 休止動作**]。起動テンプレートのどちらの設定でも、[**起動テンプレート設定に含めない**] のデフォルトを保持します。 | 同等のものはありません。アマゾン EKS は自動スケーリング グループではなく、インスタンスのライフサイクルを管理する必要があります。 |
次の表に、マネージド型ノードグループ構成で禁止される設定を示します。また、起動テンプレートで必要な同様の設定がある場合はその設定も示します。リスト化されている設定はコンソールに表示される設定です。AWS CLI と SDK とで名前が似ている場合があります。
| アマゾン EKS ノードグループ設定 — 禁止 | 起動テンプレート |
| --- | --- |
| (起動テンプレートでカスタム AMI を指定した場合のみ) **[コンピューティングとスケーリングの設定を実行]** ページの **[ノードグループのコンピューティング設定]** の下の **[AMI タイプ]** — **[起動テンプレートで指定]** と、指定した AMI ID がコンソールに表示されます。 起動テンプレートで **[アプリ and OS Images (アマゾン Machine Image)]** (アプリケーションと OS のイメージ (アマゾン マシンイメージ)) が指定されていない場合はノードグループ設定で AMI を選択できます。 | **[Launch template contents]** (起動テンプレートのコンテンツ) での **[Application and OS Images (Amazon Machine Image)]** (アプリケーションと OS のイメージ (Amazon マシンイメージ)) - 次のいずれかの要件がある場合はID を指定する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/launch-templates.html) |
| **[Set compute and scaling configuration]** (コンピューティングとスケーリングの設定を実行) ページの **[Node Group compute configuration]** (ノードグループのコンピューティング設定) の下の **[Disk size]** (ディスクサイズ) — **[Specified in launch template]** (起動テンプレートで指定) がコンソールに表示されます。 | [**ストレージ (ボリューム)**] ([**新しいボリュームの追加**]) の下の [**サイズ**]。これを起動テンプレートで指定する必要があります。 |
| **[Specify Networking]** (ネットワーキングを指定) ページの **[Node group configuration]** (ノードグループ設定) の下の **[SSH key pair]** (SSH キーペア) — コンソールに起動テンプレートで指定したキーまたは **[Not specified in launch template]** (起動テンプレートで指定されていません) が表示されます。 | [**キーペア (ログイン)**] の下の [**キーペア名**]。 |
| 起動テンプレートを使用する場合はリモートアクセスを許可するソースセキュリティグループを指定できません。 | インスタンスの場合、[**ネットワーク設定**] の下の [**セキュリティグループ**]、または [**ネットワークインターフェイス**] ([**ネットワークインターフェイスを追加**])の下の [**セキュリティグループ**]。両方設定することはできません。詳細については「[カスタムセキュリティグループを使用する](#launch-template-security-groups)」を参照してください。 |
**注記**
起動テンプレートを使用してノードグループをデプロイする場合は起動テンプレート内の **[起動テンプレートのコンテンツ]** で 0 または 1 の **[インスタンスタイプ]** を指定します。またはコンソールの **[コンピューティングとスケーリングの構成を設定する]** ページにある **[インスタンスタイプ]** で 0 から 20 までのインスタンスタイプを指定できます。またはアマゾン EKS API を使用する他のツールを使用して行うこともできます。起動テンプレートでインスタンスタイプを指定し、その起動テンプレートを使用してノードグループをデプロイする場合、コンソールや、アマゾン EKS API を使用する他のツールを使用してインスタンスタイプを指定することはできません。起動テンプレートやコンソール、または アマゾン EKS API を使用する他のツールを使用してインスタンスタイプを指定しない場合は`t3.medium` インスタンスタイプが使用されます。ノードグループがスポットキャパシティータイプを使用している場合はコンソールを使用して複数のインスタンスタイプを指定することをお勧めします。詳細については「[マネージド型ノードグループのキャパシティータイプ](managed-node-groups.md#managed-node-group-capacity-types)」を参照してください。
ノードグループにデプロイするコンテナが、インスタンスメタデータサービスバージョン 2 を使用している場合は起動テンプレートの **[メタデータレスポンスのホップ制限]** を `2` に設定してください。詳細については*「アマゾン EC2 ユーザーガイド」*の「[Instance metadata and user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」(インスタンスメタデータとユーザーデータ) を参照してください。
起動テンプレートでは、インスタンスタイプを柔軟に選択できるようにする `InstanceRequirements` 機能はサポートされていません。
## アマゾン EC2 インスタンスへのタグ付け
起動テンプレートの `TagSpecification` パラメータを使用して、ノードグループの アマゾン EC2 インスタンスに適用するタグを指定します。`CreateNodegroup` または `UpdateNodegroupVersion` API を呼び出す IAM エンティティには`ec2:RunInstances` および `ec2:CreateTags` へのアクセス許可が必要です。また、起動テンプレートにタグが追加される必要があります。
## カスタムセキュリティグループを使用する
起動テンプレートでカスタムの アマゾン EC2 [セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)を指定し、ノードグループ内のインスタンスに適用できます。これはインスタンスレベルのセキュリティグループのパラメータ内か、ネットワークインターフェイス設定のパラメータの一部として指定できます。しかし、インスタンスレベルとネットワークインタフェイス、両方のセキュリティグループを指定して、起動テンプレートを作成することはできません。マネージドノード型グループでカスタムセキュリティグループを使用する際に適用される、次の条件を考慮してください。
+ AWS マネジメントコンソール を使用する場合、アマゾン EKS では単一のネットワークインターフェイス仕様の起動テンプレートのみ使用できます。
+ デフォルトではAmazon EKS は[クラスターセキュリティグループ](sec-group-reqs.md)をノードグループ内のインスタンスに追加して、ノードとコントロールプレーンとの間の通信を容易にします。前述のいずれかのオプションを使用して、起動テンプレートでカスタムセキュリティグループを指定した場合、アマゾン EKS はクラスターセキュリティグループを追加しません。したがって、セキュリティグループのインバウンドルールとアウトバウンドルールで、クラスターのエンドポイントとの通信が有効になっていることを確認する必要があります。セキュリティグループのルールが正しくない場合、ワーカーノードはクラスターに参加できません。セキュリティグループルールの詳細については[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。
+ ノードグループ内のインスタンスへの SSH アクセスが必要な場合はそのアクセスを許可するセキュリティグループを含めてください。
## アマゾン EC2 ユーザーデータ
起動テンプレートにはカスタムユーザーデータのセクションが含まれています。このセクションでは、個々のカスタム AMI を手動で作成しなくても、ノードグループの構成設定を指定できます。Bottlerocket で使用できる設定の詳細については、GitHub で [Using user data](https://github.com/bottlerocket-os/bottlerocket#using-user-data) を参照してください。
`cloud-init` を使用すると、インスタンス起動時に起動テンプレート内の Amazon EC2 ユーザーデータを提供できます。詳細については「[cloud-init ドキュメント](https://cloudinit.readthedocs.io/en/latest/index.html)」を参照してください。ユーザーデータを使用すると、一般的な設定操作を実行できます。これには次の操作が含まれます。
+ [ユーザーまたはグループを含む](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [パッケージのインストール](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
マネージド型ノードグループで使用される起動テンプレートの Amazon EC2 ユーザーデータは、Amazon Linux AMI の場合は、[MIME マルチパートアーカイブ](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive)、Bottlerocket AMI の場合は TOML の形式であることが必要です。これはユーザーデータが、ノードがクラスターに参加するために必要な Amazon EKS ユーザーデータにマージされるためです。`kubelet` を起動または変更するコマンドをユーザーデータに指定しないでください。これは アマゾン EKS によってマージされたユーザーデータの一部として実行されます。ノードへのラベル設定などの一部の `kubelet` パラメータはマネージド型ノードグループ API 経由で直接設定できます。
**注記**
手動での起動や、カスタムの設定パラメータの受け渡しなど、高度な `kubelet` のカスタマイズについては[AMI を指定する](#launch-template-custom-ami)を参照してください。起動テンプレートでカスタム AMI ID が指定されている場合、アマゾン EKS はユーザーデータをマージしません。
次の詳細はユーザーデータセクションについて説明しています。
**アマゾン リナックス 2 ユーザーデータ**
複数のユーザーデータブロックと単一の MIME マルチパートファイルを組み合わせることができます。例えば、カスタムパッケージをインストールするユーザーデータのシェルスクリプトを、Docker デーモンを設定するクラウドブートフックに組み合わせることができます。MIME マルチパートファイルには次のコンポーネントが含まれます。
+ コンテンツタイプとパートバウンダリの宣言: `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ MIME バージョンの宣言: `MIME-Version: 1.0`
+ 次のコンポーネントを含む 1 つ以上のユーザーデータブロック:
+ ユーザーデータブロックの始まりを示す開始境界:`--==MYBOUNDARY==`
+ ブロックのコンテンツの種類の宣言: `Content-Type: text/cloud-config; charset="us-ascii"`。コンテンツタイプの詳細については[cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html) のドキュメントを参照してください。
+ ユーザーデータのコンテンツ (例えば、シェルコマンドや `cloud-init` ディレクティブのリスト)。
+ MIME マルチパートファイルの終わりを示す、終了境界: `--==MYBOUNDARY==--`
自分で MIME マルチパートファイルを作成するときに使用できる例は次の通りです。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**アマゾン リナックス 2023 ユーザーデータ**
アマゾン リナックス 2023 (AL2023) ではYAML 設定スキーマを使用する新しいノード初期化プロセス `nodeadm` が導入されています。セルフマネージド型ノードグループまたは起動テンプレートを持つ AMI を使用している場合は新しいノードグループの作成時に追加のクラスターメタデータを明示的に指定する必要があります。最低限必要なパラメータの[例](https://awslabs.github.io/amazon-eks-ami/nodeadm/)を以下に示します。ここで、`apiServerEndpoint`、`certificateAuthority`、サービスの `cidr` が必要になります。
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
通常、この設定はユーザーデータにそのまま設定するか、MIME マルチパートドキュメントに埋め込まれます。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
AL2 ではこれらのパラメータからのメタデータは アマゾン EKS `DescribeCluster` API コールから検出されていました。AL2023 ではノードの大規模なスケールアップ中に API コールによってスロットリングが発生するリスクがあるため、この動作が変更されました。この変更は起動テンプレートのないマネージド型ノードグループを使用している場合や、Karpenter を使用している場合には影響しません。`certificateAuthority` とサービス `cidr` の詳細については、「*Amazon EKS API リファレンス*」の「[https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)」を参照してください。
次に、AL2023 ユーザーデータの詳しい例を示します。ノードをカスタマイズするシェルスクリプト (パッケージのインストールやコンテナイメージの事前キャッシュなど) を必要な `nodeadm` 設定と結合しています。この例では、よく使用されるカスタマイズを示しています。\$1 追加でシステムパッケージをインストールする \$1 コンテナイメージを事前キャッシュしてポッドの起動時間を改善する \$1 HTTP プロキシ設定を設定する \$1 ノードのラベル付けに関する `kubelet` フラグを設定する
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Bottlerocket ユーザーデータ**
Bottlerocket はユーザーデータを TOML 形式で構造化しています。Amazon EKS が提供するユーザーデータとマージするユーザーデータを提供できます。たとえば、追加の `kubelet` 設定を指定できます。
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
サポートされる設定について詳しくは[Bottlerocket のドキュメント](https://github.com/bottlerocket-os/bottlerocket)を参照してください。ユーザーデータにノードラベルと[テイント](node-taints-managed-node-groups.md)を設定できます。ただし、代わりにノードグループ内にこれらを設定することをお勧めします。この場合、アマゾン EKS によりこれらの設定が適用されます。
ユーザーデータをマージしても、書式設定は保持されませんが、コンテンツは同じままです。ユーザーデータに指定した設定はアマゾン EKS によって構成された設定よりも優先されます。したがって、`settings.kubernetes.max-pods` または `settings.kubernetes.cluster-dns-ip` を設定した場合、ユーザーデータのこれらの値がノードに適用されます。
アマゾン EKS で、有効な TOML がすべてサポートされるわけではありません。以下はサポートされていない既知の形式の一覧です。
+ 引用符で囲まれたキー内の引用符: `'quoted "value"' = "value"`
+ 値内のエスケープされた引用符: `str = "I’m a string. \"You can quote me\""`
+ 浮動小数点と整数の混在: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ 配列内の混合型: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ 引用符付きキーを含む括弧で囲まれたヘッダー: `[foo."bar.baz"]`
**Windows ユーザーデータ**
Windows ユーザーデータでは、PowerShell コマンドを使用します。マネージド型ノードグループを作成すると、カスタムユーザーデータが Amazon EKS マネージドユーザーデータと結合されます。まず PowerShell コマンドが表示され、その後にマネージドユーザーデータコマンドが続きます。そのいずれも 1 つの `` タグ内にあります。
Windows ノードグループを作成すると、Amazon EKS は Linux ベースのノードがクラスターに参加できるように `aws-auth` `ConfigMap` を更新します。このサービスは、Windows AMI に対するアクセス許可を自動的には設定しません。Windows ノードを使用している場合は、アクセスエントリ API を利用するか、`aws-auth` `ConfigMap` を直接更新することで、アクセスを管理する必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。
起動テンプレートに AMI ID が指定されていない場合はユーザーデータで Windows Amazon EKS ブートストラップスクリプトを使用して Amazon EKS を設定しないでください。
ユーザーデータの例は次のとおりです。
```
Write-Host "Running custom user data script"
```
## AMI を指定する
以下のいずれかの要件がある場合は起動テンプレートの `ImageId` フィールドで AMI ID を指定します。追加情報については要件を選択してください。
### Amazon EKS に最適化された Linux/Bottlerocket AMI に含まれる `bootstrap.sh` ファイルに引数を渡すためのユーザーデータを提供する
ブートストラップとはインスタンスの起動時に実行できるコマンドの追加を表す用語です。例えば、ブートストラップでは追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数を使用できます。起動テンプレートを指定せずに、`eksctl` を使用して引数を `bootstrap.sh` スクリプトに渡すことができます。または起動テンプレートのユーザーデータセクションに情報を指定することでこれを行うことができます。
**起動テンプレートを指定しない eksctl**
*my-nodegroup.yaml* という名前のファイルを以下の内容で作成します。各*サンプル値*は独自の値に置き換えます。`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数はオプションです。しかし、これらを定義すると、`bootstrap.sh` スクリプトによる `describeCluster` 呼び出しを避けることができます。これはプライベートクラスターのセットアップや、ノードを頻繁にスケールインおよびスケールアウトするクラスターで役立ちます。`bootstrap.sh` スクリプトの詳細については、GitHub で「[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」ファイルを参照してください。
+ 必須となる引数はクラスター名 (*マイクラスター*) のみです。
+ `ami-1234567890abcdef0 ` に最適化された AMI ID を取得するには、次のセクションを参照してください。
+ [推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)
+ [推奨 Bottlerocket AMI ID を取得する](retrieve-ami-id-bottlerocket.md)
+ [推奨 Microsoft Windows AMI ID を取得する](retrieve-windows-ami-id.md)
+ クラスターの *認証機関* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ この例ではカスタムの `max-pods` 値を設定するために `kubelet` 引数を指定します。その際、Amazon EKS 最適化 AMI に含まれている `bootstrap.sh` スクリプトを使用します。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*my-max-pods-value* を選択する方法については「」を参照してください。マネージド型ノードグループを使用する場合の `maxPods` の決定方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
利用可能な `eksctl` `config` ファイルオプションについては「`eksctl` ドキュメント」の「[Config file schema](https://eksctl.io/usage/schema/)」(Config ファイルスキーマ) を参照してください。`eksctl` ユーティリティは引き続き起動テンプレートを作成し、`config` ファイルに提供したデータを使用してユーザーデータを設定します。
次のコマンドを使用して、ノードグループを作成します。
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**起動テンプレートのユーザーデータ**
起動テンプレートのユーザーデータセクションで次の情報を指定します。各*サンプル値*は独自の値に置き換えます。`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数はオプションです。しかし、これらを定義すると、`bootstrap.sh` スクリプトによる `describeCluster` 呼び出しを避けることができます。これはプライベートクラスターのセットアップや、ノードを頻繁にスケールインおよびスケールアウトするクラスターで役立ちます。`bootstrap.sh` スクリプトの詳細については、GitHub で「[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」ファイルを参照してください。
+ 必須となる引数はクラスター名 (*マイクラスター*) のみです。
+ クラスターの *認証機関* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ この例ではカスタムの `max-pods` 値を設定するために `kubelet` 引数を指定します。その際、Amazon EKS 最適化 AMI に含まれている `bootstrap.sh` スクリプトを使用します。*my-max-pods-value* を選択する方法については「」を参照してください。マネージド型ノードグループを使用する場合の `maxPods` の決定方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### Amazon EKS に最適化された Windows AMI に含まれる `Start-EKSBootstrap.ps1` ファイルに引数を渡すためのユーザーデータを提供する
ブートストラップとはインスタンスの起動時に実行できるコマンドの追加を表す用語です。起動テンプレートを指定せずに、`eksctl` を使用して引数を `Start-EKSBootstrap.ps1` スクリプトに渡すことができます。または起動テンプレートのユーザーデータセクションに情報を指定することでこれを行うことができます。
カスタム Windows AMI ID を指定する場合は、次の考慮事項に留意してください。
+ 起動テンプレートを使用し、必要なブートストラップコマンドをユーザーデータセクションに入力する必要があります。目的の Windows ID を取得するには、「[最適化された Windows AMI を使用してノードを作成する](eks-optimized-windows-ami.md)」のテーブルを使用できます。
+ いくつかの制限と条件があります。例えば、`eks:kube-proxy-windows` を AWS IAM 認証 設定マップに追加する必要があります。詳細については「[AMI ID を指定する場合の制限と条件](#mng-ami-id-conditions)」を参照してください。
起動テンプレートのユーザーデータセクションで次の情報を指定します。各*サンプル値*は独自の値に置き換えます。`-APIServerEndpoint`、`-Base64ClusterCA`、および `-DNSClusterIP` 引数はオプションです。しかし、これらを定義すると、`Start-EKSBootstrap.ps1` スクリプトによる `describeCluster` 呼び出しを避けることができます。
+ 必須となる引数はクラスター名 (*マイクラスター*) のみです。
+ クラスターの *認証機関* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ その他の引数については「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
**注記**
カスタムサービス CIDR を使用している場合は`-ServiceCIDR` パラメータを使用して指定する必要があります。そうしないと、クラスター内の Pod の DNS 解決が失敗します。
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### 特定のセキュリティ、コンプライアンス、または社内的なポリシー要件のために、カスタム AMI を実行する
詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)」を参照してください。Amazon EKS AMI ビルド仕様にはAmazon Linux をベースにしたカスタム Amazon EKS AMI を構築するためのリソースと設定スクリプトが含まれています。詳細については、GitHubの「[Amazon EKS AMI ビルド仕様](https://github.com/awslabs/amazon-eks-ami/)」を参照してください。他のオペレーティングシステムがインストールされたカスタム AMI を作成するには、GitHubの「[Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis)」を参照してください。
マネージドノードグループで使用される起動テンプレートで AMI ID に動的パラメータ参照を使用することはできません。
**重要**
AMI を指定する場合、Amazon EKS はクラスターのコントロールプレーンバージョンに対して AMI に埋め込まれた Kubernetes バージョンを検証しません。ユーザーは、カスタム AMI の Kubernetes バージョンが以下の [Kubernetes バージョンスキューポリシー](https://kubernetes.io/releases/version-skew-policy)に準拠していることを確認する責任があります。
ノード上の `kubelet` バージョンはクラスターバージョンより新しいものであってはならない
ノード上の `kubelet` バージョンは、お使いのクラスターバージョン (Kubernetes バージョン `1.28` およびそれ以降) から最大 マイナーバージョン 3 つ前まで、またはクラスターバージョン (Kubernetes バージョン `1.27` およびそれ以前) から最大 マイナーバージョン 2 つ前までである必要がある
バージョンスキューポリシーに違反したマネージド型ノードグループを作成すると、次の結果になる可能性があります。
ノードをクラスターに結合できない
未定義の動作または API の非互換性
クラスターの不安定性またはワークロード障害
AMI を指定する際、Amazon EKS ではユーザーデータをマージしません。代わりに、ノードのクラスターへの参加に必要な `bootstrap` コマンドを、ユーザーが提供する必要があります。ノードがクラスターに参加できない場合、アマゾン EKS `CreateNodegroup` および `UpdateNodegroupVersion` アクションも失敗します。
## AMI ID を指定する場合の制限と条件
以下に、マネージド型ノードグループで AMI ID を指定する際の制限と条件を示します。
+ 起動テンプレートで AMI ID を指定する場合と、AMI ID を指定しない場合は新しいノードグループを作成して切り替える必要があります。
+ 新しい AMI バージョンが利用可能になっても、コンソールでは通知を表示しません。ノードグループを新しい AMI バージョンに更新するには更新された AMI ID で新しいバージョンの起動テンプレートを作成する必要があります。次に、新しい起動テンプレートバージョンでノードグループを更新する必要があります。
+ AMI ID を指定した場合はAPI の次のフィールドを設定することはできません。
+ `amiType`
+ `releaseVersion`
+ `version`
+ AMI ID を指定する場合、API で設定されたすべての `taints` は非同期に適用されます。ノードがクラスターに参加する前にテイントを適用するには`--register-with-taints` コマンドラインフラグを使用してユーザーデータ内の `kubelet` にテイントを渡す必要があります。詳細については、Kubernetes ドキュメントの「[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)」を参照してください。
+ Windows マネージド型ノードグループのカスタム AMI ID を指定するときは、AWS IAM オーセンティケーター設定マップに `eks:kube-proxy-windows` を追加します。これはDNS が正しく機能するために必要です。
1. AWS IAM 認証 設定マップを編集用に開きます。
```
kubectl edit -n kube-system cm aws-auth
```
1. このエントリを、Windows ノードに関連付けられた各 `rolearn` の下にある `groups` リストに追加します。設定マップは [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)に似ているはずです。
```
- eks:kube-proxy-windows
```
1. ファイルを保存し、テキストエディタを終了します。
+ カスタム起動テンプレートを使用する AMI の場合、マネージドノードグループのデフォルト `HttpPutResponseHopLimit` は `2` に設定されます。
# クラスターからマネージドノードグループを削除する
このトピックでは、Amazon EKS マネージド型ノードグループを削除する方法について説明します。マネージド型ノードグループを削除すると、まず Amazon EKS が Auto Scaling グループの最小サイズ、最大サイズ、および必要なサイズをゼロに設定します。これにより、ノードグループがスケールダウンされます。
各インスタンスが終了する前に、Amazon EKS はそのノードを排出するシグナルを送信します。排出プロセス中、Kubernetes はノード上の各ポッドに対して、設定されている `preStop` ライフサイクルフックを実行し、コンテナに `SIGTERM` シグナルを送信してから、正常なシャットダウンのために `terminationGracePeriodSeconds` の間待機します。5 分後もノードが排出されない場合、Amazon EKS は自動スケーリングにインスタンスの強制終了を続行させます。すべてのインスタンスが終了すると、Auto Scaling グループは削除されます。
**重要**
クラスター内の、他のマネージド型ノードグループで使用されていないノード IAM ロールを使用している、マネージド型ノードグループを削除すると、そのロールは `aws-auth` `ConfigMap` から削除されます。クラスター内のいずれかのセルフマネージド型ノードグループが同じノード IAM ロールを使用している場合、セルフマネージド型ノードは `NotReady` ステータスに移行します。さらに、クラスター操作も中断されます。クラスターのプラットフォームバージョンが「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」の前提条件セクションに記載されている最低バージョン以上である場合、セルフマネージドノードグループにのみ使用しているロールのマッピングを追加するには、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。プラットフォームバージョンがアクセスエントリに必要な最小バージョンより前の場合は、エントリを `aws-auth` `ConfigMap` に追加し直すことができます。詳細については、ターミナルに `eksctl create iamidentitymapping --help` を入力してください。
マネージド型ノードグループを削除するには、以下を使用します。
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [AWS マネジメントコンソール](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**マネージド型ノードグループを `eksctl` を使用して削除する**
次のコマンドを入力します。`` をすべて自分の値に置き換えてください。
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
その他のオプションについては、`eksctl` ドキュメントの「[ノードグループの削除と排出](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)」を参照してください。
## AWS マネジメントコンソール
**マネージド型ノードグループを AWS マネジメントコンソール を使用して削除する**
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[クラスター]** ページで、削除するノードグループを含むクラスターを選択します。
1. 選択したクラスターページで、**[コンピューティング]** タブを選択します。
1. **[Node groups]** (ノードグループ) セクションで、削除するノードグループを選択してください。その後、**[削除]** をクリックします。
1. **[ノードグループの削除]** 確認ダイアログボックスで、ノードグループの名前を入力します。その後、**[削除]** をクリックします。
## AWS CLI
**マネージド型ノードグループを AWS CLI を使用して削除する**
1. 次のコマンドを入力します。`` をすべて自分の値に置き換えてください。
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. CLI 設定で `cli_pager=` が設定されている場合は、キーボードの矢印キーを使用して、応答出力をスクロールします。終了したら `q` キーを押します。
その他のオプションについては、「*AWS CLI コマンドリファレンス*」の ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` コマンドを参照してください。