Google Distributed Cloud は、異なる可用性、分離、リソースのフットプリントのニーズに合わせて複数のデプロイモデルをサポートします。このページでは、すべてのデプロイモデルに共通するコンセプトを定義し、各デプロイモデルについて説明します。
このページは、主要なステークホルダーと連携して、会社の戦略に沿った IT ソリューションとシステム アーキテクチャを定義する管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
ユーザー クラスタ
ユーザー クラスタは、コンテナ化されたワークロードを実行する Kubernetes クラスタです。これは、コントロール プレーン ノードとワーカーノードで構成されます。Google Distributed Cloud は、1 つ以上のユーザー クラスタをサポートします。ユーザー クラスタには、ユーザー ワークロードを実行する 1 つ以上のワーカーノードを含める必要があります。
管理クラスタ
管理クラスタは、1 つ以上のユーザー クラスタを管理する Kubernetes クラスタです。管理クラスタでは、次のタスクを実行できます。
- ユーザー クラスタの作成
- ユーザー クラスタのアップグレード
- ユーザー クラスタの更新
- ユーザー クラスタの削除
ユーザー クラスタを作成するために、管理クラスタはユーザー クラスタのコントロール プレーンとワーカーノードに Google Distributed Cloud コンポーネントを設定します。Google Distributed Cloud コンポーネントがコントロール プレーン ノードで実行されるため、管理クラスタにはコントロール プレーン ノードのみが存在します。
管理クラスタには、次の種類のセンシティブ データが含まれます。
- SSH 認証情報: リモート インストールを有効にするために使用します
- Google Cloud サービス アカウント キー: Container Registry などの機能にアクセスするために使用します。
機密データを保護するため、管理クラスタへのアクセスを制限してください。
高可用性
管理クラスタとユーザー クラスタは、高可用性（HA）モードで実行できます。このモードには、クラスタで実行される 3 つ以上（奇数）のコントロール プレーン ノードが必要です。クラスタを非 HA モードで実行する場合、クラスタに必要なコントロール プレーン ノードは 1 つのみです。
単一障害点の発生を回避するには、本番環境デプロイで HA モードを使用します。テスト環境など、ミッション クリティカルではない環境に対しては非 HA モードを使用します。単一のコントロール プレーン ノードで障害が発生したらクラスタを再作成できます。HA ユーザー クラスタには、ワーカーノードで障害が発生した場合に備えて 2 つ以上のワーカーノードが必要です。
クラスタをアップグレードする場合、HA デプロイにより、エラー発生時にクラスタにアクセスできなくなるリスクが軽減されます。
デプロイモデル
Google Distributed Cloud は、さまざまな要件に対応できるよう次のデプロイモデルをサポートしています。
管理クラスタとユーザー クラスタのデプロイ
1 つのデータセンター内にある多数のクラスタを一元化された場所から管理する場合や、デプロイが大規模で、チーム間の分離、開発と本番環境でのワークロードの分離が必要な場合には、このデプロイモデルを使用してください。
このデプロイモデルは、次のクラスタで構成されています。
- 1 つの管理クラスタ: ユーザー クラスタを管理するための API を備えた一元管理ポイント。管理クラスタは管理コンポーネントのみを実行します。
- 1 つ以上のユーザー クラスタ: ユーザー ワークロードを実行するコントロール プレーン ノードとワーカーノードが含まれます。
このモデルは次の要件を満たします。
- 一元管理されたコントロール プレーンと API でユーザー クラスタのライフサイクルを管理できます。
- チーム間の分離が可能です。
- 開発と本番環境でワークロードを分離できます。
- SSH 認証情報とサービス アカウント キーをクラスタのオーナーと共有する必要はありません。
- デプロイを独自のコントロール プレーンと統合できます。
フットプリント
管理クラスタとユーザー クラスタのデプロイには、次のノードが必要です。
管理クラスタ
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ユーザー クラスタ - ユーザー クラスタごとに個別に HA を構成できます。
コントロール プレーン ノード:
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ワーカーノード:
- 非 HA 用ワーカーノード 1 つ以上
- HA 用ワーカーノード 2 つ以上
ハイブリッド クラスタ デプロイ
このデプロイモデルは、カスタマイズされた一種のマルチクラスタ デプロイです。ハイブリッド クラスタは、ユーザー ワークロードを実行できる管理クラスタです。ハイブリッド クラスタは引き続きその他のユーザー クラスタを管理します。
このモデルの特徴:
- 管理クラスタは比較的少ないリソースを使用するため、管理クラスタにマシンセットを割り当てると、多くの場合、無駄になります。ハイブリッド クラスタのデプロイでは、管理クラスタ内でユーザー ワークロードを実行できるため、そのマシンの未使用の容量を再利用できます。
- 管理クラスタには、SSH 認証情報（管理クラスタがリモートマシンのユーザー クラスタを管理するために使用する）や Google Cloud サービス アカウント キー（管理クラスタが Cloud Storage などの Google Cloud サービスにアクセスするために使用する）などの機密データが含まれます。ハイブリッド クラスタのデプロイメントでは、管理クラスタ内でユーザー ワークロードが実行され、管理クラスタの機密データがユーザー ワークロードに公開される可能性があります。
フットプリント
ハイブリッド クラスタのデプロイには、次のノードが必要です。
ハイブリッド クラスタ
コントロール プレーン ノード:
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ワーカーノード:
- 非 HA 用ワーカーノード 1 つ以上
- HA 用ワーカーノード 2 つ以上（ワークロードのタイプによって異なる）
ユーザー クラスタ - ユーザー クラスタごとに個別に HA を構成できます。
コントロール プレーン ノード:
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ワーカーノード:
- 非 HA 用ワーカーノード 1 つ以上
- HA 用ワーカーノード 2 つ以上
スタンドアロン クラスタ デプロイ
このデプロイモデルには、ユーザー クラスタと管理クラスタとして機能する単一のクラスタがあります。
このモデルには次のような利点があります。
- 個別の管理クラスタは必要ありません
- Edge プロファイルをサポートしています。これは、システム リソースの要件を大幅に削減します。リソースの制約が大きいエッジデバイスにおすすめです。
ワークロードは、次の機密データを含むクラスタで実行されるため、このモデルにはセキュリティ上のトレードオフがあります。
- SSH 認証情報
- Google Cloud サービス アカウント キー
次のいずれかの条件を満たす場合は、このモデルを使用してください。
- すべてのクラスタを別々に管理している。
- ワーカーノードの数が少ない。
- 1 つのチームをサポートしている。
- 単一のワークロード タイプを実行している。
このモデルは次のような条件に適しています。
- 各クラスタが、それぞれ異なる SSH 認証鍵と Google Cloud 認証情報で個別に管理されている。
- クラスタが、信頼できないネットワークから分離されたネットワーク分離パーティションで実行されている。
- クラスタがエッジ ロケーションで実行されている。
フットプリント
スタンドアロン クラスタのデプロイには、次のノードが必要です。
コントロール プレーン ノード:
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ワーカーノード:
- 非 HA 用ワーカーノード 1 つ以上
- HA 用ワーカーノード 2 つ以上
エッジ プロファイル
スタンドアロン クラスタはエッジ プロファイルをサポートしており、クラスタのリソース消費を最小限に抑えます。スタンドアロン クラスタを作成するときに、クラスタ構成ファイルで profile を edge に設定して、エッジ プロファイルを有効にします。エッジ プロファイルは、リソースの制約が厳しいエッジデバイスにおすすめです。エッジ プロファイルに関連するハードウェア要件については、エッジ プロファイルを使用するスタンドアロン クラスタのリソース要件をご覧ください。
エッジ プロファイルを使用するように構成されたスタンドアロン クラスタでは、コントロール プレーン ノードはユーザー ワークロードを受け入れるように自動的に構成されます。つまり、ワーカー ノードプールは必要ありません。ただし、コントロール プレーンでワークロードを実行してフットプリントを削減すると、コントロール プレーンとデータプレーンの間のセキュリティとリソースの分離が弱まります。フットプリントの削減がこのトレードオフに値する場合は、高可用性のために単一のコントロール プレーン ノードまたは複数のコントロール プレーン ノードで実行するように、エッジ プロファイルを使用してスタンドアロン クラスタを構成できます。