Distributed Cloud の仕組み

このページでは、Google Distributed Cloud の仕組みについて説明します。インフラストラクチャ、ハードウェア、ストレージ、ネットワーキング機能に関する情報も含まれます。

Google Distributed Cloud は次のコンポーネントで構成されています。

• 分散型クラウド インフラストラクチャ。Distributed Cloud ハードウェアは Google が提供、導入、管理します。これには Google の専属チームによるリモート管理も含まれます。
• Distributed Cloud サービス。このサービスを使用すると、Google Cloud CLI と Distributed Cloud Edge Container API を使用して、Distributed Cloud クラスタとノードプールを管理できます。Distributed Cloud クラスタはフリートに登録され、Kubernetes kubectl CLI ツールを使用して操作できます。

Distributed Cloud のフォーム ファクタ

Distributed Cloud は、次のいずれかのフォーム ファクタで使用できます。

• Distributed Cloud Rack。6 台の Distributed Cloud Server と 2 台のトップオブラック（ToR）スイッチがラックに収められています。このフォーム ファクタは、ローカル コントロール プレーン クラスタと Cloud コントロール プレーン クラスタの両方をサポートしています。

• Distributed Cloud Server。独自の ToR スイッチを介してローカル ネットワークに直接接続するスタンドアロンの Distributed Cloud Server。このフォーム ファクタは、ローカル コントロール プレーン クラスタのみをサポートします。Distributed Cloud Servers は 3 つのグループでのみデプロイできます。

  次の表に、Distributed Cloud ラックと Distributed Cloud サーバーの違いを示します。

  機能	GDC Edge ラック	GDC Edge サーバー
  物理フォーム ファクタ	フル装備のラック （2 台の ToR スイッチ、6 台のラックマウント マシン）	1RU ハーフデプス ラックマウント マシン （3 台のグループでデプロイ）
  電源	AC と DC	AC のみ
  クラスタタイプ	クラウド コントロール プレーンとローカル コントロール プレーン	ローカル コントロール プレーンのみ
  GPU ワークロード	サポート対象	非対応
  ローカル ネットワーク接続	レイヤ 3、BGP サポート	レイヤ 2、BGP はサポートされていません
  EdgeNetwork ネットワーク	完全に構成可能	単一（デフォルト）ネットワークのみ
  EdgeNetwork サブネットワーク	CIDR と VLAN ID	VLAN ID のみ
  EdgeNetwork 相互接続	サポート対象	非対応
  EdgeNetwork 相互接続アタッチメント	サポート対象	非対応
  EdgeNetwork VPN 接続	サポート対象	非対応
  VPC 接続	サポート対象	非対応
  Symcloud Storage	サポート対象	サポート対象
  ネットワーク機能オペレーター	サポート対象	非対応
  SR-IOV	サポート対象	非対応

Distributed Cloud インフラストラクチャ

Google は、Distributed Cloud ゾーンを実行する専用ハードウェアを提供、デプロイ、運用、保守します。ワークロードを実行する Distributed Cloud ノードは、このハードウェアでのみ実行されます。

ハードウェアは、ノードプールにグループ化された複数のノードを実行します。これらのノードプールは、Distributed Cloud ゾーン内のクラスタに割り当てることができます。ネットワークを構成して、Distributed Cloud クラスタで実行されるワークロードをローカル ユーザーのみが利用できるようにしたり、インターネットからアクセスできるようにしたりできます。また、分散クラウドノードのみがローカル リソースを使用できるように、または VPC ネットワークへの安全な Cloud VPN ネットワーク接続を介して VPC ネットワークで実行されている Compute Engine 仮想マシン（VM）インスタンスや Kubernetes Pod などのワークロードと通信できるように、ネットワークを構成することもできます。

Distributed Cloud の管理

Distributed Cloud ノードはスタンドアロン リソースではなく、コントロール プレーンの管理とモニタリングの目的で Google Cloud に接続されたままにする必要があります。Distributed Cloud コントロール プレーン ノードは、指定された Google Cloud リージョンでホストされます。オンプレミスの Distributed Cloud ノードには、 Google Cloudへの継続的なネットワーク接続が必要です。

