このドキュメントでは、Google Distributed Cloud（GDC）エアギャップでのワークロード管理の概要について説明します。この記事のトピックは次のとおりです。
ワークロードのデプロイ設計の一部は推奨されていますが、推奨されているとおりに正確に実行する必要はありません。各 GDC ユニバースには、個別に満たす必要のある独自の要件と考慮事項があります。
ワークロードのデプロイ先
GDC プラットフォームでは、仮想マシン（VM）ワークロードとコンテナ ワークロードをデプロイするオペレーションが異なります。このセクションでは、違いと各リソースのデプロイ場所について説明します。
VM ベースのワークロード
VM ベースのワークロードをホストする VM を作成できます。VM ベースのワークロードの要件を最大限に満たすために、VM の形状とサイズには多くの構成オプションがあります。プロジェクトに VM を作成する必要があります。プロジェクトには、多数の VM と VM ワークロードを含めることができます。詳細については、VM の概要をご覧ください。
VM ベースのワークロードのみを含むプロジェクトには、Kubernetes クラスタは必要ありません。そのため、VM ベースのワークロード用に Kubernetes クラスタをプロビジョニングする必要はありません。
コンテナベースのワークロード
コンテナベースのワークロードを Kubernetes クラスタの Pod にデプロイできます。Kubernetes クラスタは 1 つまたは複数のプロジェクトに接続できますが、プロジェクトの子リソースではありません。クラスタは、適切なデプロイ環境のプロジェクトにのみ関連付けることをおすすめします。たとえば、本番環境ワークロードのクラスタは、本番環境ワークロードのプロジェクトに接続されます。
Kubernetes クラスタ内の Pod スケジューリングの場合、GDC はスケジューリング、プリエンプション、退避という Kubernetes の一般的なコンセプトを採用しています。クラスタ内の Pod のスケジューリングに関するベスト プラクティスは、ワークロードの要件によって異なります。
Kubernetes クラスタの詳細については、Kubernetes クラスタの概要をご覧ください。Kubernetes クラスタでコンテナを管理する方法については、コンテナ ワークロードの概要をご覧ください。
Kubernetes クラスタの設計に関するベスト プラクティス
このセクションでは、Kubernetes クラスタを設計するためのベスト プラクティスについて説明します。
デプロイ環境ごとに個別のクラスタを作成する
デプロイ環境ごとに個別のプロジェクトに加えて、デプロイ環境ごとに個別の Kubernetes クラスタを設計することをおすすめします。環境ごとに Kubernetes クラスタとプロジェクトを分離することで、本番環境と非本番環境のワークロード間で、リソース使用量、アクセス ポリシー、メンテナンス イベント、クラスタレベルの構成変更を分離できます。
次の図は、プロジェクト、クラスタ、デプロイ環境、マシンクラスにまたがる複数のワークロードの Kubernetes クラスタ設計の例を示しています。
このサンプル アーキテクチャでは、デプロイ環境内のワークロードがクラスタを共有できることを前提としています。各デプロイ環境には、個別の Kubernetes クラスタのセットがあります。次に、適切なデプロイ環境の Kubernetes クラスタにプロジェクトを割り当てます。Kubernetes クラスタは、異なるマシンクラスの要件に合わせて複数のノードプールにさらに細分化されることがあります。
また、複数の Kubernetes クラスタを設計すると、次のようなコンテナ オペレーションに役立ちます。
- 特定の Kubernetes バージョンに固定されたワークロードがあるため、異なるバージョンの異なるクラスタを維持します。
- バックアップ ポリシーなど、異なるクラスタ構成が必要なワークロードがあるため、異なる構成で複数のクラスタを作成します。
- クラスタのコピーを並行して実行して、中断を伴うバージョン アップグレードや Blue/Green デプロイ戦略を容易にします。
- API サーバーやクラスタ内の他の単一障害点をスロットリングするリスクのある試験運用ワークロードを構築するため、既存のワークロードから分離します。
次の図は、前のセクションで説明したコンテナ オペレーションなどの要件により、デプロイ環境ごとに複数のクラスタが構成されている例を示しています。
作成するクラスタの数を減らす
リソースを効率的に使用するには、デプロイ環境とコンテナ オペレーションの分離に関する要件を満たす最小数の Kubernetes クラスタを設計することをおすすめします。クラスタを追加するたびに、追加のコントロール プレーン ノードなど、追加のオーバーヘッド リソース消費が発生します。そのため、ワークロードが多い大規模なクラスタでは、多数の小規模なクラスタよりも基盤となるコンピューティング リソースを効率的に利用できます。
構成が類似したクラスタが複数ある場合、クラスタ容量のモニタリングとクラスタ間の依存関係の計画にメンテナンスのオーバーヘッドが発生します。
クラスタの容量が不足しそうな場合は、新しいクラスタを作成するのではなく、クラスタにノードを追加することをおすすめします。
クラスタ内のノードプールを減らす
リソースを効率的に使用するには、Kubernetes クラスタ内に少数の大きなノードプールを設計することをおすすめします。
複数のノードプールを構成すると、他の Pod とは異なるマシンクラスを必要とする Pod をスケジュールする必要がある場合に便利です。ワークロードに必要なマシンクラスごとにノードプールを作成し、ノード容量を自動スケーリングに設定して、コンピューティング リソースを効率的に使用できるようにします。