View a markdown version of this page

EC2 インスタンスストアを設定した AWS Outposts にある Amazon EKS ローカルクラスターのインスタンスタイプとプレイスメントを選択する - Amazon EKS
コントロールプレーンアーキテクチャインスタンスタイプの選択コントロールプレーンと etcd のプレイスメント容量プランニングプレイスメントの問題のトラブルシューティング

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EC2 インスタンスストアを設定した AWS Outposts にある Amazon EKS ローカルクラスターのインスタンスタイプとプレイスメントを選択する

このトピックでは、Kubernetes コントロールプレーンインスタンスタイプを選択し、プレイスメントを設定して、EC2 インスタンスストアを設定した AWS Outpost にあるローカル Amazon EKS クラスターの高可用性要件を満たすためのガイダンスを提供します。

注記

Outpost が EC2 インスタンスストアではなく Amazon EBS で設定されている場合、このトピックで説明されているアーキテクチャは Outpost に使用できません。EBS を設定した Outposts は、既存のローカルクラスターの実装を引き続き使用します。詳細については、「キャパシティに関する考慮事項に基づいて、AWS Outposts で Amazon EKS クラスターのインスタンスタイプとプレイスメントグループを選択する」を参照してください。

更新されたローカルクラスターアーキテクチャを使用して EBS-backed Outpost にローカルクラスターを作成する場合は、AWS アカウントチームにお問い合わせください。

コントロールプレーンアーキテクチャ

ローカルクラスターの Kubernetes コントロールプレーンは、Outpost の 6 つの EC2 インスタンスで実行されます。

  • 3 つのコントロールプレーンインスタンス — Kubernetes API サーバー、スケジューラ、コントローラーマネージャーなどの Kubernetes コントロールプレーンコンポーネントをホストします。

  • 3 つの etcd インスタンス — Kubernetes クラスターの状態を外部 etcd トポロジーに保存します。

これらのインスタンスは、Outpost の AWS マネージドサービスアカウントで実行されます。これらは、AWS アカウントまたは Amazon EC2 コンソールでは EC2 インスタンスとして表示されません。コントロールプレーンによって消費されるキャパシティは、AWS Outposts コンソールに表示されます。

コントロールプレーンは、負荷がかかっても水平スケーリングされません。別のコントロールプレーンインスタンスサイズが必要な場合は、新しいクラスターを作成する必要があります。

インスタンスタイプの選択

AWS Outposts にある Amazon EKS ローカルクラスターの更新されたアーキテクチャでは、Kubernetes コントロールプレーンは専用の etcd トポロジーを使用します。つまり、API サーバーと etcd は個別のインスタンスで実行されます。クラスターを作成するときは、API サーバー用の controlPlaneInstanceType と etcd 用の etcdInstanceType の 2 つのインスタンスタイプを指定します。

選択するインスタンスタイプは Outpost で使用できる必要があります。使用可能なインスタンスファミリーは Outpost の世代と SKU に依存し、異なるインスタンスファミリーは同じインスタンスサイズで異なる vCPU とメモリ設定を持つことがあります。

API サーバーcontrolPlaneInstanceType ()

想定されるワーカーノード vCPU メモリ

1～20

2

8 GiB

21～100

4

16 GiB

101～250

8

32 GiB

251～500

16

64 GiB

etcd (etcdInstanceType)

想定されるワーカーノード vCPU メモリ

1～50

2

8 GiB

51～250

4

16 GiB

251～500

8

32 GiB
重要

ローカルクラスターの存続期間中、Outpost に controlPlaneInstanceType の 3 つのインスタンスと etcdInstanceType の 3 つのインスタンスのためのキャパシティがあることを確認します。

これらの表は、厳格な要件ではなくガイドラインとして使用してください。クラスターの作成後は controlPlaneInstanceType と etcdInstanceType を変更できないため、予想される増加に対応するインスタンスファミリーとサイズを選択することをお勧めします。いずれかを変更するには、新しいクラスターを作成する必要があります。

コントロールプレーンと etcd のプレイスメント

高可用性を実現するために、コントロールプレーンと etcd のインスタンスを複数のハードウェア障害ドメインに分散させることをお勧めします。この分散は、outpostConfig の controlPlanePlacement と etcdPlacement の spreadLevel プロパティを使用して制御できます。spreadLevel を設定すると、Amazon EKS は分散戦略を使用して EC2 プレイスメントグループを作成します。プレイスメントグループを事前に作成する必要はありません。

注記

controlPlanePlacement の groupName パラメータは、インスタンスストアベースの EC2 インスタンスを実行する Outposts では使用されません。以前にローカルクラスターでプレイスメントグループを使用していた場合は、代わりに spreadLevel を使用するようになりました。

分散レベル

spreadLevel プロパティは 2 つの値を受け入れます。

  • host — コントロールプレーンインスタンスを異なる物理ホストに分散させます。選択したインスタンスタイプで設定されたホストが少なくとも 3 つ必要です。

  • rack — コントロールプレーンインスタンスを異なる物理 Outpost ラックに分散させます。選択したインスタンスタイプで設定されたホストがあるラックが少なくとも 3 つ必要です。

容量プランニング

ローカルクラスターの Outpost のキャパシティを計画する場合は、次のものを考慮します。

  • コントロールプレーンと etcd のインスタンス: クラスターあたり 6 つのインスタンス (controlPlaneInstanceType の 3 つと etcdInstanceType の 3 つ)。

  • ワーカーノード: セルフマネージド型ノードグループの EC2 インスタンス。

  • 仮想化ホスト: コントロールプレーンは仮想化ホストで実行する必要があります。Outpost には、十分なキャパシティを持つ仮想化ホストが必要です。

プレイスメントの問題のトラブルシューティング

分散レベルを指定した後にクラスターが長期間 CREATING 状態または UPDATING 状態のままになった場合は、分散トポロジーを満たすために選択したインスタンスタイプを持つ十分なホストまたはラックが Outpost にあることを確認します。

ローカルクラスターのトラブルシューティングの詳細については、「EC2 インスタンスストアを設定した AWS Outposts にあるローカルの Amazon EKS クラスターをトラブルシューティングする」を参照してください。