ベアメタル用 Distributed Cloud ソフトウェアのみの概要

Google Distributed Cloud は、Google Cloud インフラストラクチャとサービスをお客様のデータセンターに拡張する、フルマネージドのソフトウェアとハードウェアのソリューションです。Google Distributed Cloud は、独自のハードウェアで実行されるソフトウェアのみのプロダクトとしても利用できます。Google Distributed Cloud ソフトウェアは、VMware またはベアメタルのいずれかにインストールできます。このガイドは、ベアメタル マシンで直接実行される Google Distributed Cloud ソフトウェアを対象としています。

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

ベアメタル向け Distributed Cloud ソフトウェアのみを使用する理由

既存のエンタープライズ インフラストラクチャでベアメタル用の Distributed Cloud ソフトウェアのみを実行すると、ハードウェアへの直接アクセス、エンタープライズ セキュリティ、環境全体の一元管理が可能になります。

直接的なハードウェア制御とパフォーマンス

物理サーバーに直接デプロイすると、アプリケーションのスケーリング、レイテンシ、パフォーマンスを直接制御しながら、既存のインフラストラクチャを使用して費用を削減できます。Google Distributed Cloud は既存の企業データセンター全体でアプリケーションのデプロイと健全性を管理し、運用効率を高めます。GPU や SSD などの特殊なハードウェア タイプに合わせてワークロードを最適化し、ハイパーバイザのオーバーヘッドなしでネットワーク エッジで低レイテンシのアプリケーションを実行できます。

オペレーティング システム レベルのセキュリティ

ノードのオペレーティング システムとネットワーク構成を直接管理できるため、コンプライアンス要件に合わせてセキュリティ ポリシーをカスタマイズできます。クラスタは、軽量で安全な接続を介して Google API と通信します。これにより、既存のセキュリティ管理を維持しながら、仮想マシンの複雑さを排除できます。

一元管理とモニタリング

Cloud Monitoring と Connect Agent を使用して、Google Cloud コンソールからクラスタを管理、モニタリング、トラブルシューティングします。この一元的な可視性により、分散データセンター全体で信頼性を維持し、アプリケーションのスケールを調整できます。

エンタープライズの信頼性と運用

Google Distributed Cloud には、プロダクション レディな運用機能が含まれています。

  • 高可用性: 複数のコントロール プレーン ノードがサポートされているため、ノードに障害が発生しても環境を管理できます。
  • 自動プリフライト チェック: 組み込みの検証機能により、インストール前にハードウェアとオペレーティング システムの構成を検証できます。
  • 統合ロード バランシング: レイヤ 4 とレイヤ 7 のロード バランシング メカニズムは、クラスタの作成時に自動的にデプロイされます。
  • データベース メンテナンス: 自動デフラグメンテーション(etcddefrag)により、ストレージを再利用して etcd の健全性と安定性を維持します。

仕組み

Google Cloudで実行されている GKE クラスタでは、Google が Kubernetes コントロール プレーンとネットワーク インフラストラクチャを管理します。データセンターで実行されている Google Distributed Cloud クラスタの場合、 Google Cloud は、物理 Linux サーバーにダウンロードしてインストールする管理プレーンとコントロール プレーンのソフトウェアを提供します。これらのオンプレミス クラスタは、統合フリートの一部として、クラウドベースのクラスタとともに Google Cloud で管理します。

次の図は、管理クラスタとユーザー クラスタを含む、インストール完了後のアーキテクチャを示しています。

管理クラスタとユーザー クラスタのデプロイの基本アーキテクチャ
管理クラスタとユーザー クラスタがあるベアメタル上の Google Distributed Cloud アーキテクチャ

主要コンポーネント