Google は、Distributed Cloud のインストールを構成する物理マシンと ToR スイッチをリモートで管理します。これには、ソフトウェア アップデートとセキュリティ パッチのインストール、構成の問題の解決が含まれます。ネットワーク管理者は、Distributed Cloud クラスタとノードの健全性とパフォーマンスをモニタリングし、Google と協力して問題を解決することもできます。

Google が指定された場所に Distributed Cloud ハードウェアを正常にデプロイすると、クラスタ管理者は従来の Kubernetes クラスタと同様の方法で Distributed Cloud クラスタの構成を開始できます。マシンをノードプールに、ノードプールをクラスタに割り当て、ロールに必要なアプリケーション オーナーにアクセス権を付与できます。ただし、クラスタ管理者は、Distributed Cloud ラック内のマシンの処理とストレージの制限を考慮し、それに応じてクラスタとワークロードの構成を計画する必要があります。

Distributed Cloud は、クラスタとノードプールを構成するための API を提供します。

Distributed Cloud ゾーンへのアクセス

ローカル ネットワークとインターネットの両方から、Distributed Cloud ゾーンへのアクセスレベルを構成できます。

また、Distributed Cloud ゾーンを VPC ネットワークに接続して、Google Cloud サービスへのアクセス権を付与することもできます。Distributed Cloud は、Cloud VPN を使用して Google サービス エンドポイントに接続します。ネットワーク管理者が、これを許可するようにネットワークを構成する必要があります。

Distributed Cloud のペルソナ

Distributed Cloud ゾーンのデプロイと運用には、次のペルソナが関与します。

• Google のフィールド技術者。指定された場所に Distributed Cloud ハードウェアを配送、設置、有効化します。ネットワーク管理者が Google の技術者と協力して、ハードウェアを電源に接続し、ネットワークに接続します。

• Google サイト信頼性エンジニア（SRE）。Distributed Cloud ハードウェアをモニタリングして管理します。これには、構成の問題の解決、パッチとアップデートのインストール、セキュリティの維持が含まれます。

• ネットワーク管理者。Distributed Cloud ハードウェアとローカル ネットワーク間のネットワーク接続とアクセス制御を構成して維持します。これには、必要なすべてのタイプのネットワーク トラフィックが、Distributed Cloud ハードウェア Google Cloud、Distributed Cloud ワークロードを使用するクライアント、内部および外部のデータ リポジトリなどの間で自由に流れるように、ルーティング ルールとファイアウォール ルールを構成することが含まれます。ネットワーク管理者は、Distributed Cloud マシンのステータスをモニタリングするために、 Google Cloud コンソールにアクセスする必要があります。ネットワーク管理者は、Distributed Cloud ネットワーキング機能も構成します。

• クラスタ管理者。組織内の Distributed Cloud クラスタをデプロイして維持します。これには、各クラスタの権限、ロギング、ワークロードのプロビジョニングの構成が含まれます。クラスタ管理者は、ノードをノードプールに、ノードプールを Distributed Cloud クラスタに割り当てます。クラスタ管理者は、ワークロードを正しく構成してデプロイするために、Distributed Cloud クラスタと従来の Kubernetes クラスタの運用上の違い（Distributed Cloud ハードウェアの処理機能やストレージ機能など）を理解する必要があります。

• アプリケーション オーナー。Distributed Cloud クラスタで実行されているアプリケーションの開発、デプロイ、モニタリングを担当するソフトウェア エンジニア。分散クラウド クラスタでアプリケーションを所有するアプリケーション オーナーは、クラスタのサイズとロケーションの制限と、パフォーマンスやレイテンシなど、エッジにアプリケーションをデプロイすることによる影響を理解する必要があります。

Distributed Cloud Rack ハードウェア

図 1 は、一般的な Distributed Cloud ラック構成を示しています。

図 1. Distributed Cloud コンポーネント。

Distributed Cloud インストールのコンポーネントは次のとおりです。

• Google Cloud. Distributed Cloud インストールと Google Cloud 間のトラフィックには、ハードウェア管理トラフィック、コントロール プレーン トラフィック、 Google Cloudサービスとそこで実行しているワークロードへの Cloud VPN トラフィックが含まれます。該当する場合は、VPC トラフィックも含まれます。

• インターネット。Distributed Cloud のインストールと Google Cloud間の管理プレーンとコントロール プレーンのトラフィックは暗号化され、インターネット経由で転送されます。Distributed Cloud は、プロキシ インターネット接続をサポートしていません。

