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