ワークロード、フォールトトレランス、クラスター規模に基づいて、ACK のワーカーノードとマスターノード向けに ECS インスタンスタイプを選択します。
ACK でサポートされないインスタンスタイプ
次のインスタンスタイプは、ACK のワーカーノードまたはマスターノードとして使用できません。
一般的な制限
| サポートされないインスタンスファミリー | 例 | 理由 |
|---|---|---|
| t5、バースト可能 | ecs.t5-lc2m1.nano | パフォーマンスが不安定なため、クラスターが不安定になる可能性があります |
| t6、バースト可能 | ecs.t6-c4m1.large | パフォーマンスが不安定なため、クラスターが不安定になる可能性があります |
| vCPU コアが 4 未満のインスタンスタイプ | ecs.g6.large | 安定したクラスター運用にはスペックが低すぎます |
| c6t、セキュリティ強化コンピューティング最適化 | ecs.c6t.large | サポートされていません |
| g6t、セキュリティ強化汎用 | ecs.g6t.large | サポートされていません |
| Super Computing Cluster (SCC) | ecs.sccg7.32xlarge | サポートされていません |
低スペックのインスタンスタイプを使用するには、Quota Center でリクエストを送信してください。
GPU ワークロードについては、ACK でサポートされる GPU アクセラレーションインスタンスファミリーをご参照ください。
Terway ネットワークプラグインの制限
Terway を使用する場合、ノードあたりの Pod 容量は、インスタンスタイプがサポートする Elastic Network Interface (ENI) の数に依存します。Pod の最小しきい値を下回るインスタンスタイプは互換性がありません。
-
Inclusive ENI モード または [共有 ENI + Trunk ENI モード]：ノードあたりの Pod 上限は 11 を超える必要があります。式：
(ENI 数 - 1) × ENI あたりのプライベート IP 数 > 11例：ecs.g6.large は 2 つの ENI をサポートし、それぞれ 6 個のプライベート IPv4 アドレスを持ちます。Pod 上限 =(2 - 1) × 6 = 6。このタイプは互換性がありません。 -
[Exclusive ENI モード]：ノードあたりの Pod 上限は 6 を超える必要があります。式：
ENI 数 - 1 > 6例：ecs.g6.xlarge は 3 つの ENI をサポートします。Pod 上限 =3 - 1 = 2。このタイプは互換性がありません。
Terway モード別の互換性のあるインスタンスタイプについては、Terway ネットワークプラグインを使用するをご参照ください。
少数の大規模インスタンスの方が高性能である理由
各ノードは、クラスター管理のために CPU、メモリ、ディスクを予約します。小規模インスタンスでは、この予約が総容量に占める割合が大きくなり、ワークロードに割り当てられる余裕が少なくなります。
断片化により、さらに状況が悪化します。コンテナにリソースを割り当てた後、小規模インスタンスに残るリソースが別のコンテナにとって小さすぎる場合、未使用のまま残ります。
大規模インスタンスは、これら 2 つの問題を解決します：
-
ネットワーク効率の向上：より多くのコンテナが 1 つのインスタンスを共有するため、ノード間トラフィックが削減されます。また、大規模インスタンスはより高いネットワーク帯域幅を提供します。
-
イメージのプルの高速化：コンテナイメージはノードごとに 1 回だけプルされ、コンテナ間で共有されます。小規模インスタンスが多数ある場合、同じイメージが各ノードでプルされるため、スケールアウトが遅くなります。
ワーカーノード仕様の選定
最小仕様
少なくとも 4 CPU コアと 8 GB メモリを備えたインスタンスタイプを使用してください。
フォールトトレランスを考慮したサイジング
日常のワークロードに必要な CPU コア総数を算出し、サービスを中断せずにインスタンス障害に対応できるようにノードをサイジングします。
例：
| フォールトトレランス目標 | ノード数 | ノードサイズ | 最大運用負荷 |
|---|---|---|---|
| 10% (ノード 1 台が障害) | 少なくとも 10 | 16 CPU コア | 144 コア (160 × 90%) |
| 20% (ノード 1 台が障害) | 少なくとも 5 | 32 CPU コア | 128 コア (160 × 80%) |
インスタンスが 1 台障害となっても、残りのインスタンスでピーク負荷を処理し続けます。
CPU 対メモリ比
ワークロードの種類に合う比率を選択してください：
-
1:2 または 1:4：汎用ワークロード
-
1:8：Java サービスなどのメモリ集約型アプリケーション
GPU ワークロード
安定したスケジューリングのため、同一のノードプール内で GPU と非 GPU のインスタンスタイプを混在させないでください。
永続メモリ最適化インスタンス
re6p などのインスタンスファミリーは、通常メモリと永続メモリを組み合わせたハイブリッドアーキテクチャを採用しています。永続ストレージを有効にするには、不揮発性メモリボリュームをご参照ください。サポートされるタイプについては、インスタンスファミリーをご参照ください。
大規模クラスター：ECS ベアメタルインスタンス
日常的な利用規模が約 1,000 CPU コアの場合は、ECS ベアメタルインスタンスを使用してください。単一のインスタンスが少なくとも 96 CPU コアを提供するため、1,000 コアのクラスターでも必要なノード数は 10～11 台で済みます。詳細については、「ECS ベアメタルインスタンス」をご参照ください。
マスターノード仕様の選定
マスターノードでは etcd、kube-apiserver、kube-controller が実行されます。本番環境の ACK 専用クラスターでは、クラスター規模に合わせてマスターノードをサイジングします。
ここでのクラスター規模はノード数を基準とします。実際には、Pod 数、デプロイ頻度、リクエスト数も有効なサイジング指標です。
テスト用途に限り小規模インスタンスを使用してください。本番環境のクラスターでは、次の表からマスターノード仕様を選択してください。
| ノード数 | 推奨マスターノード仕様 |
|---|---|
| 1～5 | 4 CPU コア、8 GB メモリ (2 コア / 4 GB 以下は非推奨) |
| 6～20 | 4 CPU コア、16 GB メモリ |
| 21～100 | 8 CPU コア、32 GB メモリ |
| 100～200 | 16 CPU コア、64 GB メモリ |
| 200～500 (ブラスト半径のリスクを評価) | 32 CPU コア、128 GB メモリ |
ECS ベアメタルインスタンス
Alibaba Cloud の仮想化 2.0 を基盤とする ECS ベアメタルインスタンスは、VM の弾力性と物理サーバーのパフォーマンスを両立し、入れ子になった仮想化をサポートします。
ECS ベアメタルインスタンスは、専用コンピューティング、暗号化コンピューティング、ハイブリッドクラウドのデプロイに適しています。サポートされるインスタンスファミリーについては、ECS ベアメタルインスタンスの概要をご参照ください。
ECS ベアメタルインスタンスを使用するタイミング：
-
大規模なクラスターの場合：日常的な利用規模が約 1,000 CPU コアの場合、各インスタンスが少なくとも 96 コアを提供するため、必要なノード数は 10～11 台で済みます。
-
トラフィックの急増に対して迅速なスケールアウトが必要な場合：ECS ベアメタルインスタンスは、同等スペックの物理サーバーを上回るパフォーマンスを提供し、EC サイトのプロモーションなど突発的なトラフィックの急増に対して、数百万 vCPU までスケールアウトできます。