• ローカル ネットワーク。ピアリング エッジルーターをインターネットに接続する、Distributed Cloud ラックの外部にあるローカル ネットワーク。

• ピアリング エッジルーター。Distributed Cloud ToR スイッチとインターフェースするローカル ネットワーク ルーター。Distributed Cloud のインストール用に選択した物理ロケーションに応じて、ピアリング エッジルーターは組織またはコロケーション施設が所有して管理できます。これらのルーターを構成して、Border Gateway Protocol（BGP）を使用して ToR スイッチとピアリングし、Distributed Cloud ハードウェアにデフォルト ルートをアドバタイズする必要があります。また、これらのルーターと対応するファイアウォールを構成して、Google のデバイス管理トラフィック、Distributed Cloud コントロール プレーン トラフィック、Cloud VPN トラフィック（該当する場合）を許可する必要があります。

  ビジネス要件に応じて、これらのルーターを次のように構成できます。

  • パブリック ネットワーク アドレス変換（NAT）またはパブリック IP アドレスへの直接公開を使用して、Distributed Cloud ノードがインターネットにアクセスできるようにします。
  • VPC ネットワークと必要なGoogle Cloud サービスへの VPN 接続を許可します。

• トップオブラック（ToR）スイッチ。ラック内のマシンを接続し、ローカル ネットワークとインターフェースするレイヤ 3 スイッチ。これらのスイッチは BGP スピーカーで、Distributed Cloud ラックとローカル ネットワーク機器の間のネットワーク トラフィックを処理します。スイッチは、LACP（Link Aggregation Control Protocol）バンドルを使用してピアリング対象のエッジルーターに接続されます。

• マシン。Distributed Cloud ソフトウェアを実行し、ワークロードを実行する物理マシン。各物理マシンは、Distributed Cloud クラスタ内のノードです。

Distributed Cloud Server ハードウェア

図 2 は、一般的な Distributed Cloud Server の構成を示しています。

図 2. Distributed Cloud Server コンポーネント。

Distributed Cloud インストールのコンポーネントは次のとおりです。

• Google Cloud. Distributed Cloud インストールと Google Cloud 間のトラフィックには、ハードウェア管理と監査ロギングのトラフィックが含まれます。該当する場合は、VPC トラフィックも含まれます。

• インターネット。Distributed Cloud のインストールと Google Cloud間の暗号化された管理トラフィックと監査ロギング トラフィックは、インターネット経由で転送されます。Distributed Cloud は、プロキシ インターネット接続をサポートしていません。

• ローカル ネットワーク。レイヤ 2 ToR スイッチを介して Distributed Cloud Servers が接続するローカル ネットワーク。

• トップオブラック（ToR）スイッチ。サーバーマシンを接続し、ローカル ネットワークとインターフェースするレイヤ 2 スイッチ。各 Distributed Cloud Server マシンには、少なくとも 1 つのインバンド接続と 1 つのアウトオブバンド接続が必要です。信頼性を高めるために、マシンごとに 2 つの ToR スイッチと 2 つのインバンド接続（スイッチごとに 1 つ）を使用することをおすすめします。各 Distributed Cloud Server マシンは、次のように ToR スイッチに接続します。

  • インバンド接続。各 Distributed Cloud Server マシンは、インバンド接続用に 1 つまたは両方の ToR スイッチに接続します。これらの接続はワークロード トラフィックを伝送します。これらは 802.1q トランクとして構成し、対応するネイティブ VLAN を Distributed Cloud 管理ネットワーク インターフェースが属するネットワークとして構成する必要があります。ワークロードの接続を追加する必要がある場合は、追加のタグ付き VLAN を Distributed Cloud Servers にトランキングできます。
  • 帯域外接続。各 Distributed Cloud Server は、アウトオブバンド接続用の ToR スイッチにも接続されます。これにより、Distributed Cloud Server が相互に通信できるようになります。アウトオブバンド スイッチポートは同じ VLAN 内に配置する必要があります。

• マシン。Distributed Cloud ソフトウェアを実行し、ワークロードを実行する物理 Distributed Cloud Server マシン。各物理マシンは、Distributed Cloud クラスタ内のノードです。

分散型クラウド サービス

