多数の管理対象ノードがある拡張クラスタを定義する際の考慮事項
Kubernetes Engine (OKE)を使用して拡張クラスタを作成する際に考慮する制限およびその他の要因についてご確認ください。
拡張クラスタを定義する場合、基本クラスタを定義する場合よりも、クラスタごとにかなり多くの管理対象ノードを指定できます。ただし、次のようないくつかの制限があります。
- 拡張クラスタで許可される管理対象ノード・プール当たりの管理対象ノードの最大数
- 拡張クラスタで許可される管理対象ノードの最大数
これらの制限の現在の値については、Kubernetesエンジンの制限を参照してください。
また、拡張クラスタで許可される管理対象ノードの数が多い場合に考慮する必要があるその他の要因も多数あります。次の推奨事項を提供します。
- 多数の大きいノード・プールではなく、多数の小さいノード・プールを定義することをお薦めします。たとえば、拡張クラスタに2,000個の管理対象ノードを設定する場合は、それぞれに1,000個の管理対象ノードを持つ2つのノード・プールではなく、それぞれに500個の管理対象ノードを持つ4つのノード・プールを定義することをお薦めします。
- カスタムのcloud-initスクリプトを使用して、kubeletに追加のオプションを構成することをお薦めします(「カスタムCloud-init初期化スクリプトを使用した管理対象ノードの設定」を参照)。これらの追加オプションは、
kubelet-extra-argsと呼ばれることもあります。多数のkubelet-extra-argsオプションは、多数の管理対象ノードを含む拡張クラスタを管理する場合に特に役立ちます。kubeletオプションの完全なリストは、Kubernetesのドキュメントを参照してください。 - 常に、特定のロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セットにバックエンド・サーバーとして含めるワーカー・ノードのサブセットのみを選択することをお薦めします。デフォルトでは、Kubernetes EngineがタイプLoadBalancerのKubernetesサービス用にOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングすると、クラスタ内のすべてのワーカー・ノードがバックエンド・サーバーとしてバックエンド・セットに含まれます。ただし、バックエンド・セットで許可されるバックエンド・サーバーの数とバックエンド・サーバーの合計数には制限があります(ロード・バランシング・リソースの制限およびネットワーク・ロード・バランサの制限を参照)。したがって、基本クラスタを定義する場合でも拡張クラスタを定義する場合でも、バックエンド・セットに含めるクラスタ内のワーカー・ノードのサブセットのみを選択することをお薦めします。拡張クラスタで許可される管理対象ノードの数が多い場合、ワーカー・ノードのサブセットのみを選択することは特に重要です。バックエンド・セットに含めるワーカー・ノードの選択を参照してください。