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