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