Distributed Cloud サービスは、Cloud コントロール プレーン クラスタの場合は Google Cloudで実行され、ローカル コントロール プレーン クラスタの場合は Distributed Cloud ハードウェアで直接実行されます。Distributed Cloud ハードウェア上のノードとクラスタのコントロール プレーンとして機能します。

リモート コントロール プレーン クラスタの場合、Distributed Cloud は常にGoogle Cloud に接続できる必要があり、その接続がないと機能しません。ローカル コントロール プレーン クラスタの場合、Distributed Cloud が Google Cloud に最大 7 日間接続できなくても、ワークロードは引き続き実行されます。この期間が経過すると、Distributed Cloud は Google Cloud と通信して、認証トークンとストレージ暗号鍵を更新し、ハードウェア管理と監査ロギングのデータを同期する必要があります。

このコントロール プレーンは、Distributed Cloud ゾーンをインスタンス化して構成します。管理のために Distributed Cloud ハードウェアが接続する特定の Google データセンターは、Distributed Cloud のインストール場所との近接性に基づいて選択されます。

Distributed Cloud ゾーンは、Distributed Cloud ラックにインストールされたマシン、またはオンプレミスにデプロイされた Distributed Cloud サーバーマシンで構成されます。Distributed Cloud Rack では、Kubernetes ノードとしてインスタンス化されたこれらのマシンをノードプールに割り当て、ノードプールを Distributed Cloud クラスタに割り当てることができます。Distributed Cloud Servers では、ノードプールは自動的に入力され、構成できません。

図 3 は、Distributed Cloud エンティティの論理的な構成を示しています。

図 3. Distributed Cloud エンティティ。

エンティティは次のとおりです。

• Google Cloud region. Distributed Cloud ゾーンの Google Cloud リージョンは、Distributed Cloud のインストールに最も近い Google データセンターのロケーションによって決まります。

• Kubernetes クラウド コントロール プレーン。各 Distributed Cloud クラスタの Kubernetes コントロール プレーンは、デフォルトで、Distributed Cloud クラスタが割り当てられている Google Cloud リージョンの Google データセンターでリモートで実行されます。これにより、Distributed Cloud は、Distributed Cloud 物理マシンの処理能力を消費することなく、安全で可用性の高いコントロール プレーンのメリットを享受できます。クラウド コントロール プレーン クラスタは、Distributed Cloud Servers では使用できません。

• Kubernetes ローカル コントロール プレーン。Google Distributed Cloud バージョン 1.5.0 以降では、デフォルトのクラウド コントロール プレーンではなくローカル コントロール プレーンを使用するように Distributed Cloud クラスタを構成できます。ローカル コントロール プレーン クラスタは、Google Cloud への接続が一時的に失われたときに存続モードに入り、接続が復元されるまでワークロードの実行を継続できます。これは、Distributed Cloud Servers で使用できる唯一のクラスタタイプです。詳細については、サバイバビリティ モードをご覧ください。

• Distributed Cloud ゾーン。オンプレミスにデプロイされた Distributed Cloud ハードウェアを表す論理的抽象化。Distributed Cloud ゾーンは、単一の Distributed Cloud ラック、またはお客様のロケーションにデプロイされたすべての Distributed Cloud サーバー マシンを対象とします。ゾーン内の物理マシンは、 Google Cloud コンソールで Distributed Cloud マシンとしてインスタンス化されます。Distributed Cloud ゾーン内のマシンは、単一のネットワーク ファブリックまたは単一のフォールト ドメインを共有します。Google は、Distributed Cloud ハードウェアを納品する前にマシンを作成します。Distributed Cloud マシンを作成、削除、変更することはできません。

  注: Distributed Cloud ゾーンは Compute Engine ゾーンとは異なり、 Google Cloud はこれら 2 種類のゾーンを異なる方法で扱います。Distributed Cloud ゾーンは、 Google Cloud コンソールの Compute Engine ゾーンのリストに表示されません。

• ノード。ノードは、ノードプールの作成時に Distributed Cloud 物理マシンを Kubernetes 領域にインスタンス化する Kubernetes リソースです。ノードプールを Distributed Cloud クラスタに割り当てることで、ワークロードを実行できるようになります。

• ノードプール。単一の Distributed Cloud ゾーン内の Distributed Cloud ノードの論理グループ。Distributed Cloud ノードを Distributed Cloud クラスタに割り当てることができます。Distributed Cloud Servers の場合、ノードプールは自動的にインスタンス化され、入力されます。

