**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**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 アカウント内で実行されます。 + Amazon EKS は、マネージド型ノードグループのスケーリング設定を定期的に同期して、実際のAuto Scaling グループ値と一致させます。Cluster Autoscaler などの外部アクターがAuto Scaling グループのサイズを変更すると、`DescribeNodegroup` は最終的にそれらの変更を反映します。スケーリング設定を明示的に変更せずにノードグループの更新またはアップグレードを開始すると、ワークフローはノードグループの保存されたスケーリング設定ではなく現在のAuto Scaling グループ値を使用します。ストアドスケーリング設定は、明示的に `UpdateNodegroupConfig` リクエストに含める場合にのみ優先されます。 + マネージド型ノードグループの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 ユーザーガイド*」の「[デフォルトで暗号化](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)」をご覧ください。