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