• Cluster. コントロール プレーンと 1 つ以上のノードプールで構成される Distributed Cloud クラスタ。

• VPN 接続。Google Cloud プロジェクトで実行されている VPC ネットワークへの VPN トンネル。このトンネルにより、Distributed Cloud ワークロードは、その VPC ネットワークに接続されている Compute Engine リソースにアクセスできます。VPN 接続を作成するには、ゾーンに少なくとも 1 つのノードプールを作成する必要があります。Distributed Cloud Servers は VPN 接続をサポートしていません。

ストレージ

Distributed Cloud では、Distributed Cloud ラック内の物理マシン 1 台あたり 3.3 TiB の使用可能なストレージが提供されます。このストレージは Linux 論理ボリュームとして構成されます。クラスタを作成すると、Distributed Cloud は 1 つ以上の PersistentVolume を作成し、それらをブロック ボリュームとして公開します。このブロック ボリュームは、PersistentVolumeClaims を使用してワークロードに割り当てることができます。これらの PersistentVolume はデータの耐久性を提供せず、エフェメラル データにのみ適しています。ブロック ボリュームの操作については、Raw ブロック ボリュームをリクエストする PersistentVolumeClaim をご覧ください。

Distributed Cloud Servers の場合、ストレージは Rakuten Symcloud Storage を介してのみ抽象化されます。各 Distributed Cloud Server マシンは、1 TB の使用可能なストレージを提供します。

ストレージ セキュリティ

Distributed Cloud は、LUKS を使用してローカルマシンのストレージを暗号化し、顧客管理の暗号鍵（CMEK）をサポートしています。詳細については、セキュリティのベスト プラクティスをご覧ください。

Symcloud Storage の統合

Distributed Cloud Racks では、Distributed Cloud が Rakuten Symcloud Storage を使用するように構成できます。これは、各 Distributed Cloud Rack ノードのローカル ストレージ抽象化レイヤとして機能し、他の Distributed Cloud ノードで実行されているワークロードでローカル ストレージを使用できるようにします。Distributed Cloud Servers では、Symcloud Storage がデフォルトであり、利用可能な唯一のストレージ オプションです。Distributed Cloud Servers は、ローカル ストレージを Linux 論理ボリュームとして公開しません。

詳細については、Symcloud Storage 用に Distributed Cloud を構成するをご覧ください。

ネットワーキング

このセクションでは、Distributed Cloud のネットワーク接続の要件と機能について説明します。

Google は、Distributed Cloud ハードウェアをお客様に発送する前に、インストール用に Distributed Cloud 仮想ネットワーキング コンポーネントの一部を事前構成します。ハードウェアの納品後に事前構成された設定を変更することはできません。

図 3 は、Distributed Cloud 仮想ネットワークのトポロジを示しています。

図 3. Distributed Cloud ネットワーキング コンポーネント。

Distributed Cloud 仮想ネットワークのコンポーネントは次のとおりです。

• ネットワーク。Distributed Cloud ゾーンにプライベート アドレス空間を持つ仮想ネットワーク。ネットワークは、ゾーン内の他の仮想ネットワークからレイヤ 3 で分離され、1 つ以上のサブネットワークを含めることができます。仮想ネットワークは、Distributed Cloud ラック内のすべての物理マシンにまたがっています。単一の Distributed Cloud ゾーンでサポートされるネットワークの最大数は 20 です。Distributed Cloud Servers は、Distributed Cloud Server クラスタのインスタンス化時に作成されるデフォルトのネットワーク 1 つのみをサポートします。

• サブネットワーク。Distributed Cloud ネットワーク内のレイヤ 2 とレイヤ 3 の VLAN サブネットワーク。サブネットワークには、独自のブロードキャスト ドメインと、選択した 1 つ以上の IPv4 アドレス範囲があります。同じネットワーク内のサブネットワークはレイヤ 2 で分離されますが、レイヤ 3 を介して相互に通信できます。同じネットワーク内の異なるサブネットワークにあるノードは、IP アドレスを使用して相互に通信できます。ただし、異なるネットワーク内のサブネットワーク上のノードは相互に通信できません。Distributed Cloud Servers は、VLAN ID を使用したサブネットワーク管理のみをサポートしています。

