ゲートウェイ

Autopilot Standard

---

このページでは、GKE Gateway Controller を使用した、Kubernetes Gateway API の Google Kubernetes Engine（GKE）実装について説明します。

このページは、組織のネットワークを設計するクラウド アーキテクトとネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

Gateway API は、サービス ネットワーキング用のオープンソース標準です。Gateway API は、Ingress リソースを進化させ、次の方法で改善します。

• ロール指向: Gateway は、クラスタ オペレータ、デベロッパー、インフラストラクチャ プロバイダの組織のロールに対応する API リソースで構成されます。これにより、クラスタ オペレータは、異なる個別のデベロッパー チームによる共有インフラストラクチャの使用方法を定義できます。

• ポータビリティ: Gateway API は多くの実装を備えたオープンソース標準です。適合性に優れ、環境や実装のネイティブ機能をサポートする柔軟性と拡張性を備えた設計になっているため、Ingress のように移植性の高いコア API として使用できます。実装と環境全体でコンセプトとコアリソースの整合性が維持されるため、複雑さを軽減し、使いやすさを向上させることができます。

• 豊富な機能: Gateway API リソースを使用すると、Ingress ではカスタム アノテーションが必要になるヘッダーベースの照合やトラフィックの重み付けなどを組み込み機能で実現できます。

Gateway API リソース

Gateway API はロールベースのリソースモデルであり、Kubernetes ネットワーキングとやり取りするペルソナ向けに設計されています。次の図に示すように、このモデルでは、調整していないさまざまなサービス オーナーが、プラットフォーム管理者のポリシーと制御を一元化し、基盤となる管理者と同じネットワーク インフラストラクチャを安全に共有できます。

図: Gateway API の概要

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 に接続できます。
• ReferenceGrant: Gateway API 内の Namespace の相互の参照を有効にします。Namespace の外のオブジェクトを参照するには、ReferenceGrant リソースを作成する必要があります。

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	従来のアプリケーション ロードバランサ上にビルドされたマルチクラスタ グローバル外部アプリケーション ロードバランサ
asm-l7-gxlb	Cloud Service Mesh 上にビルドされたグローバル外部アプリケーション ロードバランサ

GatewayClass には、基盤となるロードバランサの制限が適用されます。

注: グローバル外部アプリケーション ロードバランサのデプロイを検討する際は、gke-l7-gxlb(-mc) GatewayClass を介して gke-l7-global-external-managed(-mc) GatewayClass を使用し、高度なセキュリティとトラフィック管理機能を利用することをおすすめします。GatewayClass でサポートされている機能の詳細については、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 に似ています。

注: Google Cloud では、LbPolicy ポリシーが GCPBackendPolicy ポリシーに置き換わりました。LbPolicy は引き続きサポートされますが、追加属性はありません。

ReferenceGrant

ReferenceGrant を使用すると、HTTPRoute や Gateway などのリソースが、Namespace の相互の参照を使用して、異なる Namespace にあるバックエンド サービスや Secret を参照できます。ReferenceGrant は権限プロバイダとして機能し、他のリソース（to）を参照できるリソース（from）を指定します。Namespace の相互の参照を有効にするには、参照されるリソースの Namespace に ReferenceGrant が必要です。

次の例では、frontend Namespace の HTTPRoute が、backend Namespace の Service にトラフィックをルーティングする必要があります。backend Namespace に次のような ReferenceGrant を作成します。

• from フィールドには、参照が許可されているソース名前空間とリソースタイプ（frontend Namespace の HTTPRoute）が一覧表示されます。
• to フィールドには、参照可能なターゲット リソースタイプ（backend Namespace 内の Service）を指定します。

apiVersion: networking.gke.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-frontend-to-access-backend
  namespace: backend
spec:
  from:
  - group: gateway.networking.gke.io
    kind: HTTPRoute
    namespace: frontend
  to:
  - group: ""
    kind: Service

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-l7-global-external-managed 一般提供 gke-l7-regional-external-managed 一般提供 gke-l7-rilb 一般提供 gke-l7-gxlb 一般提供 asm-l7-gxlb プレビュー	gke-l7-global-external-managed-mc 一般提供 gke-l7-regional-external-managed-mc 一般提供 gke-l7-rilb-mc 一般提供 gke-l7-gxlb-mc 一般提供 gke-td プレビュー

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 とサービス メッシュの統合

Cloud Service Mesh サービス メッシュは Gateway API を使用して構成できます。これにより、サービス メッシュのユースケースにサービス間通信、トラフィック管理、グローバル ロード バランシング、セキュリティ ポリシーの適用が可能になります。デプロイ設定ガイドなど、Gateway API での Cloud Service Mesh の使用の詳細については、Cloud Service Mesh GKE サービス メッシュの概要をご覧ください。

料金

Gateway コントローラを介してデプロイされたすべての Compute Engine リソースは、GKE クラスタが存在するプロジェクトに対して課金されます。リージョン Gateway コントローラは、GKE Standard と Autopilot の一部として追加料金なしで提供されます。マルチクラスタ Gateway の料金については、マルチクラスタ Ingress と Gateway の料金ページをご覧ください。

次のステップ

• ポリシーを使用して Gateway リソースを構成する方法を学習する。
• Gateway のデプロイについて確認する。

• 複数クラスタ Gateway のデプロイについて確認する。

• Gateway API で Cloud Service Mesh を使用する方法については、Cloud Service Mesh GKE サービス メッシュの概要をご覧ください。