VMware 用 Google Distributed Cloud(ソフトウェアのみ)の概要

Google Distributed Cloud は、Google Cloud インフラストラクチャとサービスをお客様のデータセンターに拡張する、フルマネージドのソフトウェアとハードウェアのソリューションです。Google Distributed Cloud は、Google 提供のハードウェア上で動作する接続された構成とエアギャップ構成の両方で使用できます。Google Distributed Cloud は、VMware またはベアメタルの独自のハードウェアで実行されるソフトウェアのみのプロダクトとしても利用できます。このガイドは、VMware vSphere 環境内の独自のハードウェアで実行される Google Distributed Cloud ソフトウェアを対象としています。

Google Distributed Cloud は Google Kubernetes Engine(GKE)を基盤としており、オンプレミス環境で使用するために GKE を拡張する独自の Kubernetes パッケージを備えています。Google Distributed Cloud では、Google Cloud の機能を使用しながら、自社のオンプレミスで GKE クラスタを作成、管理、アップグレードし、Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションをクラスタ上で大規模にデプロイして運用できます。

Google Distributed Cloud ソフトウェアをインストールすると、コンテナ化されたワークロードを大規模に統制、管理、運用するための多くのGoogle Cloud 機能を使用できるようになります。VMware で利用可能な機能の詳細については、GKE の概要をご覧ください。

このページでは、VMware での Google Distributed Cloud の仕組みの概要を説明し、最小インストールまたは本番環境インストールの前提となる背景情報について説明します。

仕組み

Google Distributed Cloud は GKE を拡張して、オンプレミスの vSphere 環境に GKE クラスタを作成し、このクラスタをフリートの一部として通常の GKE クラスタや他の環境のクラスタと一緒に Google Cloud で管理できるようにします。

Google Distributed Cloud ソフトウェアはGoogle Cloudではなくデータセンターで実行されます。このため、GKE ソフトウェア自体に加えて、管理プレーンとコントロール プレーンのソフトウェアをインストールする必要があります。お客様のデータセンターで実行されるソフトウェアは、インストールとアップグレードのプロセスの一環としてダウンロードされます。

次の図は、完了したインストールの結果を簡略化して示しています。

管理クラスタとユーザー クラスタを示す図
1 つのユーザー クラスタが存在する Google Distributed Cloud アーキテクチャ

主要コンポーネント

Google Distributed Cloud の VMware 上のソフトウェア専用インストールは、次のコンポーネントで構成されます。

  • ユーザー クラスタは、 Google Cloudの GKE と同様に、アプリケーションを実装するワークロードを実行する場所です。ワークロードを実行するノードは、ワーカーノードと呼ばれます。また、1 つのユーザー クラスタには、1 つ以上のコントロール プレーン ノードがあります。上の図では、ユーザー クラスタにコントロール プレーン ノードが 1 つ存在しています。

  • 管理クラスタは、1 つ以上のユーザー クラスタを管理します。上の図では、管理クラスタに 3 つのコントロール プレーン ノードがあります。

  • 管理ワークステーションは、クラスタ作成者とデベロッパーが環境の管理に必要なツールが存在する個別のマシンです。

    • 管理ワークステーションから gkectl を実行すると、クラスタの作成と更新、その他の管理タスクの実行ができます。
    • 管理ワークステーションから kubectl を実行すると、ワークロードのデプロイや管理といった管理クラスタとユーザー クラスタの操作が可能になります。
  • Google Cloud コンソールは、VMware 上のクラスタを含む Google Cloud プロジェクトのウェブ インターフェースを提供します。管理ワークステーションでコマンドを実行する代わりに、 Google Cloud コンソールからクラスタの作成など、管理タスクのサブセットを実行できます。

  • クラスタ管理者とデベロッパーは、kubectl と仮想 IP アドレス(VIP)を使用して、管理クラスタとユーザー クラスタのコントロール プレーンにアクセスします。VIP はクラスタの作成時に構成します。ユーザー クラスタ内のワークロードを呼び出すユーザーやデベロッパーは、Service VIP と Ingress VIP を使用します。インストールの各ノードには独自の IP アドレスも割り当てられています。Google Distributed Cloud の IP 計画の詳細については、IP アドレスを計画するをご覧ください。

フリートへの接続

すべての Google Distributed Cloud クラスタは、Kubernetes クラスタの論理グループであるフリートのメンバーとなります。フリートを使用することで、組織は個々のクラスタを管理する体制から、クラスタ グループ全体を管理する体制に移行でき、Google 社内で使用されるものと同様のベスト プラクティスをチームが導入しやすくなります。 Google Cloud コンソールでフリート クラスタを表示して管理できます。また、フリート対応の機能を使用して大規模なワークロードを管理、統制、運用できます。オンプレミス環境で使用できるフリート機能の全一覧を確認できます。

