Google Kubernetes Engine クラスタのサイズとスコープの選択

この記事では、どのワークロードを共有 Google Kubernetes Engine クラスタで実行するかを決定してクラスタの正しいサイズを特定する際に考慮する必要がある基準を示します。

仮想マシンの代わりにコンテナを使用すると、より多くのワークロードを同じインフラストラクチャ上で実行すると同時にワークロードどうしを分離できます。

アプリケーションと、そのアプリケーションで実行するコンテナでは、CPU とメモリの要件が異なります。コンテナ オーケストレーション プラットフォームである Kubernetes は、マシン間でコンテナをスケジューリングし、CPU とメモリの要件に対応します。マシンの使用をどれだけ最適化できるかは、ワークロードと、ワークロードのスケジュールに使用できるマシンによって異なります。

多数のワークロードを実行している大規模なクラスタでは、少数のワークロードしか実行していない小規模のクラスタよりも高い利用率が期待できます。ただし、多くの異なるワークロード間でクラスタを共有すると、複雑さと制約が増して、それに伴う悪影響が潜在的な利点を上回る可能性があります。

Google Kubernetes Engine は、さまざまなクラスタサイズに対応するように設計されています。クラスタの最小サイズは、クラスタがまたがるゾーンの数で決まります。ゾーンクラスタの場合は 1 つ、リージョナル クラスタの場合は 3 つです。Google Kubernetes Engine クラスタの最大サイズは、次のように定義されています。

  • ゾーンあたり 50 クラスタ
  • クラスタあたり 5000 ノード
  • ノードあたり 100 ポッド
  • 300,000 コンテナ

これらの制限内で、クラスタの適切なサイズを決定します。以下のセクションでは、考慮する必要がある基準とトレードオフの概要を示します。

Google Kubernetes Engine クラスタのサイズを決定する

ワークロードのモビリティ

Kubernetes は、使用可能なリソースが最大限に活用されるように、ノード間でポッドをスケジュールします。スケジューリングでは、ポッドを初めて実行するマシンの選択だけでなく、ポッド停止予算を考慮することも必要です。また、Kubernetes は、実行中のポッドの再スケジュールによって利用率を最適化します。ただし、以下に示す特定の機能がワークロードで使用される場合、最適化は制限されます。

多くのワークロードがこのように制限されている場合、ノード間でのポッドの割り当てはほとんど行われません。ポッドを自由にスケジュールできないということは、最適に利用できないだけでなく、クラスタの自動スケーリングが効果的でなくなることも意味します。最悪の場合、ノードに障害が発生したときに、コンピューティング容量が利用可能であっても、Kubernetes はポッドを再スケジュールできません。

利用率を高くするには、Kubernetes がポッドを自由にスケジュールできるように設定します。それができない場合は、より規模の小さいワークロード固有クラスタの使用を検討してください。ポッドの制約を考慮してノード間でのポッドの割り当てを予測できる場合は、コンテナの CPU およびメモリサイズの要件に一致するマシンサイズを選択できます。冗長性を確保するため、ノードまたはゾーンに障害が発生した場合に、制約に違反することなくワークロードを他のノードに移行できるようにノードプールを構成します。

ワークロードの均一性

ワークロードが完全に均一で、すべてのコンテナに同じ量の CPU とメモリが必要な場合、Kubernetes はノード間でワークロードをスムーズにスケジュールできます。ただし、ワークロードが多様化するほど、断片化によってリソースが浪費されないように割り当てることが難しくなります。多様なワークロードでは、クラスタの規模が大きいほどリソース使用率が高くなる傾向があります。

ワークロードの弾力性

ほとんどの場合、クラスタのワークロードは静的ではありません。デプロイが追加または削除される可能性があります。さらに、最も重要なのは、水平ポッド自動スケーリングの使用によって実行中のポッドの数が変更される可能性があることです。

ワークロードが変動する場合は、クラスタ オートスケーラー機能を有効にします。Google Kubernetes Engine のこの機能が有効になっているときは、必要な処理能力に近づけるために、基盤となるノードプールのノードの追加と削除が動的に行われます。追加で必要になった処理能力をマシン 1 つの処理能力が大幅に上回る場合は、ノードプールに追加されたマシンの利用率が最初は低くなる可能性があります。大規模なクラスタでは、この影響はごくわずかですが、クラスタの規模が小さいほど、オーバーヘッドが大きくなる可能性があります。オーバーヘッドとコストを最小限に抑えるには、より規模の大きいクラスタまたは小さいマシンを使用してください。

Google Kubernetes Engine クラスタのスコープを決定する

ワークロードのリージョン

