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