• ルーター。Distributed Cloud ネットワーク内のトラフィックを制御する仮想ルーター インスタンス。ネットワーク管理者は、ルーターを使用して、Distributed Cloud Pod がローカル ネットワークでネットワーク プレフィックスをアドバタイズできるように、Distributed Cloud ネットワークとローカル ネットワーク間のインターコネクト アタッチメントを介して BGP ピアリング セッションを構成します。デフォルトでは、ルーターは Distributed Cloud サブネットワークから受信したルートを再アドバタイズします。Distributed Cloud は、ネットワークごとに 1 つのルーターをサポートします。Distributed Cloud Servers はルーターをサポートしていません。

• Interconnect. Distributed Cloud ネットワークとローカル ネットワーク間のバンドルされた論理リンク。相互接続は 1 つ以上の物理リンクで構成されます。初回起動時に、Google は Distributed Cloud の注文時にリクエストした相互接続を作成します。Distributed Cloud ラックが稼働した後は、相互接続の作成、変更、削除はできません。デフォルトでは、Google はインストールに高可用性を提供するために 4 つのインターコネクトを作成します。Distributed Cloud Servers は相互接続をサポートしていません。

• 相互接続のアタッチメント。インターコネクトとルーター間の仮想リンク。対応する Distributed Cloud ネットワークをローカル ネットワークから分離します。相互接続のアタッチメントを通過するトラフィックは、タグなしにすることも、選択した VLAN ID でタグ付けすることもできます。ビジネス要件に基づいて相互接続アタッチメントを作成します。Distributed Cloud は、相互接続アタッチメントをサポートしていません。

Distributed Cloud のネットワーキング コンポーネントは、次の違いを除いて、同等のコンポーネントと類似しています。 Google Cloud

• Distributed Cloud ネットワーキング コンポーネントは、インスタンス化される Distributed Cloud ゾーンにローカルです。

• Distributed Cloud ネットワークは VPC ネットワークに直接接続されていません。

• デフォルトでは、Distributed Cloud ネットワークは、異なる Distributed Cloud ゾーン間で相互に接続されていません。クロスゾーン ネットワーキングを明示的に構成することもできます。

ネットワーク管理者は、Distributed Cloud のネットワーキング コンポーネント（相互接続を除く）を構成します。相互接続は、Google が Distributed Cloud ハードウェアを発送する前に構成します。

ネットワーク管理者は、ターゲット Google Cloud プロジェクトに対する Edge ネットワーク管理者ロール（roles/edgenetwork.admin）が必要です。一方、Distributed Cloud にワークロードをデプロイするアプリケーション デベロッパーは、ターゲット Google Cloud プロジェクトに対する Edge ネットワーク閲覧者ロール（roles/edgenetwork.viewer）が必要です。

ローカル ネットワークへの接続

ローカル ネットワーク上のリソースへの下り（外向き）トラフィックの場合、Distributed Cloud クラスタ内の Pod は、ピアリング エッジルーターによってアドバタイズされるデフォルト ルートを使用します。Distributed Cloud は、組み込みの NAT を使用して Pod をこれらのリソースに接続します。

ローカル ネットワーク上のリソースからのインバウンド トラフィックの場合、ネットワーク管理者は、ビジネス要件に一致するルーティング ポリシーを構成して、各 Distributed Cloud クラスタの Pod へのアクセスを制御する必要があります。つまり、少なくとも、ファイアウォール構成の手順を完了し、ワークロードで必要に応じて追加のポリシーを構成する必要があります。たとえば、Distributed Cloud の組み込みロードバランサによって公開される個々のノード サブネットワークまたは仮想 IP アドレスに対して、許可/拒否ポリシーを設定できます。Distributed Cloud Pod と Distributed Cloud Service の CIDR ブロックには直接アクセスできません。

インターネットへの接続

インターネット上のリソースへの下り（外向き）トラフィックの場合、Distributed Cloud クラスタ内の Pod は、ルーターによって Distributed Cloud ToR スイッチにアドバタイズされるデフォルト ルートを使用します。つまり、少なくともファイアウォール構成の手順を完了し、ワークロードで必要に応じて追加のポリシーを構成する必要があります。Distributed Cloud は、組み込みの NAT を使用して Pod をこれらのリソースに接続します。必要に応じて、Distributed Cloud の組み込みレイヤの上に独自の NAT レイヤを構成できます。

