GKE on Bare Metal は、異なる可用性、分離、リソースのフットプリントのニーズに合わせて複数のデプロイモデルをサポートします。このページでは、すべてのデプロイモデルに共通するコンセプトを定義し、各デプロイモデルについて説明します。
ユーザー クラスタ
ユーザー クラスタは、コンテナ化されたワークロードを実行する Kubernetes クラスタです。 これは、コントロール プレーン ノードとワーカーノードで構成されます。GKE on Bare Metal は、1 つ以上のユーザー クラスタをサポートします。ユーザー クラスタには、ユーザー ワークロードを実行する 1 つ以上のワーカーノードを含める必要があります。
管理クラスタ
管理クラスタは、1 つ以上のユーザー クラスタを管理する Kubernetes クラスタです。管理クラスタでは、次のタスクを実行できます。
- ユーザー クラスタの作成
- ユーザー クラスタのアップグレード
- ユーザー クラスタの更新
- ユーザー クラスタの削除
ユーザー クラスタを作成するために、管理クラスタはユーザー クラスタのコントロール プレーンとワーカーノードにベアメタル版 Anthos のコンポーネントを設定します。GKE on Bare Metal のコンポーネントがコントロール プレーン ノードで実行されるため、管理クラスタにはコントロール プレーン ノードのみが存在します。
管理クラスタには、次の種類のセンシティブ データが含まれます。
- SSH 認証情報: リモート インストールを有効にするために使用します
- Google Cloud サービス アカウント キー: Container Registry などの機能にアクセスするために使用します。
機密データを保護するため、管理クラスタへのアクセスを制限してください。
高可用性
管理クラスタとユーザー クラスタは、高可用性（HA）モードで実行できます。このモードには、クラスタで実行される 3 つ以上（奇数）のコントロール プレーン ノードが必要です。クラスタを非 HA モードで実行する場合、クラスタに必要なコントロール プレーン ノードは 1 つのみです。
単一障害点の発生を回避するには、本番環境デプロイで HA モードを使用します。テスト環境など、ミッション クリティカルではない環境に対しては非 HA モードを使用します。単一のコントロール プレーン ノードで障害が発生したらクラスタを再作成できます。HA ユーザー クラスタには、ワーカーノードで障害が発生した場合に備えて 2 つ以上のワーカーノードが必要です。
クラスタをアップグレードする場合、HA デプロイにより、エラー発生時にクラスタにアクセスできなくなるリスクが軽減されます。
デプロイモデル
GKE on Bare Metal は、さまざまな要件に対応できるよう次のデプロイモデルをサポートしています。
管理クラスタとユーザー クラスタのデプロイ
1 つのデータセンター内にある多数のクラスタを一元化された場所から管理する場合や、デプロイが大規模で、チーム間の分離、開発と本番環境でのワークロードの分離が必要な場合には、このデプロイモデルを使用してください。
このデプロイモデルは、次のクラスタで構成されています。
- 1 つの管理クラスタ: ユーザー クラスタを管理するための API を備えた一元管理ポイント。管理クラスタは管理コンポーネントのみを実行します。
- 1 つ以上のユーザー クラスタ: ユーザー ワークロードを実行するコントロール プレーン ノードとワーカーノードが含まれます。
このモデルは次の要件を満たします。
- 一元管理されたコントロール プレーンと API でユーザー クラスタのライフサイクルを管理できます。
- チーム間の分離が可能です。
- 開発と本番環境でワークロードを分離できます。
- SSH 認証情報とサービス アカウント キーをクラスタのオーナーと共有する必要はありません。
- デプロイを独自のコントロール プレーンと統合できます。
フットプリント
管理クラスタとユーザー クラスタのデプロイには、次のノードが必要です。
管理クラスタ
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ユーザー クラスタ - ユーザー クラスタごとに個別に HA を構成できます。
コントロール プレーン ノード:
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ワーカーノード:
- 非 HA 用ワーカーノード 1 つ以上
- HA 用ワーカーノード 2 つ以上
ハイブリッド クラスタ デプロイ
このデプロイモデルは、カスタマイズされた一種のマルチクラスタ デプロイです。ハイブリッド クラスタは、ユーザー ワークロードを実行できる管理クラスタです。ハイブリッド クラスタは引き続きその他のユーザー クラスタを管理します。
このモデルの特徴:
- 管理クラスタは比較的少ないリソースを使用するため、管理クラスタに一連のマシンを割り当てると、多くの場合に無駄が発生します。ハイブリッド クラスタのデプロイでは、管理クラスタ内でユーザー ワークロードを実行できるため、そのマシンの未使用の容量を再利用できます。
- 管理クラスタには、SSH 認証情報（管理クラスタがリモートマシンのユーザー クラスタを管理するために使用する）や GCP サービス アカウント キー（管理クラスタが 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 認証情報で個別に管理されている。
- クラスタが非武装地帯（DMZ）などのネットワーク隔離パーティションで実行されている。
- クラスタがエッジ ロケーションで実行されている。
フットプリント
スタンドアロン クラスタのデプロイには、次のノードが必要です。
コントロール プレーン ノード:
- 非 HA 用コントロール プレーン ノード 1 つ
- HA 用コントロール プレーン ノード 3 つ以上
ワーカーノード:
- 非 HA 用ワーカーノード 1 つ以上
- HA 用ワーカーノード 2 つ以上