マネージド型ノードグループ - Amazon EKS
マネージド型ノードグループの概念マネージド型ノードグループのキャパシティータイプ

マネージド型ノードグループ

Amazon EKS マネージド型ノードグループは、Amazon EKS Kubernetes クラスターのノード (Amazon EC2 インスタンス) のプロビジョニングとライフサイクル管理を自動化します。

Amazon EKS マネージド型ノードグループでは、Kubernetes アプリケーションを実行するためのコンピューティング性能を提供する Amazon EC2 インスタンスを個別にプロビジョニングまたは登録する必要はありません。1 回の操作で、クラスターのノードを作成、自動的に更新、または終了できます。ノードを更新し、終了させることで、ノードを自動的にドレーンし、アプリケーションを利用できる状態にしておきます。

すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。各ノードグループは、定義された複数のアベイラビリティーゾーンで実行できます。

Amazon EKS コンソール、eksctl、AWS CLI、AWS API、または AWS CloudFormation を含む Infrastructure as Code ツールを使用し、新規または既存のクラスターにマネージド型ノードグループを追加できます。マネージド型ノードグループの一部として起動されたノードは、自動的に Kubernetes Cluster Autoscaler によって自動検出用にタグ付けされます。ノードグループを使用すると、Kubernetes ラベルをノードに適用し、いつでも更新することができます。

Amazon EKS マネージド型ノードグループの使用に追加料金はかかりません。お支払いいただくのはプロビジョニングした AWS リソースの分だけです。これには、Amazon EC2 インスタンス、Amazon EBS ボリューム、Amazon EKS クラスター時間、その他の AWS インフラストラクチャが含まれます。最低料金や前払いの義務は発生しません。

新しい Amazon EKS クラスターおよびマネージド型ノードグループの使用を開始するには、「Amazon EKS の開始方法 – AWS Management Console と AWS CLI」を参照してください。

既存のクラスターにマネージド型ノードグループを追加するには、「マネージド型ノードグループの作成」を参照してください。