インバウンド トラフィックの場合は、ビジネス要件に応じて WAN ルーターを構成する必要があります。これらの要件によって、パブリック インターネットから Distributed Cloud クラスタの Pod に提供する必要があるアクセスレベルが決まります。Distributed Cloud は、Pod CIDR ブロックとサービス管理 CIDR ブロックに組み込みの NAT を使用するため、これらの CIDR ブロックはインターネットからアクセスできません。

VPC ネットワークへの接続

Distributed Cloud には、Distributed Cloud クラスタが VPC インスタンスと同じGoogle Cloud プロジェクトにある場合に、Distributed Cloud クラスタを VPC インスタンスに直接接続できる組み込みの VPN ソリューションが用意されています。

Cloud Interconnect を使用してローカル ネットワークを VPC インスタンスに接続する場合、Distributed Cloud クラスタは標準のノースバウンド eBGP ピアリングを使用してそのインスタンスにアクセスできます。ピアリング エッジルーターは適切な VPC 接頭辞に到達でき、Cloud Interconnect ルーターは Distributed Cloud ロードバランサ、管理、システム サブネットワークなどの Distributed Cloud 接頭辞を正しくアドバタイズする必要があります。

Distributed Cloud クラスタと VPC ネットワークの間に VPN 接続を確立すると、次の接続ルールがデフォルトで適用されます。

• VPC ネットワークは、Distributed Cloud クラスタ内のすべての Pod にアクセスできます。
• Distributed Cloud クラスタ内のすべての Pod は、VPC ネイティブ クラスタ内のすべての Pod にアクセスできます。ルートベースのクラスタの場合、カスタム アドバタイズ ルートを手動で構成する必要があります。
• Distributed Cloud クラスタ内のすべての Pod は、VPC ネットワーク内の仮想マシン サブネットワークにアクセスできます。

このセクションで説明する機能は、Distributed Cloud Servers では使用できません。

Google Cloud API とサービスへの接続

VPC ネットワークへの VPN 接続を構成すると、Distributed Cloud インストールで実行されているワークロードが Google Cloud API とサービスにアクセスできるようになります。

ビジネス要件に応じて、次の機能を追加で構成できます。

• 限定公開の Google アクセスを使用して Google Cloud API とサービスにアクセスする
• Private Service Connect を使用して、プライベート サービス エンドポイントから Google Cloud API にアクセスする

Distributed Cloud Servers では VPN 接続は使用できません。

ネットワーク セキュリティ

ビジネス要件と組織のネットワーク セキュリティ ポリシーによって、Distributed Cloud のインストールに出入りするネットワーク トラフィックを保護するために必要な手順が規定されます。詳細については、セキュリティのベスト プラクティスをご覧ください。

その他のネットワーキング機能

Distributed Cloud は、次のネットワーキング機能をサポートしています。

• ロード バランシング
• Kubernetes Ingress リソース

ハイ パフォーマンス ネットワーキングのサポート

Distributed Cloud Racks は、可能な限り最高のネットワーキング パフォーマンスを必要とするワークロードの実行をサポートします。このため、Distributed Cloud には、高パフォーマンスのワークロード実行に必要な機能を実装する専用のネットワーク機能オペレータと Kubernetes CustomResourceDefinitions（CRD）のセットが付属しています。

Distributed Cloud Racks は、SR-IOV を使用したネットワーク インターフェースの仮想化もサポートしています。

このセクションで説明する機能は、Distributed Cloud Servers では使用できません。

仮想マシンのワークロードのサポート

Distributed Cloud では、コンテナに加えて仮想マシンでワークロードを実行できます。詳細については、仮想マシンを管理するをご覧ください。

仮想マシンが Google Distributed Cloud プラットフォームの重要なコンポーネントとして機能する方法については、GKE Enterprise を拡張してオンプレミス エッジ VM を管理するをご覧ください。

GPU ワークロードのサポート

Distributed Cloud は、NVIDIA Tesla T4 GPU で GPU ベースのワークロードを実行できます。この要件は、Distributed Cloud ハードウェアを注文する際に指定する必要があります。詳細については、GPU ワークロードを管理するをご覧ください。

この機能は Distributed Cloud Servers では使用できません。

次のステップ

• ネットワーキング機能