各フリート クラスタと Google Cloud の接続は、Google Distributed Cloud のインストール プロセスの一部としてデプロイされる Connect Agent によって管理されます。このエージェントの動作の詳細については、Connect Agent の概要をご覧ください。

次のセクションで説明するように、フリート メンバーシップは Google Distributed Cloud の料金管理にも使用されます。

料金

Google Distributed Cloud の一部として作成されたオンプレミスの GKE クラスタは、vCPU ごとに課金されます。課金を有効にするには、 Google Cloud プロジェクトで Anthos API を有効にします。

営業担当者へのお問い合わせ方法などの料金に関する詳細については、GKE の料金をご覧ください。

Google Distributed Cloud on VMware のインストール

Google Distributed Cloud ソフトウェアは独自のインフラストラクチャで実行されるため、特定の組織やユースケースのニーズに合わせて構成できます。サポートされているさまざまなロード バランシング モード、vSphere 構成、IP アドレス指定オプション、セキュリティ機能、接続オプションなどから選択できます。このため、Google Distributed Cloud を設定するには、インストールの前と間に、ネットワーキング、vSphere、アプリケーションの各チームと協議のうえで、インストールがニーズを満たすように決定を行う必要があります。このドキュメント セットには、こうした決定をチームで行う際に役立つガイドが含まれています。

ただし、Google Distributed Cloud の動作を確認する必要がある場合は、小規模なテスト インストール用のシンプルなインストール パスも用意しています。多くのオプションがあるため、ワークロードを迅速に稼働させることができます。

いずれの場合も、インストール プロセスは次のとおりです。

  1. インストールを計画する。この手順には少なくとも、Google Distributed Cloud のリソースと vSphere の要件を満たしていることの確認、IP アドレスの計画などが含まれます。
  2. Google Distributed Cloud をサポートするオンプレミス環境を設定します(vSphere インベントリ オブジェクトの設定や Google への接続など)。
  3. Google Cloud リソースを設定する。これには、Google Distributed Cloud の設定と管理を行う際に使用する Google Cloud プロジェクトが含まれます。
  4. クラスタの作成に必要なリソースとツールを使用して、管理ワークステーションを作成します。
  5. ユーザー クラスタを作成、管理、更新するための管理クラスタを作成します。
  6. 実際のワークロードを実行するためのユーザー クラスタを作成します。

サポート対象のバージョン

このドキュメントでは、サポートされている Google Distributed Cloud のバージョンについて説明します。このドキュメントでは、サポート対象外の古いバージョンに関する情報も必要に応じて残しています。ドキュメントには要件と動作のバージョン固有の違いが記載されています。同様に、新しい機能が利用可能になると、その機能でサポートされているバージョンがドキュメントに記載されます。

サポートされているマイナー バージョンと利用可能なパッチの一覧については、バージョニングをご覧ください。

1.29 リリース以降、以前のマイナー リリースのディレクトリを作成することはなくなりました。動作の違いはドキュメントに記載されています。同様に、新しい機能が利用可能になると、その機能でサポートされているバージョンがドキュメントに記載されます。

以前のバージョンの完全なドキュメントは、次の URL にマイナー バージョン番号を追加すると表示できます。

https://cloud.google.com/anthos/clusters/docs/on-prem/VERSION/

VERSION をマイナー バージョン(1.0~1.16)に置き換えてから、URL をコピーしてブラウザのアドレスバーに貼り付けます。

データの保存場所

VMware 用の Distributed Cloud ソフトウェアのみを実行すると、クラスタ、アプリケーション、ビジネスデータはデータセンターに保持されます。デフォルトでは、Google Distributed Cloud は、設定、健全性、使用状況などのクラスタに関する Google Cloud 情報を送信しますが、アプリケーション データは送信しません。

データセンターに保持されるデータ

