Google Distributed Cloud ソフトウェアのみは Kubernetes をベースとしており、VMware またはベアメタル サーバーのいずれかにオンプレミスでデプロイできます。Distributed Cloud はオンプレミスで実行されますが、モニタリングや管理などの理由から、 Google Cloud に永続的に接続するように設計されています。ただし、なんらかの理由で（たとえば、技術的な問題のために） Google Cloud への接続が失われた場合、どうなるかを知っておく必要があります。このドキュメントでは、Distributed Cloud ソフトウェアのみのデプロイ（ベアメタルまたは VMware）でクラスタの接続が失われた場合の影響と、そのような場合に使用できる回避策について説明します。
この情報は、 Google Cloud からの計画外または強制的な切断に備え、その影響を把握する必要があるアーキテクトにとって有用です。ただし、Google Cloud から切断されたソフトウェアのみの Distributed Cloud デプロイを通常の動作モードとして計画的に使用することは控えてください。Google は、 Google Cloud サービスのスケーラビリティと可用性を活用できるように Distributed Cloud を設計しています。このドキュメントは、一時的な中断中に Distributed Cloud と互換性のあるさまざまな Google Cloud コンポーネントの設計とアーキテクチャに基づいています。すべてを網羅していない可能性があります。
このドキュメントは、GKE に精通していることを前提としています。そうでない場合は、まず GKE の概要を確認することをおすすめします。
ライセンスの検証と測定
Google Cloud プロジェクトで Anthos API（anthos.googleapis.com）を有効にしている場合、クラスタで実行されているメータリング コントローラがライセンス エンタイトルメントを定期的に生成して更新します。切断の許容時間は 12 時間です。また、測定と課金を管理するために接続が必要です。
次の表に、 Google Cloudからの一時的な切断時のライセンスと測定に関連する機能の動作を示します。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| ライセンスの検証 | 測定コントローラは、 Google Cloud プロジェクトで anthos.googleapis.com が有効になっている限り、ライセンス エンタイトルメント カスタム リソースを定期的に生成して更新します。 |
エンタイトルメント カスタム リソースを使用するコンポーネントは猶予期間をサポートします。猶予期間内にエンタイトルメント カスタム リソースが更新される限り、コンポーネントは引き続き機能します。 | 無制限。猶予期間が終わると、コンポーネントはエラーの記録を開始します。クラスタをアップグレードできなくなります。 | なし |
| 測定と課金 | メータリング コントローラは、クラスタの vCPU 容量を課金目的で Google Cloud Service Control API に報告します。 | クラスタ内エージェントは、切断中にクラスタに課金レコードを保持し、クラスタが Google Cloudに再接続するとレコードを取得します。 | 無制限。ただし、「プレミアム ソフトウェア」のサービス固有の規約に記載されているように、メータリング情報はコンプライアンスのために必要です。 | なし |
クラスタのライフサイクル
このセクションでは、クラスタの作成、更新、削除、サイズ変更などのシナリオと、そのようなアクティビティのステータスのモニタリングについて説明します。
ほとんどのシナリオでは、bmctl、gkectl、kubectl などの CLI ツールを使用して、一時的な切断中にオペレーションを実行できます。これらのツールを使用して、オペレーションのステータスをモニタリングすることもできます。再接続されると、Google Cloud コンソールが更新され、切断中に実行されたオペレーションの結果が表示されます。
| アクション | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| クラスタの作成 | クラスタの作成には bmctl または gkectl CLI ツールを使用します。このオペレーションでは、 Google Cloudへの接続が必要です。 |
クラスタを作成できません。 | ゼロ | なし |
| クラスタのアップグレード | クラスタのアップグレードには bmctl または gkectl CLI ツールを使用します。このオペレーションでは、 Google Cloudへの接続が必要です。 |
クラスタをアップグレードできません。 | ゼロ | なし |
| クラスタの削除 | クラスタを削除するには、bmctl または gkectl CLI ツールを使用します。このオペレーションでは、 Google Cloudへの接続は必要ありません。 |
クラスタを削除できます。 | 無制限 | - |
| クラスタのステータスの表示 | クラスタに関する情報は、コンソールの Google Kubernetes Engine クラスタのリストで確認できます。 | クラスタ情報はコンソールに表示されません。 | 無制限 | kubectl を使用してクラスタに直接クエリを実行し、必要な情報を取得します。 |
| クラスタからのノードの削除 | クラスタからノードを削除するために、 Google Cloud への接続は必要ありません。 | クラスタからノードを削除できます。 | 無制限 | - |
| クラスタへのノードの追加 | 新しいノードは、Container Registry からコンテナ イメージを pull して、正しく動作します。プリフライト チェックを実行して、 Google Cloudへの接続があることを確認します。 | 新しいノードの追加時に実行されるプリフライト チェックは、 Google Cloudへの接続があることを確認します。そのため、切断時にクラスタに新しいノードを追加することはできません。 | ゼロ | なし |
アプリケーションのライフサイクル
Google Cloud との一時的な切断は、オンプレミス クラスタで実行されているアプリケーションの管理にほとんど影響しません。影響を受けるのは Connect Gateway のみです。Container Registry、 Artifact Registry、Cloud Build、 Cloud Deploy を使用してGoogle Cloudでコンテナ イメージまたは CI/CD パイプラインを管理している場合、これらは切断時に利用できなくなります。こうしたプロダクトが切断に対応するための戦略については、このドキュメントでは扱いません。
| アクション | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| アプリケーションのデプロイ | kubectl、CI/CD ツール、または Connect Gateway を使用して、アプリケーションをローカルにデプロイします。 |
Connect Gateway を使用できません。他のすべてのデプロイ方法は、Kubernetes API に直接接続している限り機能します。 | 無制限 | Connect Gateway を使用している場合は、ローカルで kubectl の使用に切り替えます。 |
| アプリケーションの削除 | アプリケーションをローカルで削除するには、kubectl、CI/CD ツール、または Connect Gateway を使用します。 |
Connect Gateway を使用できません。他のすべてのデプロイ方法は、Kubernetes API に直接接続している限り機能します。 | 無制限 | Connect Gateway を使用している場合は、ローカルで kubectl の使用に切り替えます。 |
| アプリケーションのスケールアウト | kubectl、CI/CD ツール、または Connect Gateway を使用して、アプリケーションをローカルでスケールアウトします。 |
Connect Gateway を使用できません。他のすべてのデプロイ方法は、Kubernetes API に直接接続している限り機能します。 | 無制限 | Connect Gateway を使用している場合は、ローカルで kubectl の使用に切り替えます。 |
ロギングとモニタリング
監査可能性は、組織が規制要件とコンプライアンス ポリシーを満たすうえで役立ちます。Distributed Cloud では、アプリケーションのロギング、Kubernetes のロギング、監査ロギングで監査可能性を高めることができます。お客様の多くは、Google の Cloud Logging と Cloud Monitoring を利用しているため、オンプレミスでロギングとモニタリングのインフラストラクチャを管理する必要はありません。一方、集約のためにログをオンプレミス システムに一元化したいと考える方もいます。このようなお客様をサポートするために、Distributed Cloud は Prometheus などのサービスへの直接統合をサポートしています。このモードでは、 Google Cloudとの一時的な切断中のロギングやモニタリング機能への影響はありません。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| Cloud Logging を使用したアプリケーション ロギング | システムはログを Cloud Logging に書き込みます。 | システムはログをローカル ディスクにバッファリングします。 | ノードあたり 4.5 時間または 4 GiB ローカル バッファ。バッファがいっぱいになるか、切断が 4.5 時間続くと、最も古いエントリが削除されます。 | ローカル ロギング ソリューションを使用します。 |
| Cloud Logging を使用したシステム / Kubernetes のロギング | システムはログを Cloud Logging に書き込みます。 | システムはログをローカル ディスクにバッファリングします。 | ノードあたり 4.5 時間または 4 GiB ローカル バッファ。バッファがいっぱいになるか、切断が 4.5 時間続くと、最も古いエントリが削除されます。 | ローカル ロギング ソリューションを使用します。 |
| Cloud Audit Logs を使用した監査ロギング | システムはログを Cloud Logging に書き込みます。 | システムはログをローカル ディスクにバッファリングします。 | コントロール プレーン ノードあたり 10 GiB のローカル バッファ。バッファがいっぱいになると、システムは最も古いエントリを削除します。 | ローカル ロギング ソリューションへのログ転送を設定します。 |
| 他のプロバイダを使用したアプリケーション ロギング | Elastic、Splunk、Datadog、Loki などのさまざまなサードパーティ プロバイダを使用できます。 | 影響なし | 無制限 | - |
| 他のプロバイダを使用したシステム / Kubernetes のロギング | Elastic、Splunk、Datadog など、さまざまなサードパーティ プロバイダを使用できます。 | 影響なし | 無制限 | - |
| Cloud Monitoring に書き込まれるアプリケーションと Kubernetes の指標 | システムは Cloud Monitoring に指標を書き込みます。 | システムは指標をローカル ディスクにバッファリングします。 | システム指標の場合はノードあたり 24 時間または 6 GiB のローカル バッファ、アプリケーション指標の場合はノードあたり 1 GiB のローカル バッファ。バッファがいっぱいになるか、切断が 24 時間続くと、システムは最も古いエントリを削除します | ローカルのモニタリング ソリューションを使用する。 |
| Kubernetes とアプリケーション ワークロードからのモニタリング データへのアクセスと読み取り | すべての指標は、コンソールで、または Cloud Monitoring API を使用して取得できます。 | 切断中は、Cloud Monitoring で指標が更新されません。 | システム指標の場合はノードあたり 24 時間または 6 GiB のローカル バッファ、アプリケーション指標の場合はノードあたり 1 GiB のローカル バッファ。バッファがいっぱいになるか、切断が 24 時間続くと、システムは最も古いエントリを削除します | ローカルのモニタリング ソリューションを使用する。 |
| 指標のアラートルールとページング | Cloud Monitoring はアラートをサポートします。アラートは任意の指標で作成できます。システムはさまざまなチャネルを介してアラートを送信できます。 | 切断中は、アラートはトリガーされません。システムは、Cloud Monitoring にすでに送信されている指標データからのみアラートをトリガーします。 | ローカルのモニタリングとアラート ソリューションを使用する。 |
構成とポリシーの管理
Config Sync と Policy Controller を使用すると、すべてのクラスタの構成とポリシーを大規模に管理できます。構成とポリシーを Git リポジトリに保存すると、システムによってクラスタに自動的に同期されます。
Config Sync
Config Sync は、クラスタ内エージェントを使用して Git リポジトリに直接接続します。Google Cloud CLI または kubectl ツールを使用して、リポジトリ URL や同期パラメータの変更を管理できます。
一時的な切断中に、クラスタ内エージェントが Git リポジトリにアクセスできる場合は、同期に影響はありません。ただし、gcloud CLI またはコンソールで同期パラメータを変更した場合、切断中にクラスタに適用されません。kubectl を使用して、一時的にローカルで上書きできます。再接続すると、ローカルの変更は上書きされます。
Policy Controller
Policy Controller を使用すると、クラスタに対して完全にプログラム可能なポリシーを適用できます。これらのポリシーは「ガードレール」として機能し、定義したセキュリティ、運用、コンプライアンスの管理に違反する変更を防止します。
| アクション | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| Git リポジトリからの構成の同期 | クラスタ内エージェントは Git リポジトリに直接接続します。 Google Cloud API を使用して、リポジトリの URL または同期パラメータを変更できます。 | 構成の同期は影響を受けません。gcloud CLI またはコンソールで同期パラメータを変更しても、切断中にクラスタに適用されません。kubectl を使用して、一時的にローカルで上書きできます。再接続すると、ローカルの変更が上書きされます。 |
無制限 | Config Sync には Fleet API を使用せず、Kubernetes API を使用して構成します。 |
| Kubernetes API へのリクエストに対するポリシーの適用 | クラスタ内エージェントは、Kubernetes API との統合のために制約を適用します。ポリシーは、ローカルの Kubernetes API を使用して管理します。Policy Controller のシステム構成は、 Google CloudAPI を使用して管理します。 | ポリシーの適用は影響を受けません。ポリシーの管理には、引き続きローカルの Kubernetes API を使用します。 Google Cloud API を使用した Policy Controller システム構成の変更は、クラスタに伝播されませんが、一時的にローカルで上書きできます。再接続すると、ローカルの変更が上書きされます。 | 無制限 | Policy Controller には Fleet API を使用せず、Kubernetes API を使用して構成します。 |
| Google CloudAPI を使用した Config Sync のインストール、構成、アップグレード | Google Cloud API を使用して、クラスタ内エージェントのインストールとアップグレードを管理します。この API（または gcloud CLI、コンソール）を使用して、これらのエージェントの構成を管理することもできます。 | クラスタ内エージェントは引き続き正常に動作します。 Google Cloud API を使用してクラスタ内エージェントをインストール、アップグレード、構成することはできません。API を使用して行われた保留中のインストール、アップグレード、構成は、再接続時に続行されます。 | ゼロ | Policy Controller は、Fleet API ではなく Kubernetes API を使用して構成します。 |
| コンソールでのシステムまたは同期ステータスの表示 | クラスタ内エージェントの健全性と同期ステータスは、 Google Cloud API またはコンソールを使用して表示できます。 | Google Cloud API またはコンソールのステータス情報は古くなります。API で接続エラーが発生します。すべての情報は、ローカルの Kubernetes API を使用してクラスタごとに引き続き利用できます。 | ゼロ | nomos CLI またはローカルの Kubernetes API を使用します。 |
セキュリティ
このセクションでは、ID、認証、認可、シークレット管理などのセキュリティ機能が Google Cloudからの一時的な切断によってどのように影響を受けるかについて説明します。
アイデンティティ、認証、認可
Distributed Cloud は、Cloud Identity に直接接続してアプリケーションとユーザーのロールを管理できます。また、Connect を使用してワークロードを管理したり、OIDC を使用してエンドポイントの認証を行うこともできます。 Google Cloud から切断されると、Cloud Identity への接続が解除され、これらの機能は使用できなくなります。一時的な切断に対して復元力を高める必要のあるワークロードの場合は、 GKE Identity Service を使用して、LDAP または OIDC プロバイダ（ADFS など）と統合し、エンドユーザー認証を構成できます。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| ID プロバイダとしての Cloud Identity（Connect Gateway を使用） | ID プロバイダとして Cloud Identity を使用し、Connect Gateway を介して接続することで、Distributed Cloud リソースにアクセスできます。 | Connect Gateway には Google Cloudへの接続が必要です。切断中はクラスタに接続できません。 | ゼロ | GKE Identity Service を使用して、別の ID プロバイダと連携します。 |
| サードパーティの ID プロバイダを使用した ID と認証 | OIDC と LDAP をサポートします。最初に gcloud CLI を使用してログインします。OIDC プロバイダの場合は、コンソールを使用してログインできます。その後、クラスタの API に対して通常どおり認証を行うことができます（たとえば、kubectl を使用）。 |
ID プロバイダがユーザーとクラスタの両方にアクセスできる限り、クラスタの API に対して認証を行うことができます。コンソールからはログインできません。クラスタの OIDC や LDAP 構成はローカルでのみ更新できます。コンソールは使用できません。 | 無制限 | - |
| 承認 | Distributed Cloud は、ロールベース アクセス制御（RBAC）をサポートしています。ロールはユーザー、グループ、サービス アカウントに関連付けることができます。システムは、ID プロバイダからユーザー ID とグループを取得します。 | RBAC システムは Kubernetes クラスタのローカルにあり、 Google Cloud からの切断による影響はありません。ただし、Cloud Identity から取得した ID に依存している場合は、切断時に使用できません。 | 無制限 | - |
シークレットと鍵の管理
シークレットと鍵の管理はセキュリティ ポスチャーの重要な構成要素です。Google Cloud から切断された場合の Distributed Cloud の動作は、これらの機能で使用しているサービスによって異なります。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| Cloud Key Management Service と Secret Manager を使用したシークレットと鍵の管理 | 暗号鍵には Cloud Key Management Service を、シークレットには Secret Manager を直接使用します。 | Cloud Key Management Service と Secret Manager の両方は使用できません。 | ゼロ | 代わりにローカル システムを使用します。 |
| Hashicorp Vault と Google Cloud サービスを使用したシークレットと鍵の管理 | シークレットの格納に Cloud Storage または Cloud Spanner を使用し、鍵の管理に Cloud Key Management Service を使用するように Hashicorp Vault を構成します。 | Hashicorp Vault がオンプレミス クラスタで実行され、切断による影響も受ける場合、切断中はシークレットの格納と鍵の管理ができません。 | ゼロ | 代わりにローカル システムを使用します。 |
| Hashicorp Vault とオンプレミス サービスを使用したシークレットと鍵の管理 | シークレットの格納にオンプレミスのストレージ バックエンドを使用し、オンプレミスの鍵管理システム（ハードウェア セキュリティ モジュールなど）を使用するように Hashicorp Vault を構成します。 | Google Cloud から切断されても影響はありません。 | 無制限 | - |
ネットワーキングとネットワーク サービス
このセクションでは、オンプレミス クラスタのネットワーキングとネットワーク サービスについて説明します。これらには、Google Cloudからの一時的な切断による影響も含まれます。ロード バランシング、Cloud Service Mesh、その他のネットワーク サービスに関する情報を提供します。
ロード バランシング
オンプレミス クラスタでホストされている Kubernetes Service をユーザーに公開するには、次のオプションがあります。
ベアメタル:
VMware:
提供されているバンドル型ロードバランサ MetalLB を使用します。
これらのロード バランシング オプションは、Google Cloudから切断されても動作し続けます。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| バンドルされた L4 ロードバランサ | Google Cloud の API やネットワークに依存することなく、L4 ロード バランシングを完全にローカルで行うことができます。 | 変更なし | 無制限 | - |
| 手動または統合されたロードバランサ | F5 BIG-IP など、オンプレミスでホストされている他のロードバランサもサポートします。 | 変更なし | 無制限 | - |
Cloud Service Mesh
Cloud Service Mesh を使用すると、オンプレミス クラスタで実行されているサービス間の通信を管理、観察、保護できます。Distributed Cloud は、すべての Cloud Service Mesh 機能をサポートしていません。詳細については、サポートされている機能のリストをご覧ください。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| ポリシー（ルーティング、認可、セキュリティ、監査など）のデプロイまたは更新 | Cloud Service Mesh ポリシーは、コンソール、kubectl、asmcli、または istioctl を使用して管理できます。 |
kubectl または istioctl のみを使用して Cloud Service Mesh ポリシーを管理できます。 |
無制限 | kubectl または istioctl を使用します。 |
| 認証局（CA） | クラスタ内 CA または Cloud Service Mesh 認証局を使用して、Cloud Service Mesh で使用される証明書を管理できます。 | クラスタ内 CA を使用している場合、影響はありません。 Cloud Service Mesh 認証局を使用している場合、証明書は 24 時間後に期限切れになります。新しいサービス インスタンスは証明書を取得できません。 |
クラスタ内 CA の場合、無制限。 Cloud Service Mesh 認証局の場合、24 時間はサービス品質が低下し、24 時間後にサービスが無効になります。 |
クラスタ内 CA を使用します。 |
| Cloud Service Mesh 用の Cloud Monitoring | Cloud Monitoring を使用して、Cloud Service Mesh の HTTP 関連の指標を保存、探索、利用できます。 | 指標は保存されません。 | ゼロ | Prometheus などの互換性のあるローカル モニタリング ソリューションを使用します。 |
| Cloud Service Mesh の監査ロギング | Cloud Service Mesh は、ローカルの Kubernetes ロギング機能に依存します。この動作は、オンプレミス クラスタでロギングをどのように構成しているかに依存します。 | オンプレミス クラスタのロギングをどのように構成したかによって異なります。 | - | - |
| Ingress ゲートウェイ | Istio Ingress Gateway で外部 IP を定義できます。 | 影響なし | 無制限 | - |
| Istio Container Network Interface（CNI） | iptables の代わりに Istio CNI を使用してトラフィックを管理するように Cloud Service Mesh を構成できます。 | 影響なし | 無制限 | - |
| ウェブ アプリケーション用の Cloud Service Mesh エンドユーザー認証 | Cloud Service Mesh Ingress ゲートウェイを使用して、独自の ID プロバイダ（OIDC 経由）と統合し、メッシュの一部であるウェブ アプリケーションでエンドユーザーを認証および認可できます。 | 影響なし | 無制限 | - |
その他のネットワーク サービス
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| DNS | Kubernetes DNS サーバーはクラスタ内で実行されます。 | Kubernetes DNS サービスは、クラスタ内で実行されるため通常どおり動作します。 | 無制限 | - |
| 下り（外向き）プロキシ | 下り（外向き）接続にプロキシを使用するようにオンプレミス クラスタを構成できます。 | プロキシがオンプレミスで実行されている場合、クラスタは一時的な切断中にも引き続きプロキシを使用できます。ただし、プロキシが Google Cloudへの接続を失った場合、このドキュメントのすべてのシナリオが引き続き適用されます。 | 無制限 | - |
Google Cloud Marketplace
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| Cloud Marketplace からのアプリケーションとサービスのデプロイと管理 | Cloud Marketplace はコンソールで利用でき、ソリューションの検出、取得、デプロイに使用できます。 | Cloud Marketplace は使用できません。Cloud Marketplace の一部のソリューションで、ここに記載されていない独自の接続要件がある場合があります。 | ゼロ | なし |
サポート
このセクションでは、GDC 上の GKE クラスタに関連するケースについて、Google Cloud サポートまたはオペレーティング パートナーとやりとりする際に遭遇する可能性がある状況について説明します。
| 機能 | 接続中の動作 | 一時的な切断時の動作 | 切断の最大許容時間 | 接続喪失の回避策 |
|---|---|---|---|---|
| サポートチームとのクラスタ スナップショットの共有 | クラスタ スナップショットは、bmctl check
cluster コマンドまたは gkectl diagnose snapshot コマンドを使用してローカルで作成できます。このスナップショットは、通常のサポート プロセスを経て共有します。 |
スナップショットはローカル オペレーションであるため、引き続き生成できます。 Google Cloud とそのサポート ウェブ インターフェースにアクセスできなくなった場合、拡張サポートプランまたはプレミアム サポートプランに登録されていれば、サポートチームへ電話でのお問い合わせが可能です。 | 無制限 | - |
| 関連するログデータのサポートチームとの共有 | ローカルでクラスタからログを収集して、通常のサポート プロセスを通じて共有できます。 | クラスタからログを収集することはできます。 Google Cloud とそのサポート ウェブ インターフェースにアクセスできなくなった場合、拡張サポートプランまたはプレミアム サポートプランに登録されていれば、サポートチームへ電話でのお問い合わせが可能です。 | 無制限 | - |