このガイドでは、Google Distributed Cloud（GDC）エアギャップ環境の IP アドレス計画の概要について説明します。効果的な IP アドレス管理は、GDC のエアギャップ ソリューションのデプロイ、運用、スケーリングを成功させるうえで不可欠です。
このドキュメントは、以下の方を対象としています。
- インフラストラクチャ オペレーター（IO）: 基盤となるネットワーク インフラストラクチャやテナント組織の作成など、GDC のエアギャップ ゾーンの全体的な計画、デプロイ、運用を担当する個人またはチーム。
プロダクトの概要
Google Distributed Cloud（GDC）エアギャップは、パブリック クラウドから完全に切断された、厳格なセキュリティまたはデータ主権に関する制限のある環境でクラウド テクノロジーを実行できるハードウェアとソフトウェアの統合ソリューションです。GDC 1.14 では、組織ごとの単一のインフラストラクチャ クラスタや高度な Virtual Private Cloud（VPC）ネットワーキング機能など、クラスタ設計とネットワーキングが大幅に強化されています。
GDC エアギャップでは、次の理由から IP アドレスを慎重に計画することが不可欠です。
- 分離: 異なるテナント（組織）間、管理プレーンとデータプレーン間の適切なネットワーク セグメンテーション。
- スケーラビリティ: VM、コンテナ、サービスなど、現在および将来のワークロードに十分な IP アドレス空間。
- 接続: GDC のエアギャップ環境内のすべてのコンポーネントと、必要に応じて外部ネットワークへの正しいルーティングと到達可能性。
- コンプライアンス: 環境で義務付けられている特定のネットワーク アドレス指定スキームまたは制限の遵守。
GDC アーキテクチャは、仮想ルーティングと転送（VRF）インスタンスを利用して、ネットワークの分離とセグメンテーションを実現します。IO と PA のどちらがどの IP アドレス空間を管理しているかを理解することが、計画を成功させる鍵となります。
ゾーン IP の計画
インフラストラクチャ オペレーターは、GDC エアギャップ ゾーン全体の基盤となる IP アドレス空間の計画を担当します。これには、ゾーンのコア インフラストラクチャ、共有サービス、新しい組織のブートストラップに必要な初期ネットワーク セグメントのネットワークが含まれます。
ゾーン インフラストラクチャ ネットワーク
ゾーン インフラストラクチャ ネットワークは、最初のゾーン ブートストラップ中に IO によってプロビジョニングされ、GDC エアギャップ環境の機能に不可欠です。アドレスは、GDC のエアギャップ環境内でグローバルに一意である必要があり、通常は RFC 1918 プライベート アドレス空間を使用します。これらのネットワークはグローバルに予約され、テナント組織のネットワークで使用できなくなります。
完全なリファレンス/仕様については、要件収集テンプレート を参照してください。
これらの IP アドレスは、顧客取り込みアンケート（CIQ）やその他のゾーン ブートストラップ手順を使用してゾーンをブートストラップするときに IO によって提供されます。
組織インフラストラクチャ ネットワーク
IO が新しい組織を作成すると、特定の基盤となるネットワークがプロビジョニングされます。これらは GDC エアギャップ インフラストラクチャ アドレス空間の一部であり、グローバルに一意である必要があります。アドレスは、ゾーン ブートストラップで指定されたゾーン インフラストラクチャ ネットワークから自動的に割り当てられます。組織の管理者とユーザーは、これらのネットワークを認識していません。
組織の IP 計画
組織を作成する際、IO は PA と協力して、組織入力アンケート（OIQ）プロセスの一環として組織の IP アドレス指定を計画する必要があります。これらの CIDR は、各ゾーンで組織のインフラストラクチャ クラスタをブートストラップするために使用されます。これらの CIDR は、相互に重複したり、ゾーン インフラストラクチャ ネットワークなどのグローバルに予約されたネットワークと重複したりしてはなりません。ゾーン インフラストラクチャ ネットワークは、CIQ から取得するか、ルート管理者クラスタをクエリすることで取得できます。
制約の詳細については、要件収集テンプレートをご覧ください。
これらの詳細は IO によって PA から収集され、組織のプロビジョニングに使用されます。組織の IP アドレス計画に関連する主な OIQ フィールドは次のとおりです。
infraVPCCIDR:- 説明: 組織コンソール、管理 API、ファーストパーティ サービスなど、組織内のシステム ワークロードに使用されます。
- グローバル ルート サブネット名:
infra-vpc-root-cidr - グローバル API サーバー: グローバル ルート
defaultVPCCIDR- 説明: 組織内のユーザー ワークロード（ユーザー VM、Pod CIDR、Kubernetes クラスタノードなど）に使用されます。
- グローバル ルート サブネット名:
default-vpc-root-cidr - グローバル API サーバー: グローバル組織 API
orgAdminExternalCIDR:- 説明: 外部ネットワークと組織間の管理トラフィックを処理する、境界クラスタ内のワークロードとエンドポイント。
- グローバル ルート サブネット名:
admin-external-root-cidr - グローバル API サーバー: グローバル ルート
orgDataExternalCIDR:- 説明: 外部ロードバランサや下り（外向き）NAT など、ユーザーが外部からアクセスできるワークロードとエンドポイント。
- グローバル ルート サブネット名:
data-external-root-cidr - グローバル API サーバー: グローバル ルート
計画プロセス
組織のネットワーク アドレスの計画とプロビジョニングの概要は次のとおりです。
PA と協力して CIDR を定義する: 組織の PA と協力して、インフラストラクチャ VPC、デフォルト VPC、組織管理者ネットワーク セグメント、組織データ ネットワーク セグメントに適した重複しない CIDR ブロックを決定します。
グローバル ルート管理者 API サーバーにグローバル サブネットを作成する: 定義された CIDR を使用して、グローバル ルート管理者 API サーバーの組織の Namespace に
Subnetリソース（infra-vpc-root-cidr、admin-external-root-cidr、data-external-root-cidr）を作成します。ゾーンのルート サブネットを分割する: これらのグローバル ルート サブネットは、各ゾーンで使用するために、自動または手動でより小さなサブネットに分割されます。
- 自動分割: デフォルトでは、コントローラはグローバル ルート サブネットを自動的に分割します。
- 手動分割: ゾーン CIDR 割り当てを手動で制御する必要がある場合は、
Subnetリソースにipam.gdc.goog/pause-auto-division: trueアノテーションを設定し、ゾーン サブネットを手動で定義します。
これらのサブネットと組織の作成の詳細な手順については、顧客組織を作成するをご覧ください。
要件収集テンプレート
このセクションでは、ゾーンと組織の両方のブートストラップでインフラストラクチャ オペレーター（IO）が収集する必要がある IP アドレス指定情報のテンプレートを提供します。
ゾーンのブートストラップ
ゾーン ブートストラップを開始する前に、IO に次の IP アドレス AttachmentGroup が必要です。
| サブネットの詳細 | サブネットのサイズ設定 | 備考/制限 | ||
|---|---|---|---|---|
| 名前 | IPv6 Supp. | 最小 | Rec | |
OOBMgmtCIDR省略可 展開可能 |
いいえ | /19 ゾーンあたり |
- | 単一のゾーンで使用 ユニバース内のすべてのゾーンで一意である必要があります 外部でピアリングされたネットワーク間で一意である必要があります グローバルに予約され、どの組織でも使用できなくなります |
ZoneInfraCIDR省略可 1.14 では拡張不可 |
○ | /16 /ゾーン |
- | 単一のゾーンで使用される ユニバース内のすべてのゾーンで一意である 外部でピアリングされたネットワーク間で一意である グローバルに予約され、どの組織でも使用できなくなる 指定しない場合、デフォルトは 172.17+{zoneID}.0/16 |
ZoneInfraAnycastCIDR必須 展開可能 |
○ | /24 ユニバースあたり |
- | すべてのゾーンで使用される ユニバース内のすべてのゾーンで一意でなければなりません 外部でピアリングされたネットワーク間で一意でなければなりません グローバルに予約され、どの組織でも使用できなくなります |
組織のブートストラップ
組織のプロビジョニングを開始する前に、IO はオンボーディング PA と協力して、次の IP アドレス情報を計画する必要があります。
| サブネットの詳細 | サブネットのサイズ設定 | 備考/制限 | ||
|---|---|---|---|---|
| 名前 | IPv6 Supp. | 最小 | Rec | |
defaultVPCCIDR必須 展開可能 |
○ | /16 （ゾーンあたり） | /16 （ゾーンあたり） | 複数のゾーンで使用される すべてのゾーンでグローバル組織内で一意である 他の組織間で常に重複する可能性がある グローバルに予約されたサブネットを使用しない |
infraVPCCIDR必須 展開可能 |
○ | /16 （ゾーンあたり） | /16 （ゾーンあたり） | 複数のゾーンで使用される すべてのゾーンでグローバル組織内で一意である 他の組織間で常に重複する可能性がある グローバルに予約されたサブネットを使用しない |
orgAdminExternalCIDR必須 展開可能 |
○ | /26（ゾーンごと） | /26（ゾーンごと） | グローバルに予約されたサブネット 単一ゾーンで使用 グローバル組織内のすべてのゾーンで一意 外部ピアリング ネットワーク間で一意 グローバルに予約されたサブネットは使用しない |
orgAdminAnycastCIDR必須 展開可能 |
○ | /28 per universe | /28 per universe | グローバルに予約されたサブネットを使用してはなりません。複数のゾーンで使用される グローバル組織内のすべてのゾーンで一意である必要があります。外部ピアリングされたネットワーク間で一意である必要があります。グローバルに予約されたサブネットを使用してはなりません。 |
orgDataExternalCIDR必須 展開可能 |
○ | /26 ゾーンあたり | /23 ゾーンあたり | グローバルに予約されたサブネットを使用してはなりません。単一ゾーンで使用されます。 グローバル組織内のすべてのゾーンで一意である必要があります。 外部ピアリング ネットワーク間で一意である必要があります。 グローバルに予約されたサブネットを使用してはなりません。 |
orgDataAnycastCIDR必須 展開可能 |
○ | /28 per universe | ユニバースあたり/26 | グローバルに予約されたサブネットを使用してはなりません 複数のゾーンで使用 グローバル組織内のすべてのゾーンで一意である必要があります 外部ピアリングされたネットワーク間で一意である必要があります グローバルに予約されたサブネットを使用してはなりません |
例
次の図は、このドキュメントで説明した IP アドレス プランニングのコンセプトが、一般的な GDC エアギャップ シナリオにどのように適用されるかを示しています。
例 1: ゾーンのブートストラップ
例 2: 共有インターコネクトを使用した組織のオンボーディング
例 3: 専用相互接続を使用した組織のオンボーディング
主なコンセプトとベスト プラクティス
- VRF 分離: VRF は、GDC エアギャップのネットワーク セグメンテーションに不可欠です。各 VRF（Zone Infra、Org Infra、Org Admin、Org Data など）の目的を理解して、必要な分離境界を維持する IP アドレス空間を計画します。
- 重複する IP と重複しない IP:
- GDCag インフラストラクチャ アドレス空間（IO 管理）: GDC エアギャップ デプロイ全体（すべてのゾーン、すべての組織）でグローバルに一意である必要があります。このアドレス空間は基本的にグローバルに予約されます。
- 組織のアドレス空間（PA 管理/定義）:
- VPC ネットワーク（インフラストラクチャ VPC、デフォルト VPC）: 異なる組織間で重複できますが、組織内のすべてのゾーンで一意であり、ピアリングするネットワークと重複しないようにする必要があります。
- 組織管理者/データ VRF: 異なる組織が別々の Interconnect アタッチメント グループを使用している場合、異なる組織間で重複する可能性があります。アタッチメント グループを共有する場合、IP アドレスは一意である必要があります。すべてのゾーンで同じ組織内で一意であり、ピアリングするネットワークと異なる必要があります。
- 推奨される CIDR サイズ: 各ネットワーク セグメントに指定された推奨 CIDR プレフィックス長に準拠して、システム コンポーネントと将来の拡張に十分なアドレス空間を確保します。
- RFC 1918 の優先度: ゾーンがインターネットに接続されていない場合、ほとんどの PA 管理スペースでパブリック IP アドレスを使用できますが、一般的に、内部 GDC エアギャップ ネットワークには RFC 1918 プライベート アドレスが推奨されます。
- OIQ の精度: CIQ（IO の場合）と OIQ（PA から IO の場合）で提供される情報は非常に重要です。IP アドレス範囲が不正確であったり、計画が不十分であったりすると、デプロイに大きな問題が生じる可能性があります。
- マルチゾーン:
- IO の場合: ゾーン インフラストラクチャ VRF はゾーンごとです。
- PA の場合: 組織の VPC（インフラストラクチャとデフォルト）、組織の管理者と組織のデータ ネットワーク セグメントは、概念的には組織全体にわたりますが、そのグローバル組織内で重複しないゾーンごとに一意の IP 割り当てが必要です。グローバル サブネットは、特定の組織のゾーンごとに一意の範囲を提供するように分割されます。
サポート、診断、トラブルシューティング、よくある質問
- よくある間違い:
- CIDR ブロックのサイズが不十分で、IP アドレスが枯渇する。
- 一意性が求められる IP 範囲の重複。たとえば、IO 管理のインフラストラクチャ ネットワークや、単一の組織の VPC 内、ゾーン間の外部 VRF などです。
- 特定の IP 範囲の計画を担当するエンティティ（IO と PA）の誤解。
zone-infra-cidrまたはピアリングされたネットワークと競合する CIDR 範囲。
- 検証（概要）:
- IO: ルート管理クラスタの
CIDRClaimリソースと、グローバル ルート管理 API サーバーのSubnetリソースを検証できます。 - PA: IO と連携して、組織のインフラストラクチャと VPC に割り当てられた IP 範囲を把握できます。デフォルト VPC の
Subnetリソースは、グローバル組織 API サーバーで確認できます。
- IO: ルート管理クラスタの
- よくある質問:
- Q: デプロイ後に IP CIDR を変更できますか？
- A: デプロイ後にコア インフラストラクチャの IP 範囲を変更するのは複雑で、多大な労力や再デプロイが必要になる場合があります。顧客向け CIDR（デフォルト VPC、組織管理者、組織データ ネットワーク セグメントなど）は、作成後に変更できるように設計されていますが、変更には慎重な計画と調整が必要です。
- Q: アプリケーションのロードバランサまたは下り（外向き）NAT の IP はどこで定義しますか？
- A: 通常、これらは組織データ VRF CIDR から割り当てられます。これは PA によって計画され、組織の作成時に IO に提供されます。
- Q:
zone-infra-cidrとは何ですか？また、OIQ CIDR がzone-infra-cidrと重複できないのはなぜですか？- A:
zone-infra-cidrは、ゾーンの内部インフラストラクチャ コンポーネントの基盤となる IP 範囲です。重複すると、ルーティングの競合と不安定性が生じます。
- A:
- Q: デプロイ後に IP CIDR を変更できますか？
組織の作成とサブネットの構成に関する詳細な手順については、顧客組織の作成に関するドキュメントを参照してください。