このページでは、GKE Gateway Controller を使用した、Kubernetes Gateway API の Google Kubernetes Engine（GKE）実装について説明します。
Gateway API は、サービス ネットワーキング用のオープンソース標準です。Gateway API は、Ingress リソースを進化させ、次の方法で改善します。
ロール指向: Gateway は、クラスタ オペレータ、デベロッパー、インフラストラクチャ プロバイダの組織のロールに対応する API リソースで構成されます。これにより、クラスタ オペレータは、異なる個別のデベロッパー チームによる共有インフラストラクチャの使用方法を定義できます。
ポータビリティ: Gateway API は多くの実装を備えたオープンソース標準です。適合性に優れ、環境や実装のネイティブ機能をサポートする柔軟性と拡張性を備えた設計になっているため、Ingress のように移植性の高いコア API として使用できます。実装と環境全体でコンセプトとコアリソースの整合性が維持されるため、複雑さを軽減し、使いやすさを向上させることができます。
豊富な機能: Gateway API リソースを使用すると、Ingress ではカスタム アノテーションが必要になるヘッダーベースの照合やトラフィックの重み付けなどを組み込み機能で実現できます。
Gateway API リソース
Gateway API はロールベースのリソースモデルであり、Kubernetes ネットワーキングとやり取りするペルソナ向けに設計されています。次の図に示すように、このモデルでは、調整していないさまざまなサービス オーナーが、プラットフォーム管理者のポリシーと制御を一元化し、基盤となる管理者と同じネットワーク インフラストラクチャを安全に共有できます。
Gateway API には次のリソースタイプがあります。
- GatewayClass: クラスタ スコープ リソースを定義します。これは、クラスタにロードバランサを作成する際のテンプレートになります。GKE は、GKE クラスタで使用できる GatewacyClass を提供します。
- Gateway: ロードバランサがトラフィックをリッスンする場所と方法を定義します。クラスタ オペレータは GatewayClass に基づいてクラスタに Gateway を作成します。GKE は、Gateway リソースで定義された構成を実装するロードバランサを作成します。
- HTTPRoute: Gateway から Kubernetes Services にリクエストをルーティングするためのプロトコル固有のルールを定義します。GKE は、HTTP(S) ベースのトラフィック ルーティング用の HTTPRoutes をサポートしています。アプリケーション デベロッパーは HTTPRoute を作成し、Gateway を使用して HTTP アプリケーションを公開します。
- Policy: Gateway リソースの実装固有の一連の特性を定義します。ポリシーは、Gateway、Route、または Kubernetes Service に接続できます。
GatewayClass
GatewayClass は、Kubernetes クラスタ内の HTTP(S)（レベル 7）ロードバランサのテンプレートを定義するリソースです。GKE は、クラスタ スコープ リソースとして GatewayClasses を提供します。クラスタ オペレータは、クラスタで Gateway を作成する際に GatewayClass を指定します。
GatewayClass によって対応する Google Cloud ロードバランサが異なります。GatewayClass を使用して Gateway を作成すると、対応するロードバランサが作成され、指定した構成が実装されます。
一部の GatewayClass はマルチクラスタ ロード バランシングをサポートしています。
次の表に、GKE クラスタで使用可能な GatewayClass と、その基になるロードバランサ タイプを示します。GatewayClass の詳細については、GatewayClass の機能と仕様をご覧ください。
| GatewayClass の名前 | 説明 |
|---|---|
gke-l7-global-external-managed |
グローバル外部アプリケーション ロードバランサ上にビルドされたグローバル外部アプリケーション ロードバランサ |
gke-l7-regional-external-managed |
リージョン外部アプリケーション ロードバランサ上にビルドされたリージョン外部アプリケーション ロードバランサ |
gke-l7-rilb |
内部アプリケーション ロードバランサ上にビルドされた内部アプリケーション ロードバランサ |
gke-l7-gxlb |
従来のアプリケーション ロードバランサ上にビルドされたグローバル外部アプリケーション ロードバランサ |
gke-l7-global-external-managed-mc |
グローバル外部アプリケーション ロードバランサ上にビルドされたマルチクラスタ グローバル外部アプリケーション ロードバランサ |
gke-l7-regional-external-managed-mc |
グローバル外部アプリケーション ロードバランサ上にビルドされたマルチクラスタ リージョン外部アプリケーション ロードバランサ |
gke-l7-rilb-mc |
内部アプリケーション ロードバランサ上にビルドされたマルチクラスタ内部アプリケーション ロードバランサ |
gke-l7-gxlb-mc |
従来のアプリケーション ロードバランサ上にビルドされたマルチクラスタ グローバル外部アプリケーション ロードバランサ |
gke-td |
マルチクラスタの Traffic Director サービス メッシュ |
asm-l7-gxlb |
Anthos Service Mesh 上にビルドされたグローバル外部アプリケーション ロードバランサ |
GatewayClass には、基盤となるロードバランサの制限が適用されます。
Gateway
クラスタ オペレータは Gateway を作成して、ロードバランサがトラフィックをリッスンする場所と方法を定義します。Gateway は、関連付けられている GatewayClass から動作（つまり、どのように実装されるか）を引き継ぎます。
Gateway の仕様には、Gateway の GatewayClass、リッスンするポートとプロトコル、Gateway にバインドできるルートを定義します。Gateway は Route メタデータ（Route リソースの種類、Namespace、ラベルなど）に基づいてルートを選択します。
Gateway のデプロイ例については、Gateway のデプロイをご覧ください。
マルチクラスタ Gateway のデプロイ例については、マルチクラスタ Gateway のデプロイをご覧ください。
HTTPRoute
HTTPRoute では、Gateway が受信した HTTP リクエストと HTTPS リクエストを Service に転送する方法を定義します。アプリケーション デベロッパーは HTTPRoute を作成し、Gateway を使用してアプリケーションを公開します。
HTTPRoute では、トラフィックのルーティング先となる Gateway、ルーティング先の Service、HTTPRoute のトラフィック照合ルールを定義します。Gateway と Route のバインディングは双方向です。つまり、両方のリソースをバインドするには、お互いのリソースを選択する必要があります。HTTPRoute は、リクエスト ヘッダーの詳細に基づいてリクエストを照合できます。
Policy
Policy は、クラスタ オペレーターが Gateway、Route、Kubernetes Service に接続できる Gateway リソースの特性を定義します。通常は実装に固有のものです。Policy は、基盤となる Google Cloud インフラストラクチャがどのように機能するかを定義します。
通常、Policy は Namespace に接続され、同じ Namespace 内のリソースを参照できます。また、RBAC を使用してアクセス権が付与されます。Gateway API は階層的な性質を持つため、Namespace 内のトップレベルのリソース（Gateway）にポリシーを接続し、異なる Namespace の下のすべてのリソースにポリシーの特性を適用できます。
GKE Gateway Controller は、次のポリシーをサポートしています。
HealthCheckPolicy: バックエンド Pod のヘルス ステータスの確認に使用されるヘルスチェックのパラメータと動作を定義します。GCPGatewayPolicy: Google Cloud ロードバランサ フロントエンドの特定のパラメータを定義します。これは、Ingress リソースのFrontendConfigに似ています。GCPBackendPolicy: ロードバランサのバックエンド サービスがエンドポイントにトラフィックをどのように分散するかを定義します。これは、Ingress リソースのBackendConfigに似ています。
Gateway のオーナー権限と使用パターン
Gateway と Route のリソースは、組織内での所有とデプロイに柔軟性を提供します。つまり、インフラストラクチャ チームは単一のロードバランサをデプロイし、管理できますが、特定のドメインまたはパスの下のルーティングは、別の Kubernetes Namespace の別のチームに委任できます。GKE Gateway コントローラは、Namespace、クラスタ、リージョン間で共有されるロードバランサのマルチテナント使用をサポートします。また、分散オーナー権限がさらに必要な場合は、Gateway を共有する必要はありません。GKE の Gateway の一般的な使用パターンの一部を次に示します。
セルフマネージド Gateway
1 人のオーナーが、アプリケーション用に Gateway と Route をデプロイし、排他的に使用できます。この方法でデプロイされた Gateway と Route は Ingress と似ています。次の図は、独自の Gateway をデプロイして管理する 2 人の異なるサービス オーナーを示しています。Ingress と同様に、各 Gateway は固有の IP アドレスとロードバランサに対応しています。TLS、ルーティングなどのポリシーはサービス オーナーによって完全に制御されます。
この使用パターンは Ingress では一般的ですが、共有リソースがないため、多くのチームでスケーリングが困難です。Gateway API のリソースモデルは、分散制御とオーナー権限のさまざまなオプションを提供する以下の使用パターンを可能にします。
Namespace ごとのプラットフォーム マネージド Gateway
Gateway と Route のリソースを分離することで、プラットフォーム管理者はサービス オーナーに代わって Gateway を制御できます。プラットフォーム管理者は、Namespace またはチームごとに Gateway をデプロイし、その Namespace に Gateway を使用するための排他的アクセス権を付与できます。これにより、サービス オーナーは、他のチームとの競合のリスクなしに、ルーティング ルールを完全に制御できます。これにより、プラットフォーム管理者は、IP 割り振り、ポート公開、プロトコル、ドメイン、TLS などのアスペクトを制御できます。プラットフォーム管理者は、チームが使用できる Gateway の種類（内部 Gateway や外部 Gateway など）を決定することもできます。この使用パターンにより、ロール間の責任が明確に分離されます。
Namespace をまたがるルーティングにより、ルートが Namespace の境界を超えて Gateway に接続できるようになります。Gateway は、ルートが接続できる Namespace を制限できます。同様に、ルートは、接続する Gateway を指定しますが、接続できるのはルートの Namespace を許可している Gateway だけです。この双方向のアタッチメントは、多様な使用パターンを可能にする柔軟な制御を各側に提供します。
次の図では、プラットフォーム管理者が各 Namespace に排他的にアクセスできる Gateway をデプロイしています。たとえば、store Gateway は、store Namespace からの Route のみが接続できるように構成されています。各 Gateway は一意のロード バランシングされた IP アドレスを表すため、各チームは、選択したドメインまたはルートに対して、Gateway に任意の数の Route をデプロイできます。
クラスタごとの共有 Gateway
Namespace 間で Gateway を共有すると、プラットフォーム管理者にさらに一元化されたオーナー権限が提供されます。これにより、異なる Namespace で実行している異なるサービス オーナーが、同じ IP アドレス、DNS ドメイン、証明書、パスを共有し、サービス間のきめ細かいルーティングを行うことができます。Gateway は、Namespace を特定のドメインにルーティングできるプラットフォーム管理者に制御を提供します。これは前の例と似ていますが、Gateway は複数の Namespace からの Route アタッチメントを許可する点が異なります。
次の図では、プラットフォーム管理者が 2 つの Gateway を infra Namespace にデプロイしています。external Gateway は、web Namespace と mobile Namespace からの Route を Gateway に接続できます。accounts Namespace からの Route では、external Gateway を使用できません。これは、accounts Namespace は内部サービス専用であるためです。internal Gateway を使用すると、内部クライアントは、プライベート IP アドレスを使用して VPC 内で限定公開で通信できます。
m.example.com ドメインは mobile Namespace に委任され、モバイル サービス オーナーは m.example.com ドメインで必要なルーティング ルールを構成できます。これにより、サービス オーナーは、管理者に変更を要求せずに、新しい API エンドポイントを導入し、トラフィックを制御するための高度な制御が可能になります。
フリートごとの共有 Gateway
マルチクラスタ Gateway を使用すると、Gateway を両方の Namespace、クラスタ、リージョンで共有できます。地理的に分散したアプリを持つ大規模な組織は、ルーティングのオーナー権限を委任しながらグローバル トラフィックをきめ細かく制御できるため、マルチクラスタ Gateway が役立つ場合があります。前の例と同様に、プラットフォーム管理者は Gateway を管理し、ルーティングを委任します。このユースケースでの主な追加点は、Route がクラスタ間でデプロイされるマルチクラスタ Service を参照することです。トラフィックは明示的な方法でルーティングされるか、store.example.com/us へのトラフィックは gke-us Pod に送信されるか、または example.com/* へのトラフィックはクライアントに最も近いクラスタに明示的な方法でルーティングされます。この柔軟性により、サービス オーナーはアプリケーションに最適なルーティング戦略を定義できます。
GKE Gateway コントローラ
GKE Gateway コントローラは、Google が Cloud Load Balancing に実装した Gateway API です。GKE Ingress コントローラと同様に、Gateway コントローラは Gateway API リソースの Kubernetes API を監視し、Cloud Load Balancing リソースを調整して、Gateway リソースで指定されたネットワーク動作を実装します。
GKE Gateway コントローラには 2 つのバージョンがあります。
- 単一クラスタ: 単一の GKE クラスタの単一クラスタ Gateway を管理します。
- マルチクラスタ: 1 つ以上の GKE クラスタのマルチクラスタ Gateway を管理します。
どちらの Gateway コントローラも Google がホストするコントローラで、GKE クラスタの Kubernetes API を監視します。GKE Ingress コントローラとは異なり、Gateway コントローラは GKE コントロール プレーンまたはユーザー プロジェクトでホストされないため、スケーラビリティと堅牢性が向上します。どちらの Gateway コントローラも一般提供されています。
Gateway コントローラ自体はネットワーク データプレーンではなく、トラフィックは処理されません。トラフィックから帯域外で、トラフィックを処理するさまざまなデータプレーンを管理します。次の図は、単一クラスタと複数クラスタの GKE Gateway コントローラのアーキテクチャを示しています。使用される基礎となるコントローラは、デプロイされた Gateway の GatewayClass によって異なります。
| コントローラ | 単一クラスタ Gateway コントローラ | 複数クラスタ Gateway コントローラ |
|---|---|---|
| 管理者 | Google Cloud | Google Cloud |
| クラスタのスコープ | 単一クラスタ Gateway | 複数クラスタ Gateway |
| デプロイする場所 | GKE クラスタと同じリージョンにデプロイされます。 | 複数の Google Cloud リージョンにグローバルにデプロイされます。 |
| 有効にする方法 | GKE では、デフォルトで有効になっています。 | マルチクラスタ Ingress API を使用して有効にし、フリートに登録します。マルチクラスタ Gateway の有効化をご覧ください。 |
| サポートされている GatewayClass |
GKE クラスタでは、複数の Gateway コントローラ（Google が提供していないコントローラも含む）を同時に使用できます。どの GatewayClass も 1 つの Gateway コントローラのみでサポートされているため、単一クラスタとマルチクラスタのロード バランシングを同時に使用できます。
Ingress と Gateway
Ingress と Gateway の比較
Gateway と Ingress はどちらもトラフィックのルーティングに使用されるオープンソース標準です。Gateway は Kubernetes コミュニティによって設計され、Ingress とサービス メッシュのエコシステムから得られた知見を活用しています。Gateway は、同じ機能を提供する Ingress の進化であり、Ingress 機能のスーパーセットとして機能します。どちらも競合なく同時に使用できますが、時間の経過とともに Gateway リソースと Route リソースで Ingress に提供されない機能が増えるため、Ingress を使用しているユーザーも Gateway に切り替えるようになります。
GKE では、すべての Ingress リソースを Gateway リソースと HTTPRoute リソースに直接変換できます。単一の Ingress は、Gateway（フロントエンド構成の場合）と HTTPRoute（ルーティング構成の場合）の両方に対応します。次の例は、対応する Gateway と HTTPRoute の構成を示しています。Gateway リソースと HTTPRoute リソースは個別に作成できます。異なるユーザーが作成することもできます。Gateway は多くの Route を持つことができ、Route は複数の Gateway に接続できます。Gateway と Route の関係については、Gateway の使用パターンをご覧ください。
Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.class: "gce-internal"
spec:
rules:
- host: "example.com"
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: site
port:
number: 80
- pathType: Prefix
path: /shop
backend:
service:
name: store
port:
number: 80
Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: gke-l7-rilb
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
kinds:
- kind: HTTPRoute
Route
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
hostnames:
- "example.com"
rules:
- matches:
- path:
value: /
backendRefs:
- name: site
port: 80
- matches:
- path:
value: /shop
backendRefs:
- name: store
port: 80
Gateway API とサービス メッシュの統合
Traffic Director サービス メッシュは Gateway API を使用して構成できます。これにより、サービス メッシュのユースケースにサービス間通信、トラフィック管理、グローバル ロード バランシング、セキュリティ ポリシーの適用が可能になります。デプロイ設定ガイドなど、Gateway API での Traffic Director の使用の詳細については、Traffic Director GKE サービス メッシュの概要をご覧ください。
料金
Gateway コントローラを介してデプロイされたすべての Compute Engine リソースは、GKE クラスタが存在するプロジェクトに対して課金されます。リージョン Gateway コントローラは、GKE Standard と Autopilot の一部として追加料金なしで提供されます。マルチクラスタ Gateway の料金については、マルチクラスタ Ingress と Gateway の料金ページをご覧ください。
次のステップ
- ポリシーを使用して Gateway リソースを構成する方法を学習する。
- Gateway のデプロイについて確認する。
- マルチクラスタ Gateway のデプロイについて確認する。
- Gateway API で Traffic Director を使用する方法については、Traffic Director GKE サービス メッシュの概要をご覧ください。