ソフトウェアのみのベアメタル デプロイは、次のコンポーネントで構成されます。

  • 管理クラスタ: Kubernetes Resource Management(KRM)を使用してユーザー クラスタのライフサイクルを管理します。標準デプロイは、1 つ以上のユーザー クラスタのライフサイクルを管理する管理クラスタで構成されています。管理クラスタは、コントロール プレーン ノードとして機能する 1 つ以上の物理 Linux マシンで構成されます。インストールの各ノードのマシンには、独自の IP アドレスがあります。
  • ユーザー クラスタ: コンテナ化されたワークロードを実行します。各ユーザー クラスタは、1 つ以上のコントロール プレーン ノードと 1 つのワーカーノードで構成されます。
  • 管理ワークステーション: 構成ファイルと管理ツールをホストする専用マシン。
    • bmctl: クラスタを作成、更新、管理します。
    • kubectl: 管理クラスタとユーザー クラスタを操作し、ワークロードを管理します。
  • GKE On-Prem API: クラスタ ライフサイクル管理用の Google Cloudがホストする API。 Google Cloud コンソール、Google Cloud CLI、Terraform などのクライアントを使用すると、管理ワークステーションにログインせずにオンプレミス クラスタを管理できます。
  • Google Cloud コンソール: オンプレミス クラスタを含む Google Cloudプロジェクトのウェブ インターフェースを提供します。 Google Cloud コンソールには、クラスタに関する主要な指標が表示されます。これにより、クラスタの正常性とフリートのステータスをモニタリングできます。
  • 仮想 IP アドレス(VIP): インストール時に構成された仮想 IP。クラスタ管理者とデベロッパーは、kubectl を使用して、コントロール プレーン VIP を介してクラスタ コントロール プレーンにアクセスします。アプリケーション ユーザーとデベロッパーは、Service VIP と Ingress VIP を使用し、それぞれワークロードにアクセスして公開します。

フリートへの接続

ユーザー クラスタ(および必要に応じて管理クラスタ)は、フリートに登録されます。フリートは、Kubernetes クラスタの論理グループであり、環境全体で統合管理を提供します。フリートを使用することで、組織は個々のクラスタを管理する体制から、クラスタ グループ全体を管理する体制に移行でき、Google 社内で使用されるものと同様のベスト プラクティスをチームが導入しやすくなります。Google Cloud コンソールでクラスタをまとめて表示し、フリート対応機能を使用してワークロードを大規模に管理、統制、運用できます。

各クラスタは、クラスタのインストール時に自動的にデプロイされる Connect Agent を介して Google Cloud に接続します。フリート メンバーシップは、Google Distributed Cloud の課金も決定します。

料金

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

料金の詳細と営業担当者へのお問い合わせ方法については、Google Kubernetes Engine の料金をご覧ください。

バージョン

Google Distributed Cloud のバージョンについては、バージョンのサポート ポリシーをご覧ください。

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

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

1.29 リリース以降、以前のマイナー リリースのドキュメント用に番号付きのディレクトリを作成することはなくなりました。バージョン 1.16 以前のアーカイブ ドキュメントは、次の URL にマイナー バージョン番号を追加すると表示されます。

https://cloud.google.com/anthos/clusters/docs/bare-metal/VERSION/

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

ベアメタル用 Distributed Cloud ソフトウェアのみのインストール

Google Distributed Cloud を使用して作成された GKE クラスタは独自のインフラストラクチャで実行されるため、柔軟な構成が可能です。特定の組織やユースケースのニーズを満たすデプロイモデルを選択すると、サポートされているさまざまなロード バランシング モード、IP アドレス指定オプション、セキュリティ機能、接続性オプションなどから選択できます。クラスタを設定するには、インストール前とインストール中に決定を行う必要があります。このドキュメント セットには、チームによる適切な機能とオプションの決定に役立つガイドが含まれています。インストールが組織のニーズを満たすようにするには、ネットワーキング チームとアプリケーション チームにご相談ください。

