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

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

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

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

Amazon EKS マネージド型ノードグループでは、Kubernetes アプリケーションを実行するためのコンピューティング能力を提供する Amazon EC2 インスタンスを個別にプロビジョニングまたは登録する必要はありません。1 回のオペレーションで、クラスターのノードを作成、自動更新、または終了できます。ノードはAmazon EKS、アカウント内の最新のAWS最適化された AMIsを使用して実行されます。ノードの更新と終了は自動的かつ適切に行われ、アプリケーションが利用できるようにノードがドレーンされます。

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

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

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

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

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

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

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

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

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

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

    重要

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

  • デフォルトでは、マネージド型ノードグループのインスタンスは、そのクラスターの Kubernetes バージョンに最新バージョンのAmazon EKS最適化された Amazon Linux 2 AMI を使用します。Amazon EKS 最適化された Amazon Linux 2 AMI の標準バリアントと GPU バリアントのいずれかを選択できます。起動テンプレートを使用してデプロイする場合は、カスタム AMI を使用することもできます。詳細については、「 」を参照してください起動テンプレートのサポート

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

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

  • プライベートサブネットで VPC エンドポイントを使用する場合は、com.amazonaws.region.ecr.api と com.amazonaws.region.ecr.dkr のエンドポイントおよび Amazon S3 のゲートウェイエンドポイントを作成する必要があります。詳細については、「Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink)」を参照してください。

  • マネージド型ノードグループは、 AWS Outposts または AWS Wavelength のAWSローカルゾーンにデプロイすることはできません。

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

  • マネージド型ノードグループで正常性の問題が発生した場合は、Amazon EKS から問題の診断に役立つエラーメッセージが返されます。詳細については、「 」を参照してくださいマネージド型ノードグループのエラー

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

  • Amazon EKS は、終了または更新時に Kubernetes API を使用してノードを自動的にドレーンします。更新は、ポッドに設定したポッド中断予算を優先します。

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

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

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

マネージド型ノードグループを作成するときに、[オンデマンド] または [スポットキャパシティータイプ] を選択できます。 は、オンデマンドインスタンスのみまたはAmazon EKSスポットインスタンスのみを含む Amazon EC2 Auto Scaling グループを持つマネージド型ノードグループをAmazon EC2デプロイします。耐障害性を備えたアプリケーションのポッドをスポットマネージド型ノードグループにスケジュールしたり、耐障害性の低いアプリケーションを単一の Kubernetes クラスター内のオンデマンドノードグループにスケジュールしたりできます。デフォルトでは、マネージド型ノードグループはオンデマンドAmazon EC2インスタンスをデプロイします。

オンデマンド

オンデマンドインスタンスでは、長期契約なしで、コンピューティング性能に対して秒単位で支払います。

仕組み

デフォルトでは、容量タイプを指定しない場合、マネージド型ノードグループはオンデマンドインスタンスでプロビジョニングされます。マネージド型ノードグループは、次の設定を適用してAmazon EC2Auto Scaling、 グループをユーザーに代わって設定します。

  • オンデマンド容量をプロビジョニングする配分戦略は、 に設定されますprioritized。マネージド型ノードグループは、 API で渡されたインスタンスタイプの順序を使用して、オンデマンド容量を満たすときに最初に使用するインスタンスタイプを決定します。たとえば、3 つのインスタンスタイプを c5.large、c4.large、 の順序で指定できますc3.large。オンデマンドインスタンスが起動されると、マネージド型ノードグループは c5.large、、 の順にオンデマンド容量を満たしc4.largec3.largeます。詳細については、の「Amazon EC2 Auto Scalinggroup」を参照してくださいAmazon EC2 Auto Scaling ユーザーガイド。

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

Spot

Amazon EC2 スポットインスタンスは、オンデマンド価格から大幅な割引になる予備のAmazon EC2キャパシティーです。 Amazon EC2スポットインスタンスはEC2 で容量が戻る必要がある場合に 2 分間の中断通知で中断されることがあります。詳細については、の「スポットインスタンス」を参照してくださいLinux インスタンス用 Amazon EC2 ユーザーガイド。マネージド型ノードグループをAmazon EC2スポットインスタンスで設定して、Amazon EKSクラスターで実行されているコンピューティングノードのコストを最適化できます。