マネージド型ノードグループの概念

  • Amazon EKS マネージド型ノードグループは、Amazon EC2 インスタンスを作成し、管理します。

  • すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。さらに、Amazon EC2 インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。

  • マネージド型ノードグループの Auto Scaling グループは、グループの作成時に指定するすべてのサブネットにまたがります。

  • Amazon EKS は、Kubernetes Cluster Autoscaler の使用を設定するようにマネージド型ノードグループリソースをタグ付けします。

    重要

    Amazon EBS ボリュームによってバックアップされ、Kubernetes Autoscaling を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、--balance-similar-node-groups 機能を有効にする必要があります。

  • カスタム起動テンプレートを使用すると、マネージド型ノードをデプロイするときに、柔軟性とカスタマイズのレベルを向上させることができます。例えば、追加の kubelet 引数を指定して、カスタム AMI を使用できます。詳細については、「起動テンプレートを使用したマネージドノードのカスタマイズ」を参照してください。マネージド型ノードグループを最初に作成するときにカスタム起動テンプレートを使用しない場合は、自動生成された起動テンプレートを使用できます。自動生成されたテンプレートを手動で変更しないでください。エラーが発生します。

  • Amazon EKS は、マネージド型ノードグループで CVE およびセキュリティパッチの責任共有モデルに従います。マネージド型ノードが Amazon EKS 最適化 AMI を実行する場合、バグや問題が報告されると、Amazon EKS が AMI のパッチ適用バージョンの構築を担当します。修正を公開できます。ただし、これらのパッチが適用された AMI バージョンのマネージド型ノードグループへのデプロイはユーザーが担当します。マネージド型ノードでカスタム AMI を実行する場合、バグや問題が報告され、AMI をデプロイする場合は、ユーザーがパッチ適用バージョンの構築を担当します。詳細については、「マネージド型ノードグループの更新」を参照してください。

  • Amazon EKS マネージド型ノードグループは、パブリックサブネットとプライベートサブネットの両方で起動できます。2020 年 4月 22 日 以降にパブリックサブネットでマネージド型ノードグループを起動した場合、インスタンスがクラスターに正常に参加するには、サブネットで MapPublicIpOnLaunch を true に設定する必要があります。パブリックサブネットが eksctl、または 2020 年 3 月 26 日以降に Amazon EKS が販売した AWS CloudFormation テンプレートを使用して作成された場合、この設定はすでに true に設定されています。パブリックサブネットが 2020 年 3 月 26 日 より前に作成されている場合は、設定を手動で変更する必要があります。詳細については、「サブネットのパブリック IPv4 アドレッシング属性の変更」を参照してください。

  • マネージド型ノードグループをプライベートサブネットにデプロイする場合、Amazon ECR にアクセスしてコンテナイメージをプルできることを確認します。これを行うには、NAT ゲートウェイをサブネットのルートテーブルに接続するか、次の AWS PrivateLink VPC エンドポイントを追加します。

    • 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

    その他の一般的に使用されるサービスとエンドポイントについては、「プライベートクラスターの要件」を参照してください。

  • マネージド型ノードグループは、AWS Outposts、AWS Wavelength または AWS Local Zones にはデプロイできません。

  • 1 つのクラスター内に複数のマネージド型ノードグループを作成できます。例えば、一部のワークロード用に、標準 Amazon EKS 最適化 Amazon Linux AMI を使用するノードグループを作成し、GPU サポートを必要とするワークロード用に GPU バリアントを使用する別のノードグループを作成できます。

  • マネージド型ノードグループで Amazon EC2 インスタンスのステータスチェックに障害が発生した場合、Amazon EKS は問題の診断に役立つエラーコードを返します。詳細については、「マネージド型ノードグループのエラー」を参照してください。

  • Amazon EKS は、マネージド型ノードグループインスタンスに Kubernetes ラベルを追加します。これらの Amazon EKS によって提供されたラベルには、プレフィックス eks.amazonaws.com が付与されます。

  • Amazon EKS では、終了または更新時に Kubernetes API を使用して、ノードを自動的にドレーンします。

  • AZRebalance を使用してノードを終了、または目的のノード数を減らす際には、ポッドの停止状態の予算は考慮されません。これらのアクションはノードの Pods を削除しようとします。しかし、15 分を超過する場合、ノード上のすべての Pods が終了しているかどうかにかかわらず、ノードは終了します。ノードが終了するまでの期間を延長するには、Auto Scaling グループにライフサイクルフックを追加します。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「ライフサイクルフックの追加」を参照してください。

  • スポット中断通知またはキャパシティリバランス通知を受け取った後、ドレインプロセスを正しく実行するには、CapacityRebalance を true に設定する必要があります。

  • マネージドノードグループを更新すると、Pods 用に設定した Pod の停止状態の予算が考慮されます。詳細については、「マネージド型ノードの更新動作」を参照してください。

  • Amazon EKS マネージド型ノードグループの使用に、追加料金はかかりません。プロビジョニングした AWS リソースに対してのみ料金が発生します。

  • ノードの Amazon EBS ボリュームを暗号化する場合は、起動テンプレートを使用してノードをデプロイできます。起動テンプレートを使用せずに、暗号化された Amazon EBS ボリュームを持つマネージド型ノードをデプロイするには、アカウントに作成された新しい Amazon EBS ボリュームをすべて暗号化してください。詳細については、「Amazon EC2 Linux インスタンス用ユーザーガイド」の「デフォルトで暗号化」を参照してください。

マネージド型ノードグループのキャパシティータイプ

