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