仕組み

マネージド型ノードグループ内でスポットインスタンスを使用するには、キャパシティータイプを に設定してマネージド型ノードグループを作成する必要がありますspot。マネージド型ノードグループは、次のスポットのベストプラクティスを適用してAmazon EC2Auto Scaling、 グループをユーザーに代わって設定します。

  • スポット容量をプロビジョニングする配分戦略はcapacity-optimized、スポットノードが最適なスポット容量プールに確実にプロビジョニングされるように、 に設定されます。容量の割り当てに使用できるスポット容量プールの数を増やすには、複数のインスタンスタイプを使用するようにマネージド型ノードグループを設定することをお勧めします。

  • Amazon EC2 スポット容量の再分散が有効になるためAmazon EKS、 は、スポットノードが正常にドレインして再分散し、スポットノードが中断されるリスクが高まったときのアプリケーションの中断を最小限に抑えることができます。詳細については、の「Amazon Amazon EC2 Auto Scaling 容量の再分散」を参照してくださいAmazon EC2 Auto Scaling ユーザーガイド。

    • スポットノードが再調整の推奨事項を受け取ると、 Amazon EKS は自動的に新しい置き換え先スポットノードの起動を試み、クラスターに正常に参加するまで待機します。

    • 置き換え先スポットノードがブートストラップされ、Kubernetes Ready の 状態になると、 Amazon EKS は再調整の推奨事項を受け取ったスポットノードをドロンおよびドレーンします。スポットノードをコニングすると、サービスコントローラーはこのスポットノードに新しいリクエストを送信しなくなります。また、正常なアクティブなスポットノードのリストからも削除されます。スポットノードのドレインにより、実行中のポッドが適切に削除されます。

    • 代替スポットノードが Ready 状態になる前にスポットの 2 分の中断通知が到着すると、 は再調整の推奨事項を受け取ったスポットノードのドレインAmazon EKSを開始します。

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

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

オンデマンド容量とスポット容量のどちらを使用してノードグループをデプロイするかを決定するときは、次の条件を考慮する必要があります。

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

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

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

    • マネージド型ノードグループ内で を使用している場合はCluster Autoscaler、同じ量の vCPU およびメモリリソースを持つ柔軟なインスタンスタイプのセットを使用して、クラスター内のノードが想定どおりにスケールされるようにすることをお勧めします。たとえば、4 つの vCPUs と 8 GiB メモリが必要な場合はc3.xlarge、、、、c4.xlargec5.xlarge、c5d.xlarge、c5a.xlargec5nまたはその他の同様のインスタンスタイプを使用することをお勧めします。

    • アプリケーションの可用性を高めるために、複数のスポットマネージド型ノードグループをデプロイすることをお勧めします。各グループには、同じ vCPU とメモリリソースを持つ柔軟なインスタンスタイプのセットが使用されます。たとえば、4 vCPUs と 8 GiB メモリが必要な場合はc3.xlarge、、、、、、c4.xlargec5.xlargec5d.xlargec5a.xlargec5n.xlarge、 などの同様のインスタンスタイプを持つ 1 つのマネージド型ノードグループ、および m3.xlarge、、、m4.xlargem5.xlargem5d.xlarge、、m5a.xlarge、、m5n.xlargeまたはその他の同様のインスタンスタイプを持つ 2 番目のマネージド型ノードグループを作成することをお勧めします。

    • カスタム起動テンプレートを使用するスポットキャパシティータイプを使用してノードグループをデプロイする場合は、起動テンプレートを通じて単一のインスタンスタイプを渡すのではなく、 API を使用して複数のインスタンスタイプを渡します。起動テンプレートを使用したノードグループのデプロイの詳細については、「」起動テンプレートのサポートを参照してください。