レイテンシを最小限に抑える、可用性を向上させる、または規制を遵守するために、特定のリージョンだけで、あるいは複数のリージョンでワークロードを実行することが必要になる場合があります。1 つの Google Kubernetes Engine クラスタは、単一リージョン内または単一ゾーン内で実行されます。したがって、ワークロードを実行するために必要なリージョンの数によって、必要な Google Kubernetes Engine クラスタの最小数が決定します。

ワークロードの重要度

インシデントによってミッション クリティカルなワークロードが影響を受けるたびに、オペレーション スタッフに通知して問題を修復できるようにする必要があります。しかし、クラスタがミッション クリティカルなワークロードとクリティカルでないワークロードの両方を実行する場合はどうでしょうか。インシデントが発生した場合、影響を受けるワークロードがクリティカルでないワークロードのみか、クリティカルなワークロードも含まれるかをすぐに判断できない場合があります。Kubernetes ではワークロードを優先度によって分類できますが、同じクラスタ上で同等の重要度を持つワークロードのみを実行する方法をおすすめします。

サービス ディスカバリと通信

同じクラスタ上で動作するワークロードは、Kubernetes のサービス ディスカバリ機能と負荷分散機能を使用できます。ただし、ワークロードがクラスタ間で通信する必要がある場合は、ワークロードが互いを検出してアクセスできるようにするために、外部のサービス レジストリまたはロードバランサの使用が必要になることがあります。

サービス ディスカバリと通信の観点からは、一般的には、従属ワークロード(たとえばフロントエンドとバックエンドのアプリケーション)を単一の大きなクラスタで管理するほうが、複数の小さな専用クラスタで管理するよりも簡単です。

ID とアクセスの管理

Google Cloud Platform(GCP)では、アクセス管理はプロジェクトというスコープの中で処理されます。そのため、組織のチーム構造に従ってプロジェクトをモデル化することが一般的に推奨されます。

Google Kubernetes Engine クラスタはプロジェクトの一部であるため、複数のプロジェクトで共有することはできません。したがって、Google Kubernetes Engine クラスタはプロジェクトの Cloud Identity and Access Management(IAM)構成にも依存します。

クラスタ、チーム、プロジェクトをそろえると、役割と権限の管理が簡単になります。ほとんどの場合は、Cloud IAM での粒度が Kubernetes へのアクセスの管理に十分であるため、役割ベースのアクセス制御(RBAC)を Kubernetes 自体の中で構成する必要はありません。

ただし、クラスタをチーム間で共有する必要がある場合は、クラスタの親 GCP プロジェクトも複数のチームにまたがっている必要があります。この場合は、Cloud IAM で定義される役割では Google Kubernetes Engine のアクセスを管理するには限定性が不足する可能性があり、追加の(名前空間レベルの)RBAC 構成を Kubernetes 自体の中で管理することが必要になります。RBAC 構成を 2 つの場所(Cloud IAM と Kubernetes)で管理するという方法では管理上の複雑さが増すので、すべてのアクセス制御を Cloud IAM で管理できるようにクラスタのスコープを選択することをおすすめします。

メンテナンス

Google Kubernetes Engine はフルマネージド サービスですが、以下のようなメンテナンス作業を検討する必要があります。

  • Kubernetes バージョンの選択
  • アップグレード モデル(手動またはスケジュール)とメンテナンスの時間枠の選択
  • アップグレードの開始
  • ノードプール設定の変更

これらのすべての作業は、クラスタで実行されているワークロードに影響を与える可能性があります。クラスタが多くのチームで共有されている場合、チームがこれらの作業を実行するタイミングについて合意するのは難しいことがあります。スケジューリングの問題を回避するには、クラスタのメンテナンス作業に関与するチームの数を制限します。

ネットワーキング

1 つの Google Kubernetes Engine クラスタは、使用するノードプールの数にかかわらず、単一の Virtual Private Cloud(VPC)とサブネットに属します。接続の要件が理由でワークロードを複数の VPC またはサブネットで実行する必要がある場合は、VPC またはサブネットごとに少なくとも 1 つとなるようにクラスタを分けて作成する必要があります。

モニタリングとロギング

モニタリングとロギングの構成は Google Kubernetes Engine クラスタの中でグローバルであるため、複数のワークロードを単一のクラスタ上で実行するには、これらのワークロードのロギングとモニタリングの要件が一致している必要があります。

課金

GCP の料金計算はプロジェクト単位で行われます。複数のワークロードが単一のクラスタを共有している、つまり単一の GCP プロジェクトに属している場合に、各ワークロードが全体のコストに占める割合を判断することは困難です。ワークロード単位の料金計算が必要な場合は、専用の Google Kubernetes Engine クラスタと GCP プロジェクトを使用してください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...