単一プロジェクト内の複数の GKE クラスタで同じアドレス空間を再利用する
Naveen Mandadhi
Strategic Cloud Engineer
Adam Cole
Strategic Cloud Engineer
※この投稿は米国時間 2024 年 5 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Kubernetes Engine（GKE）のメリットの一つは、完全に統合されたネットワーク モデルを使用できることです。つまり、Pod アドレスを VPC ネットワーク内でルーティングできます。しかし、GKE を組織全体で使用するようになると、単一の VPC でネットワーク空間を割り当てるのは難しくなり、IP アドレスは急速に枯渇していきます。組織に複数の GKE クラスタが必要な場合、VPC ネットワーク内のクラスタに十分に足りる一意の IP 範囲を予約できるようにネットワークを慎重に計画するのは、骨の折れる作業になります。
次の設計を使用すると、GKE クラスタ全体で IP 空間を完全に再利用できます。このブログ投稿では、Private Service Connect を利用して GKE クラスタ範囲を非表示にしたまま、ネットワーク アプライアンス ルーターとして機能するマルチ NIC VM を使用して、ネットワーク同士を接続するアーキテクチャを紹介します。これにより、GKE クラスタ ネットワークは非表示でも接続された状態になり、複数のクラスタでアドレス空間を再利用できるようになります。
アーキテクチャ
プラットフォーム コンポーネント:
-
各クラスタは、アイランド VPC 内に作成されます。
-
既存のネットワークとアイランド ネットワーク間の接続を可能にするために、複数の NIC を備えた VM ルーターが使用されます。
-
サンプルコードではルーターとして単一の VM を使用していますが、これをマネージド インスタンス グループ（MIG）に拡張して高可用性アーキテクチャにすることもできます。
サービスの接続:
-
受信接続の場合、GKE にデプロイされたサービスは、Private Service Connect エンドポイントを通じて公開されます。このためには、エンタープライズ ネットワーク内の静的内部 IP アドレスを予約し、DNS エントリを作成してルーティングを有効にする必要があります。
-
クラスタからの送信接続の場合、すべてのトラフィックは、ネットワーク アプライアンスを介してエンタープライズ ネットワークにルーティングされます。
使ってみる
1. 基本的なインフラストラクチャをデプロイする以下の公開されている Terraform コードを使用して、ネットワークの初期構成と GKE クラスタ構成をプロビジョニングできます。README に従って、クラスタをデプロイし、必要に応じてクラスタの IP アドレスを調整します。
2. GKE でサービスを公開するPSC サービス アタッチメントに新しいサブネットを作成します。このサブネットは、GKE クラスタと同じリージョンに、--purpose PRIVATE_SERVICE_CONNECT を使用して作成する必要があります。このコードで PSC サブネットも作成されます。必要に応じて CIDR を調整できます。
次に、GKE にサンプル ワークロードをデプロイします。
ここで、内部パススルー ネットワーク ロードバランサを使用して Deployment を公開します。
ロードバランサの ServiceAttachment を作成します。
3. PSC エンドポイントを接続する
ServiceAttachment の URL を取得します。
この URL を使用して、接続された VPC ネットワークに Private Service Connect エンドポイントを作成します。
4. アクセスをテストする
接続されたネットワークから、curl を使用してサービスにアクセスできます。
制限事項
この設計には以下の制限事項があります。
-
これは、プロジェクトあたりの VPC ネットワーク数に関する割り当ての対象となります。この数は、コマンド gcloud compute project-info describe --project PROJECT_ID を使用して確認できます。
-
Private Service Connect の制限事項が適用されます。
-
サービス アタッチメントは、GKE バージョン 1.21.4-gke.300 以降で作成できます。
-
複数サービスのアタッチメント構成で同じサブネットを使用することはできません。
-
このブログ投稿の執筆時点では、PSC を使用するには、内部パススルー ネットワーク ロードバランサを使用する GKE サービスを作成する必要があります。
このような制限により、上記で作成した Google Cloud リソース（サブネット、内部パススルー ネットワーク ロードバランサ、サービス アタッチメント、PSC エンドポイント）は、公開する GKE サービスごとにデプロイする必要があります。
この設計は、単一のプロジェクト内の複数のクラスタに同じアドレス空間を再利用することで、GKE クラスタの IP アドレス空間を節約したいと考えている企業に最適です。
この設計では、これらの Google Cloud リソースをすべての GKE サービスにデプロイする必要があるため、Ingress ゲートウェイ（Istio サービス メッシュや Nginx など）を使用して、必要なエントリポイントを GKE に統合することを検討してください。
その他のリソース
このトピックについてさらに詳しく知るには、以下のリンクをご覧ください。
-
ドキュメント: GKE のネットワーク モデル
- ドキュメント: Private Service Connect を使用してサービスを公開する
ー 戦略的クラウド エンジニア Naveen Mandadhi
ー 戦略的クラウド エンジニア Adam Cole
