このリファレンス アーキテクチャは、Google Distributed Cloud（GDC）エアギャップで、お客様が管理するレイヤ 7 ロード バランシング ソリューションを提供します。HAProxy Kubernetes Ingress や NGINX Gateway Fabric などの一般的なオープンソース コントローラを GDC 標準クラスタにデプロイすることで、L7 トラフィックをハイブリッド環境にシームレスにルーティングできます。このアーキテクチャでは、TLS 終端（Ingress / HTTPRoute）を使用して、Server Name Indication（SNI）に基づいて、組み込みのコンテナ化された Pod と外部仮想マシンでホストされているアプリケーションの両方にトラフィックをルーティングします。
特長と機能
- 高度なレイヤ 7 ルーティング: ホストベースのルーティング、パスベースのルーティング、ヘッダーベースのマッチングやトラフィックの重み付けなどの高度なトラフィック管理をサポートします。
- 一元化された TLS 管理: 一元化された TLS 管理と終端を提供します。
- ハイブリッド環境のサポート: 組み込みのコンテナ化された Pod と外部仮想マシンでホストされているアプリケーションの両方に L7 トラフィックをシームレスにルーティングします。
- 柔軟なコントローラ オプション: 最新の NGINX Gateway Fabric（Gateway API を使用）または実績のある HAProxy Ingress Controller のいずれかを選択できます。
- エアギャップ対応: Harbor Registry と統合され、切断されたプライベート環境内でプロキシ イメージとアプリケーション イメージを保存して提供します。
- 複雑なトラフィック分割: 最新のアプリケーションの配信のための高度なトラフィック分散戦略を可能にします。
アーキテクチャの原則
- 2 層ロード バランシング パターン: このアーキテクチャは、GDC の組み込み L4 ロードバランサ（エントリ ポイントとして）と、Kubernetes 内にデプロイされたお客様管理の L7 ゲートウェイを組み合わせたものです。
- ロール指向の分離: 特定のリソース（
GatewayClass、Gateway、HTTPRoute、Ingressなど）を介して、インフラストラクチャ プロバイダ、クラスタ オペレーター、デベロッパーの間で責任を分離する設計に従います。 - 最新の標準への移行: このアーキテクチャでは、最新のルーティング機能に Gateway API を優先的に使用しますが、特定のコントローラの安定性が必要な場合は、以前の Ingress API のサポートも維持します。
- お客様が管理する柔軟性: セルフマネージド コントローラをデプロイすることで、GDC マネージド L4 ロードバランサでネイティブに提供されていない L7 機能と構成を制御できます。
- ワークロードの場所の抽象化: このアーキテクチャでは、Kubernetes Service の抽象化（標準またはヘッドレス）を通じて、コンテナ化されたワークロードと VM ベースのワークロードを一貫して処理します。
概念アーキテクチャ
論理アーキテクチャ
論理アーキテクチャは、外部トラフィックを内部バックエンドまたは外部バックエンドにルーティングするために連携する複数の機能コンポーネントで構成されています。
- Ingress / Gateway エントリ ポイント: クライアントが HTTPS リクエストを開始し、最初に GDC L4 ロードバランサに到達します。この組み込みバランサはエントリ ポイントとして機能し、TCP/443 トラフィックを L7 ロードバランサに分散します。
- コントロール プレーン: Ingress または Gateway Controller（HAProxy または NGINX オペレーター）は、
Ingress、Gateway、HTTPRouteなどの Kubernetes リソースをモニタリングします。 - データプレーン: 監視対象のリソースに基づいて、コントローラは、SNI ベースのホスト ルーティング ルールと TLS 終端に基づいて実際のトラフィック ルーティングを実行する基盤となるプロキシを動的に更新します。
- バックエンド サービス:
- コンテナ化された Pod: 標準の Deployment として管理され、通常の Kubernetes Service で公開されます。
- 外部 VM: ヘッドレス Kubernetes Service と、VM の直接 IP を含むカスタム エンドポイント（または
EndpointSlice）を使用してクラスタに統合されます。
- アーティファクト管理: プロキシとアプリケーションのすべてのイメージは、ローカルの Harbor Registry から提供され、エアギャップ環境での機能が保証されます。
基本コンセプトとテクノロジー
このアーキテクチャでは、GDC の組み込み L4 ロードバランサと、Kubernetes にデプロイされたお客様管理の L7 Gateway を組み合わせた 2 層のロード バランシング パターンを使用します。主なコンポーネントは次のとおりです。
- クライアント: アプリケーションとやり取りするために HTTPS リクエストを開始するエンティティ。
- GDC 標準クラスタ: GDC には、Kubernetes Vanilla クラスタを作成するための組み込みの方法が用意されています。このソリューションでは、クラスタは L7 LB とそのコントローラ、ワークロード、外部 VM のヘッドレス サービスをホストします。
- GDC L4 ロードバランサ: エントリ ポイントとして機能する組み込みの L4 ロードバランサ。TCP/443 トラフィックを Ingress コントローラまたは Gateway コントローラを実行している Kubernetes Pod に直接分散します。
- Ingress コントローラと Gateway コントローラ: Standard クラスタで実行されている HAProxy または NGINX オペレーター。Nginx の場合、Gateway API リソース（
GatewayやHTTPRouteなど）をモニタリングし、基盤となるプロキシを動的に更新します。HAProxy の場合、Ingressリソースをモニタリングし、基盤となるプロキシを動的に更新します。- HAProxy Ingress Controller: HAProxy をリバース プロキシおよびレイヤ 7 ロードバランサとして利用する Kubernetes 用の Ingress コントローラ。TLS 終端も処理します。
- Nginx Gateway Fabric: NGINX をデータプレーンとして使用する Gateway API の実装。
- Ingress と Gateway（HTTPRoute を使用）: 物理リスニング ポート（443）と TLS 終端を使用した SNI ベースのホスト ルーティング ルールを定義する標準化された Kubernetes リソース。
- コンテナ化されたワークロード（Pod）: 標準の Kubernetes
Serviceを使用して内部的に公開される標準の Kubernetes Deployment。 - VM ベースのワークロード（外部）: プロジェクト ネットワーク上の外部 VM でホストされるワークロード。ヘッドレス Kubernetes
Serviceと VM の直接 IP を含むカスタム エンドポイントを使用してプロキシに公開されます。 - Harbor Registry: エアギャップ環境でプロキシ イメージとアプリケーション イメージを保存して提供するために使用される非公開 Container Registry。
Ingress と Gateway API
Kubernetes ネットワーキング環境は、従来の Ingress API から最新の Gateway API に移行しています。この 2 つの違いを理解することは、ワークロードに適したアーキテクチャを選択するうえで重要です。
Ingress API: これまで、Ingress は HTTP サービスへの外部アクセスを管理するための標準でした。ホストベースとパスベースのルーティングを提供しますが、その設計は比較的基本的であり、ベンダー固有のアノテーションに依存せずに高度なトラフィック管理（ヘッダーベースのマッチングやトラフィックの重み付けなど）を組み込みでサポートしていません。重要な点として、Ingress API は Kubernetes コミュニティによって機能が凍結されたと見なされています（Ingress の制限と Kubernetes ネットワーキングの進化）。
Gateway API: Ingress の V2 と呼ばれることが多い Gateway API は、サービス ネットワーキングに、より堅牢で拡張可能なモデルを提供するカスタム リソース定義（CRD）のコレクションです。これは、インフラストラクチャ プロバイダ（
GatewayClass）、クラスタ オペレーター（Gateway）、デベロッパー（HTTPRoute/TLSRoute）の間で責任を分離するロール指向になるように設計されています（GKE の Gateway API）。この分離により、よりきめ細かい制御とマルチテナンシーのサポートが可能になります。
この GDC エアギャップ ソリューションでは、2 つの主要なコントローラに異なる API を意図的に選択しています。
- NGINX（Gateway API）: NGINX の実装には、Gateway API の成熟した組み込み実装である NGINX Gateway Fabric を使用します。NGINX で Gateway API を活用すると、API に組み込まれている最新の標準と高度なルーティング機能（
HTTPRouteなど）を利用できます。 - HAProxy（Ingress API）: Gateway API は戦略的な方向性ですが、このガイドでは HAProxy に Ingress API を選択しています。これは、HAProxy の Gateway API 統合が成熟していないためです。実績のある HAProxy Ingress Controller を使用することで、HAProxy を好むお客様に安定性と信頼性に優れた L7 ソリューションを提供しつつ、最新の L7 機能へのパスも提供します。
前提条件と制約
前提条件
- インフラストラクチャの準備状況: このデプロイでは、GDC エアギャップ 1.15.x 標準クラスタが利用可能であることを前提としています。
- ローカル レジストリ: ローカルの Harbor Registry が、エアギャップ環境でプロキシ イメージとアプリケーション イメージを保存して提供するように正しく構成されていることを前提としています。
- ネイティブ エントリ ポイント: トラフィックは、まず組み込みの GDC L4 ロードバランサにヒットし、その後 L7 プロキシに分散されると想定されます。
制約
- お客様管理のソリューション: GDC には、SLA で保証されたマネージド L7 サービスはありません。この実装は、お客様が完全にセルフマネージドで行います。
- Standard クラスタのみ: 共有ユーザー クラスタは、Ingress と Gateway Controller のデプロイに必要な高い権限が必要なため、対象外です。
- API の成熟度: NGINX は最新の Gateway API を使用しますが、HAProxy は Gateway API の統合がまだ成熟していないため、Ingress API に制限されています。
- エアギャップ メンテナンス: すべてのコンテナ イメージは、ローカルの Harbor レジストリ内で手動でプロモートして管理する必要があります。
- コミュニティ エディション: このアーキテクチャは、Nginx と HAProxy のオープンソース コミュニティ エディション向けに設計されています。Enterprise エディションは動作する可能性がありますが、明示的なテストは行われていません。
- 運用の所有権: お客様は、サードパーティ コントローラの独自のスケーリング、高可用性、パッチ適用を管理する必要があります。
- サポート範囲: Google サポートの対象は、基盤となる GDC インフラストラクチャのみです。HAProxy または NGINX ソフトウェア自体の問題は、お客様またはベンダーの責任となります。
- API の陳腐化: Ingress API（HAProxy で使用）は、Kubernetes コミュニティによって機能が凍結されているため、将来のルーティング機能が制限される可能性があります。
ライセンス
- コミュニティ エディション: このアーキテクチャは、オープンソースのコミュニティ エディション（通常は Apache 2.0 または同様のもの）向けに設計されています。これらのエディションは無料で使用できますが、お客様が管理する必要があります。
- エンタープライズ調達: NGINX Plus や HAProxy Enterprise などの商用ライセンスの調達と管理は、お客様の責任となります。