マネージド型ノードグループを作成する場合、キャパシティータイプをオンデマンドまたはスポットのいずれかから選択できます。Amazon EKS は、Amazon EC2 Auto Scaling グループを使用して、マネージド型ノードグループをデプロイします。これにはオンデマンドのみか、Amazon EC2 スポットインスタンスのみが含まれます。単一の Kubernetes クラスター内で、耐障害性のあるアプリケーションの Pods をスポットのマネージド型ノードグループに、耐障害性のないアプリケーションのポッドをオンデマンドのノードグループに、それぞれスケジュールできます。デフォルトでは、マネージド型ノードグループはオンデマンド 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 グループを参照してください。

  • Amazon EKS は、キャパシティータイプを eks.amazonaws.com/capacityType: ON_DEMAND に指定しているマネージド型ノードグループ内のすべてのノードに、次の Kubernetes ラベルを追加します。このラベルを使用すると、オンデマンドノードで、ステートフルまたは非フォールトトレラントなアプリケーションをスケジュールできます。

スポット

Amazon EC2 スポットインスタンスは、オンデマンドの料金から大きな割引で提供される、Amazon EC2 の予備容量です。Amazon EC2 スポットインスタンスは、EC2 から容量の返却を求められると 2 分間の中断通知をもって中断されることがあります。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「スポットインスタンス」を参照してください。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 容量の再調整を参照してください。

    • スポットノードが再調整の推奨事項を受け取ると、Amazon EKS は自動的に新しい代替スポットノードの起動を試みます。

    • 代替スポットノードが Ready 状態になる前にスポットの 2 分間の中断通知が到着すると、Amazon EKS は再調整に関する推奨事項を受け取ったスポットノードのドレーンを開始します。Amazon EKS はベストエフォートベースでノードをドレインします。そのため、Amazon EKS が既存のノードをドレインする前に、代替ノードがクラスターに参加するのを待機するという保証はありません。

    • 代替スポットノードがブートストラップされ、Kubernetes 上で Ready 状態になると、Amazon EKS は再調整に関する推奨事項を受信したスポットノードを遮断し、ドレーンします。スポットノードを遮断すると、サービスコントローラーがこのスポットノードに新しいリクエストを送信しないようにします。正常でアクティブなスポットノードのリストからも削除されます。スポットノードをドレインすると、実行中の Pods が正常に削除されます。

  • Amazon EKS は、キャパシティータイプを eks.amazonaws.com/capacityType: SPOT に指定しているマネージド型ノードグループ内のすべてのノードに、次の Kubernetes ラベルを追加します。このラベルを使用して、スポットノードで耐障害性のあるアプリケーションをスケジュールできます。

キャパシティータイプを選択する際の考慮事項

オンデマンドキャパシティーとスポットキャパシティーのどちらでノードグループをデプロイするかを決定するときは、次の条件を考慮する必要があります。

  • スポットインスタンスは、ステートレスかつフォールトトレラントで、柔軟性の高いアプリケーションに適しています。これには、バッチトレーニングワークロード、機械学習トレーニングワークロード、Apache Spark などのビッグデータ ETL、キュー処理アプリケーション、ステートレス API エンドポイントなどがあります。スポットは Amazon EC2 の予備容量であり、時間の経過とともに変化する可能性があるため、中断されても問題ないワークロードには、スポットキャパシティーを使用することをお勧めします。具体的には、スポット容量は、必要な容量が使用できない期間を許容できるワークロードに適しています。

  • 非フォールトトレラントなアプリケーションには、オンデマンドを使用することをお勧めします。これには、モニタリングツールやオペレーションツールなどのクラスター管理ツール、StatefulSets を必要とするデプロイ、データベースなどのステートフルなアプリケーションなどが含まれます。

  • スポットインスタンスの使用中にアプリケーションの可用性を最大化するには、スポットのマネージド型ノードグループが複数のインスタンスタイプを使用するように構成することをお勧めします。複数のインスタンスタイプを使用する場合は、次のルールを適用することをお勧めします。

    • マネージド型ノードグループ内で Cluster Autoscaler を使用している場合、同じサイズの 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 つのインスタンスタイプを渡さないでください。起動テンプレートを使用したノードグループのデプロイについての詳細は、「起動テンプレートを使用したマネージドノードのカスタマイズ」をご覧ください。