データの保存場所

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

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

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

  • コンテナ、Pod、PersistentVolume、ローカル ストレージ バックエンド、アプリケーションが処理するデータ。
  • コントロール プレーン(kube-apiserver、kube-scheduler、kube-controller-manager)と、すべての Kubernetes オブジェクトを保存する etcd データベース。
  • クラスタ CA、etcd CA、フロントプロキシ CA などの認証局(CA)の秘密鍵。管理クラスタのユーザー クラスタの名前空間には、ユーザー クラスタの CA が保存されます。
  • アプリケーション シークレット、OAuth トークン、SSH 秘密鍵、Container Registry の認証情報、サービス アカウント キーファイルは、etcd または管理者ワークステーションに保存されます。これらは GKE On-Prem API に送信されず、デフォルトの診断スナップショットにはクラスタの認証情報は含まれません。
  • クラスタ構成ファイルは、管理者ワークステーションに保存されます。クラスタが GKE On-Prem API に登録されている場合、一部の設定が送信されます。詳細については、 Google Cloudに送信されるデータをご覧ください。
  • 監査ログは、コントロール プレーン ノードで Cloud Audit Logs をオフにした場合にのみディスクに書き込まれます。
  • 診断スナップショットのアップロード用にサービス アカウントを設定すると、ファイルは Cloud Storage にアップロードされます。スナップショットを Cloud カスタマーケアと共有するかどうかを選択できます。

Google Cloudに送信されるデータ

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

データ 送信される情報 使用と保管 デフォルト
接続とフリート登録
(gkehub.googleapis.com、gkeconnect.googleapis.com)
  • Google Cloud プロジェクト、フリート メンバーシップ名、クラスタ UID、公開鍵、Kubernetes バージョン、クラスタサイズ、ID プロバイダの構成。
  • Google Cloud コンソールまたは Connect Gateway を介してリクエストする Kubernetes データ。
  • ユーザー プロファイルのGoogle Cloud コンソールからログインした場合、ログアウトするまで、暗号化された Kubernetes トークンが保存されます。
Google Cloud コンソール、Connect Gateway、Connect Agent を使用したフリートからクラスタを管理します。 必須
クラスタの設定とステータス
(gkeonprem.googleapis.com)
  • 名前、UID、説明、アノテーション、バージョン、ライフサイクル状態、コントロール プレーンの VIP とポート。
  • ノードプール名、ノード IP アドレス、Pod と Service の CIDR、ロードバランサの VIP とアドレスプール、BGP ピア IP アドレスと ASN、プロキシ URL、ローカル ストレージ パス。
  • クラスタ管理者のメールアドレス。
Google Cloud コンソール、Google Cloud CLI、または Terraform を使用してクラスタを管理できます。gkeOnPremAPI.location で設定されたリージョン(デフォルトは clusterOperations.location)の GKE On-Prem API によって保存されます。 バージョン 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、knative-serving、monitoring-system、gatekeeper-system、cnrm-system の各 Namespace からのコンテナログとヘルスチェックの結果。
  • メタデータ: ノード、Pod、Deployment、Service の名前とラベル。
Cloud Monitoring、 Google Cloud コンソールのステータス ビュー、カスタマーケアのトラブルシューティングに使用されます。clusterOperations.projectID で設定された Google Cloud プロジェクトに保存されます。指標は clusterOperations.location で設定されたリージョンに保存され、ログはログルーターの設定に従います。 システムログと指標の場合はオン。完全なカスタマーケア サポートと SLA の対象範囲に必要です。Stackdriver リソースで enableCloudLoggingForApplications または enableGMPForApplications を true に設定しない限り、アプリケーション ログと指標はオフになります。
監査ログ
(anthosaudit.googleapis.com)
管理アクティビティ監査ログ(audit-proxy): kube-apiserver を介して誰が何をいつ変更したか。エントリには、時刻、クラスタ、ホストまたは VM、ユーザーまたはサービス アカウント、RBAC ロール、オペレーション、結果が含まれます。読み取りリクエストは記録されません。 Google Cloud プロジェクトの Cloud Audit Logs の _Required バケットに保存され、400 日間保持されます。 オン。オフにするには、clusterOperations.disableCloudAuditLogging を true に設定します。監査ログは、コントロール プレーン ノードのディスクにのみ保持されます。

次のステップ

Google Distributed Cloud の使用を開始するには、次のガイドをご覧ください。