このガイドでは、GDCV for Bare Metal のデプロイに使用するリファレンス アーキテクチャについて説明します。このガイドは、可用性の高い地理的冗長構成でベアメタル プラットフォームに GKE Enterprise をデプロイするプラットフォーム管理者を対象としています。このガイドを適切に理解するには、GKE Enterprise の技術概要で説明されている GKE Enterprise の基本的なコンセプトを理解している必要があります。また、Kubernetes の基礎を学習すると GKE のドキュメントで説明されている Kubernetes のコンセプトと Google Kubernetes Engine（GKE）に関する基本的な知識も必要です。
このガイドには、前述のアーキテクチャのデプロイに使用できるスクリプトを含む GitHub ソース リポジトリが含まれています。また、このガイドでは、それらのコンポーネントの作成に使用されるスクリプトとモジュールに付属するアーキテクチャ コンポーネントについても説明します。これらのファイルをテンプレートとして使用し、組織のベスト プラクティスとポリシーを使用するモジュールを作成することをおすすめします。
GDCV for Bare Metal のアーキテクチャ モデル
GKE Enterprise アーキテクチャ基盤ガイドでは、プラットフォーム アーキテクチャがレイヤで説明されています。各レイヤのリソースには、特定の関数セットが用意されています。これらのリソースは、1 つ以上のペルソナによって所有、管理されます。次の図に示すように、ベアメタル用の GKE Enterprise プラットフォーム アーキテクチャは、次のレイヤとリソースで構成されています。
- インフラストラクチャ: このレイヤには、ストレージ、コンピューティング、ネットワークが含まれ、オンプレミスの構成体で扱われます。
- データ管理: このガイドの目的では、データ管理レイヤには、デプロイされる Kubernetes クラスタの外部で管理される SQL データベースが必要です。
- コンテナ管理レイヤ: このレイヤでは GKE クラスタを使用します。
- サービス管理レイヤ: このレイヤでは、Anthos Service Mesh を使用します。
- ポリシー管理レイヤ: このレイヤでは、Config Sync と Policy Controller を使用します。
- アプリケーション管理レイヤ: このレイヤでは、Cloud Build と Cloud Source Repositories を使用します。
- オブザーバビリティ レイヤ: このレイヤでは、Google Cloud Observability と Anthos Service Mesh ダッシュボードを使用します。
これらの各レイヤは、開発、ステージング、本番環境など、さまざまなライフサイクル環境でスタック全体にわたり繰り返されます。
以降のセクションでは、GDCV for Bare Metal に固有の追加情報のみ説明します。これらは、GKE Enterprise アーキテクチャ基盤ガイドのそれぞれのセクションに基づいています。この記事を読みながら、同ガイドを確認することをおすすめします。
ネットワーキング
ネットワーク要件の詳細については、ネットワークの要件をご覧ください。
GDCV for Bare Metal ロードバランサには、バンドルと手動の 2 つのオプションがあります。
バンドルモードでは、クラスタの作成時に L4 ロード バランシング ソフトウェアがデプロイされます。ロードバランサ プロセスは、ワーカーノードの専用プールまたはコントロール プレーンと同じノードで実行できます。仮想 IP アドレス（VIP）をアドバタイズするために、このロードバランサには次の 2 つのオプションがあります。
- アドレス解決プロトコル（ARP）: ロードバランサを実行するノード間のレイヤ 2 接続が必要です。
- Border Gateway Protocol（BGP）: ピアリングを使用して、クラスタ ネットワーク（自律システム）を外部ネットワークなどの別の自律システムに接続します。
手動モードでは、コントロール プレーンとデータプレーンのトラフィック用に独自のロード バランシング ソリューションを構成します。外部ロードバランサで使用できるハードウェアとソフトウェアのオプションは多数あります。ベアメタル クラスタを作成する前に、コントロール プレーン用に外部ロードバランサを設定する必要があります。コントロール プレーンの外部ロードバランサはデータプレーンのトラフィックにも使用できます。また、データプレーン用に別のロードバランサを設定することもできます。可用性を確認するには、構成可能な準備状況チェックに基づいて、ロードバランサがノードプールにトラフィックを分散できなければなりません。
GDCV for Bare Metal のロードバランサの詳細については、ロードバランサの概要をご覧ください。
クラスタのアーキテクチャ
GDCV for Bare Metal は、さまざまな可用性、分離、リソース フットプリントのニーズに合わせて複数のデプロイモデルをサポートします。これらのデプロイモデルについては、デプロイモードの選択をご覧ください。
ID 管理
GDCV for Bare Metal は、GKE Identity Service を使用して ID プロバイダと統合します。OpenID Connect（OIDC）と Lightweight Directory Access Protocol（LDAP）をサポートしています。アプリケーションとサービスで、Anthos Service Mesh をさまざまな ID ソリューションで使用できます。
ID 管理の詳細については、GDCV for Bare Metal での OIDC による ID 管理と OIDC による認証または LDAP で Anthos Identity Service を設定するをご覧ください。
セキュリティとポリシーの管理
GDCV for Bare Metal のセキュリティとポリシー管理には、Config Sync と Policy Controller を使用することをおすすめします。Policy Controller を使用すると、クラスタ全体にポリシーを作成して適用できます。Config Sync は、変更を評価してすべてのクラスタにそれを適用し、適切な状態を実現します。
Service
ロード バランシングに GDCV for Bare Metal のバンドルモードを使用すると、LoadBalancer タイプの Serivice を作成できます。これらの Service を作成すると、GDCV for Bare Metal では、構成したロードバランサの IP アドレスプールから IP アドレスを Service に割り当てます。LoadBalancer Service タイプは、North-South トラフィック用のクラスタ外に Kubernetes Service を公開するために使用されます。GDCV for Bare Metal を使用する場合は、デフォルトでクラスタに IngressGateway も作成されます。手動モードでは、GDCV for Bare Metal 用の LoadBalancer タイプの Service を作成できません。代わりに、IngressGateway を使用する Ingress オブジェクトを作成するか、NodePort タイプの Service を作成して、Kubernetes Service をバックエンドとして使用するように外部ロードバランサを手動で構成します。
Service Management（East-West トラフィックとも呼ばれます）については、Anthos Service Mesh を使用することをおすすめします。Anthos Service Mesh は Istio オープン API を基盤としており、均一なオブザーバビリティ、認証、暗号化、きめ細かいトラフィック制御、その他の特徴と機能を提供します。Service Management の詳細については、Anthos Service Mesh をご覧ください。
永続性と状態の管理
GDCV for Bare Metal は、エフェメラル ストレージ、ボリューム ストレージ、PersistentVolume ストレージについて、既存のインフラストラクチャに大きく依存しています。エフェメラル データは、Kubernetes Pod がスケジュールされているノード上のローカル ディスク リソースを使用します。永続データの場合、GKE Enterprise は Container Storage Interface（CSI）と互換性があります。CSI は、多くのストレージ ベンダーがサポートするオープン標準 API です。本番環境のストレージについては、GKE Enterprise Ready ストレージ パートナーから CSI ドライバをインストールすることをおすすめします。GKE Enterprise Ready ストレージ パートナーの全一覧については、GKE Enterprise Ready ストレージ パートナーをご覧ください。
ストレージの詳細については、ストレージの構成をご覧ください。
データベース
GDCV for Bare Metal では、GKE Enterprise プラットフォームの標準機能以外に追加のデータベース固有の機能はありません。ほとんどのデータベースは、外部のデータ管理システムで実行されます。GKE Enterprise プラットフォームのワークロードは、アクセス可能な外部データベースに接続するように構成することもできます。
オブザーバビリティ
Google Cloud Observability は、GKE クラスタの収集とモニタリングのポリシーと同様の方法で、GDCV for Bare Metal クラスタのログとモニタリング指標を収集します。デフォルトでは、クラスタログとシステム コンポーネントの指標が Cloud Monitoring に送信されます。Google Cloud Observability でアプリケーションのログと指標を収集するには、クラスタ構成の YAML ファイルで clusterOperations.enableApplication オプションを有効にします。
オブザーバビリティの詳細については、ロギングとモニタリングの構成をご覧ください。
ユースケース: Cymbal Bank のデプロイ
このガイドでは、GDCV for Bare Metal の計画、プラットフォーム デプロイ、アプリケーション デプロイのプロセスをシミュレートするために Cymbal Bank/Bank of Anthos アプリケーションを使用します。
このドキュメントの残りの部分は、3 つのセクションから構成されます。計画セクションでは、アーキテクチャ モデルのセクションで説明した選択肢に基づいて行われた決定の概要を説明します。プラットフォームのデプロイ セクションでは、GKE Enterprise プラットフォームをデプロイするためにソース リポジトリに用意されたスクリプトとモジュールについて説明します。最後に、アプリケーションのデプロイ セクションでは、Cymbal Bank アプリケーションをプラットフォームにデプロイします。
この GDCV for Bare Metal ガイドは、セルフマネージド ホストや Compute Engine インスタンスにデプロイするために使用できます。Google Cloud リソースを使用すると、物理的なハードウェアにアクセスすることなく、このガイドをやり終えることが可能です。Compute Engine インスタンスの使用は、デモのみを目的としたものです。本番環境のワークロードにこれらのインスタンスは使用しないでください。物理ハードウェアにアクセスでき、同じ IP アドレス範囲が使用されている場合は、用意されたソース リポジトリをそのまま使用できます。環境が計画セクションで説明する内容と異なる場合は、スクリプトとモジュールを違いに対応するように変更できます。関連するソース リポジトリは、物理ハードウェアと Compute Engine インスタンスの両方のシナリオを含んでいます。
計画
次のセクションでは、GDCV for Bare Metal に Bank of GKE Enterprise アプリケーションをデプロイするためのプラットフォームを計画、設計する際に行ったアーキテクチャ上の決定事項について詳しく説明します。このセクションでは、本番環境に焦点を当てています。開発やステージングなどの下位環境をビルドする場合、同様の手順を使用できます。
Google Cloud プロジェクト
Google Cloud で GDCV for Bare Metal のプロジェクトを作成するときは、フリート ホスト プロジェクトが必要です。環境やビジネス機能ごとに追加のプロジェクトを用意することをおすすめします。このプロジェクト構成により、リソースを操作するペルソナに基づいてリソースを整理できます。
以下のサブセクションでは、推奨されるプロジェクト タイプと、それらのプロジェクトに関連付けられたペルソナについて説明します。
ハブ プロジェクト
ハブ プロジェクト hub-prod はネットワーク管理者ペルソナ用です。このプロジェクトでは、選択したハイブリッド接続を使用して、オンプレミス データセンターを Google Cloud に接続します。ハイブリッド接続オプションの詳細については、Google Cloud の接続をご覧ください。
フリート ホスト プロジェクト
フリート ホスト プロジェクト fleet-prod はプラットフォーム管理者ペルソナ用です。プロジェクトとは、GDCV for Bare Metal クラスタが登録されている場所のことです。このプロジェクトには、プラットフォーム関連の Google Cloud リソースも存在しています。これらのリソースには、Google Cloud Observability や Cloud Source Repositories などが含まれます。1 つの Google Cloud プロジェクトに関連付けられるのは、1 つのフリート（またはフリートなし）だけです。この制限により、Google Cloud プロジェクトを使用して、制御されていないリソースや一緒に使用されないリソースの分離を強化します。
アプリケーション プロジェクトまたはチーム プロジェクト
アプリケーションまたはチーム プロジェクト app-banking-prod は、デベロッパー ペルソナ用です。このプロジェクトには、アプリケーション固有またはチーム固有の Google Cloud リソースがあります。このプロジェクトには、GKE クラスタを除くすべてのものが含まれます。チームまたはアプリケーションの数によっては、このプロジェクト タイプのインスタンスが複数存在する場合があります。チームごとに別々のプロジェクトを作成すると、チームごとに IAM、課金、割り当てを個別に管理できます。
ネットワーキング
各 GDCV for Bare Metal クラスタには、次の IP アドレス サブネットが必要です。
- ノード IP アドレス
- Kubernetes Pod IP アドレス
- Kubernetes Service / クラスタの IP アドレス
- ロードバランサの IP アドレス（一括モード）
各クラスタ内の Kubernetes Pod とサービス サブネットにルーティングできない同じ IP アドレス範囲を使用するには、アイランド モードのネットワーク モデルを選択します。この構成では、Pod はクラスタ内で相互に直接通信できますが、クラスタの外部から（Pod の IP アドレスを使用して）Pod に直接アクセスすることはできません。この構成により、外部ネットワークに接続されていないネットワーク内に「アイランド」が形成されます。クラスタはアイランド内のクラスタノード全体に完全なノード間メッシュを形成し、Pod がクラスタ内の他の Pod に直接アクセスできるようにします。
IP アドレスの割り振り
| クラスタ | ノード | Pod | Service | ロードバランサ |
|---|---|---|---|---|
| metal-admin-dc1-000-prod | 10.185.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | なし |
| metal-user-dc1a-000-prod | 10.185.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.1.3-10.185.1.10 |
| metal-user-dc1b-000-prod | 10.185.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.2.3-10.185.2.10 |
| metal-admin-dc2-000-prod | 10.195.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | なし |
| metal-user-dc2a-000-prod | 10.195.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.1.3-10.195.1.10 |
| metal-user-dc2b-000-prod | 10.195.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.2.3-10.195.2.10 |
アイランド モードでは、Kubernetes Pod とサービス用に選択された IP アドレス サブネットがノード ネットワークから使用されていないか、ルーティング可能でないことを確認することが重要です。
ネットワークの要件
構成が不要な GDCV for Bare Metal 用に統合ロードバランサを提供するには、各クラスタで一括ロードバランサ モードを使用します。ワークロードで LoadBalancer Service が実行されている場合、ロードバランサ プールから IP アドレスが割り当てられます。
バンドル ロードバランサの要件と構成の詳細については、ロードバランサの概要とバンドル ロード バランシングの構成をご覧ください。
クラスタのアーキテクチャ
本番環境では、管理クラスタとユーザー クラスタのデプロイモデルを使用して、各地理的場所に 1 つの管理クラスタと 2 つのユーザー クラスタを配置し、GDCV for Bare Metal の最大限の冗長性とフォールト トレラントを実現することをおすすめします。
本番環境ごとに少なくとも 4 つのユーザー クラスタを使用することをおすすめします。2 つのフォールト トレラント クラスタをそれぞれ含む、地理的に冗長な 2 つのロケーションを使用します。各フォールト トレラント クラスタには、冗長なハードウェアと冗長ネットワーク接続があります。クラスタの数を減らすと、アーキテクチャの冗長性やフォールト トレラントが低くなります。
高可用性を確保するため、各クラスタのコントロール プレーンでは 3 つのノードを使用します。ユーザー クラスタごとに少なくとも 3 つのワーカーノードを使用することにより、それらのノード間でワークロードを分散して、ノードがオフラインになった場合の影響を軽減できます。ワーカーノードの数とサイズは、クラスタ内で実行されるワークロードのタイプと数に大きく依存します。各ノードの推奨サイズについては、GDCV for Bare Metal 用のハードウェアの構成をご覧ください。
次の表は、このユースケースでの CPU コア、メモリ、ローカル ディスク ストレージの推奨ノードサイズを示しています。
| ノードタイプ | CPU / vCPU | メモリ | ストレージ |
|---|---|---|---|
| コントロール プレーン | 8 コア | 32 GiB | 256 GiB |
| ワーカー | 8 コア | 64 GiB | 512 GiB |
マシンの前提条件とサイズ設定の詳細については、クラスタノード マシンの前提条件をご覧ください。
ID 管理
ID 管理については、GKE Identity Service を介して OIDC と統合することをおすすめします。ソース リポジトリに示されている例では、要件を簡素化するためにローカル認証が使用されています。OIDC が使用できる場合は、それを使用するように例を変更できます。詳細については、GDCV for Bare Metal での OIDC による ID 管理をご覧ください。
セキュリティとポリシーの管理
Cymbal Bank のユースケースでは、ポリシー管理に Config Sync と Policy Controller が使用されます。Config Sync が使用する構成データを保存するために、Cloud Source Repositories が作成されます。Config Sync と Policy Controller のインストールと管理には、ConfigManagement Operator が使用されます。この Operator には構成ソース リポジトリへの読み取り専用アクセス権が必要です。この権限を付与するには、受け入れ可能な認証方法を使用します。この例では、Google サービス アカウントを使用します。
Service
このユースケースの Service Management では、分散サービスを構築するベースとするために Anthos Service Mesh が使用されます。デフォルトでは、標準の Kubernetes Ingress オブジェクトを扱う IngressGateway もクラスタ内に作成されます。
永続性と状態の管理
永続ストレージは既存のインフラストラクチャに大きく依存するため、このユースケースでは不要です。それ以外の場合は、GKE Enterprise Ready ストレージ パートナーのストレージ オプションを使用することをおすすめします。CSI ストレージ オプションを使用可能な場合は、ベンダー提供の手順でクラスタにインストールできます。概念実証と高度なユースケースでは、ローカル ボリュームを使用できます。ただし、ほとんどのユースケースでは、本番環境でローカル ボリュームを使用することはおすすめしません。
データベース
GDCV for Bare Metal のステートフル アプリケーションの多くは、データベースを永続ストアとして使用します。ステートフル データベース アプリケーションは、クライアントにビジネス ロジックを提供するためにデータベースにアクセスする必要があります。GDCV for Bare Metal で使用される Datastore のタイプに制限はありません。したがって、データ保存に関する決定は、デベロッパーまたは関連するデータ管理チームが行う必要があります。アプリケーションが異なるデータストアを必要とする場合があるため、これらのデータストアも制限なく使用できます。データベースは、クラスタ内、オンプレミス、クラウドでも管理できます。
Cymbal Bank アプリケーションは、2 つの PostgreSQL データベースにアクセスするステートフル アプリケーションです。データベース アクセスは、環境変数を使用して構成されます。データベースがクラスタから外部的に管理されている場合でも、ワークロードを実行しているノードから PostgreSQL データベースにアクセスできる必要があります。この例では、アプリケーションが既存の外部の PostgreSQL データベースにアクセスします。アプリケーションがプラットフォームで実行されている間、データベースは外部で管理されます。したがって、データベースは GKE Enterprise プラットフォームの一部ではありません。PostgreSQL データベースが利用可能な場合は、それを使用します。そうでない場合は、Cymbal Bank アプリケーション用の Cloud SQL データベースを作成して使用します。
オブザーバビリティ
Cymbal Bank のユースケースの各クラスタは、Google Cloud Observability でシステム コンポーネントとアプリケーションの両方のログと指標を収集するように構成されています。Google Cloud コンソールのインストーラによって作成された Cloud Monitoring ダッシュボードはいくつかあります。これらのダッシュボードは、モニタリング ダッシュボード ページから表示できます。オブザーバビリティの詳細については、ロギングとモニタリングの構成と、GDCV for Bare Metal のロギングとモニタリングの仕組みをご覧ください。
プラットフォームのデプロイ
詳細については、GitHub ソース リポジトリにあるドキュメントのプラットフォームをデプロイするセクションをご覧ください。
アプリケーションのデプロイ
詳細については、GitHub ソース リポジトリにあるドキュメントのアプリケーションをデプロイするセクションをご覧ください。
次のステップ
- Anthos Service Mesh、Config Sync、Policy Controller の詳細を確認する。
- その他の GKE Enterprise リファレンス アーキテクチャを確認する。
- GKE Enterprise のサンプル デプロイを使用して、Google Cloud で GKE Enterprise を試す。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。