次のデータはデータセンターに保持されます。

  • コンテナ、Pod、PersistentVolume、アプリケーションが処理するデータ。
  • すべての Kubernetes オブジェクトは、コントロール プレーンと etcd データベースに保存されます。
  • 管理クラスタのコントロール プレーンには、自己署名 etcd 秘密鍵、ユーザー クラスタ鍵、クラスタ認証局(CA)が保存されます。
  • アプリケーション シークレット、OAuth トークン、SSH 秘密鍵、Container Registry 認証情報、vCenter と F5 BIG-IP の認証情報、サービス アカウント キーファイル。これらは etcd または管理者ワークステーションに保存されます。これらは GKE On-Prem API に送信されず、診断スナップショットから削除されます。
  • 管理クラスタ、ユーザー クラスタ、認証情報の構成ファイルは、管理者ワークステーションに保存されます。
  • 監査ログは、管理クラスタのコントロール プレーン ノードとユーザー クラスタのディスクに書き込まれます。
  • 診断スナップショットを Cloud Storage にアップロードすることもできます。

Google Cloudに送信されるデータ

次の表に、送信されるデータ、その使用方法と保存方法、オフにできるかどうかを示します。

データ 送信される情報 使用と保管 デフォルト
接続とフリート登録
(gkehub.googleapis.com、gkeconnect.googleapis.com)
  • クラスタ ID: Google Cloud プロジェクト、フリート メンバーシップ名、クラスタ UID、公開鍵、Kubernetes バージョン、クラスタサイズ、ID プロバイダ構成。
  • Google Cloud コンソールまたは Connect Gateway からリクエストされた Kubernetes データ。
  • Google Cloud コンソールからログアウトするまで、ユーザー プロファイルに暗号化された Kubernetes トークン。
Google Cloud コンソール、Connect Gateway、Connect Agent を使用したフリートからクラスタを管理します。kube-apiserver は、各リクエストを認証、認可、監査ログに記録します。 必須
クラスタの設定とステータス
(gkeonprem.googleapis.com)
  • 名前、UID、説明、アノテーション、バージョン、ライフサイクル状態、コントロール プレーン VIP。
  • ノードプール名、ノード IP または DHCP 設定、Pod と Service の CIDR、ロードバランサ VIP、ロードバランサ設定。
  • vCenter のアドレス、データセンター、クラスタ、リソースプール、データストア、フォルダ、ストレージ ポリシー名(vCenter の認証情報ではない)。
  • クラスタ管理者のメールアドレス。
Google Cloud コンソール、Google Cloud CLI、または Terraform を使用してクラスタを管理できます。GKE On-Prem API は、このデータを gkeOnPremAPI.location で設定されたリージョンに保存します。 バージョン 1.16 以降で、 Google Cloud プロジェクトで GKE On-Prem API が有効になっている場合はオン。オフにするには、gkeOnPremAPI.enabled を false に設定します。
請求の使用状況
(anthos.googleapis.com)
vCPU 容量、ノード数、ライセンス利用資格のステータス。 測定、課金、ライセンス チェックに使用されます。 必須。課金レコードは、サービス停止中にバッファリングされ、後で送信されます。
システムの健康に関するデータ
(logging.googleapis.com、monitoring.googleapis.com、opsconfigmonitoring.googleapis.com)
  • 指標: CPU、メモリ、ディスク、ネットワークの使用量、kubelet 指標、ノードとシステム Pod の kube-state-metrics。
  • すべての管理クラスタ コンポーネント、および kube-system、gke-system、gke-connect、istio-system、config-management-system ユーザー クラスタ名前空間からのコンテナログとヘルスチェックの結果。
  • メタデータ: ノード、Pod、Deployment、Service の名前とラベル。
Cloud Monitoring、 Google Cloud コンソールのステータス ビュー、カスタマーケアのトラブルシューティングに使用されます。stackdriver.projectID で設定された Google Cloud プロジェクトに保存されます。指標は stackdriver.clusterLocation リージョンに保存され、ログはログルーターの設定に従います。 システムログと指標の場合はオン。完全なカスタマーケア サポートと SLA の対象範囲に必要です。Stackdriver リソースで enableCloudLoggingForApplications または enableGMPForApplications を true に設定しない限り、アプリケーション ログと指標はオフになります。
監査ログ
(anthosaudit.googleapis.com)
管理アクティビティ監査ログ: kube-apiserver を介して誰が、何を、いつ変更したか。エントリには、時刻、クラスタ、ホストまたは VM、ユーザーまたはサービス アカウント、RBAC ロール、オペレーション、結果が含まれます。読み取りリクエストは記録されません。 cloudAuditLogging.projectID で設定された Google Cloud プロジェクトの Cloud Audit Logs に _Required バケットで保存され、400 日間保持されます。 (省略可)有効にするには、cloudAuditLogging セクションに入力します。管理クラスタの場合、作成時にのみ有効にできます。ユーザー クラスタで無効にするには、このセクションを削除してクラスタを更新します。

次のステップ