ゲートウェイ

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このページでは、GKE Gateway コントローラを使用した、Kubernetes Gateway API の Google Kubernetes Engine(GKE)実装について説明します。GKE で Gateway をデプロイするには、Gateway のデプロイまたはマルチクラスタ Gateway のデプロイをご覧ください。

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

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

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

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

Gateway API リソース

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

GKE には Gateway クラスがあります。クラスタ オペレータは、これらのクラスに基づいて Gateway リソースを作成します。アプリケーション デベロッパーは、Gateway リソースにバインドする HTTPRoute リソースを作成します。
図: Gateway API の概要

Gateway API には次のリソースタイプがあります。

  • GatewayClass: クラスタ スコープ リソースを定義します。これは、クラスタにロードバランサを作成する際のテンプレートになります。GKE は、GKE クラスタで使用できる GatewacyClass を提供します。
  • Gateway: ロードバランサがトラフィックをリッスンする場所と方法を定義します。クラスタ オペレータは GatewayClass に基づいてクラスタに Gateway を作成します。GKE は、Gateway リソースで定義された構成を実装するロードバランサを作成します。
  • HTTPRoute: Gateway から Kubernetes Services にリクエストをルーティングするためのプロトコル固有のルールを定義します。GKE は、HTTP(S) ベースのトラフィック ルーティング用の HTTPRoutes をサポートしています。アプリケーション デベロッパーは HTTPRoute を作成し、Gateway を使用して HTTP アプリケーションを公開します。
  • ポリシー: Gateway リソースの一連の実装固有の特性を定義します。ポリシーは、Gateway、ルート、Kubernetes Service に接続できます。GKE は次のポリシーをサポートしています。
    • LBPolicy: Google Cloud ロードバランサからの想定される動作を定義します。
    • HealthCheckPolicy: バックエンド Pod のヘルスチェックの種類とヘルスチェックの特性を定義します。

GatewayClass

GatewayClass は、Kubernetes クラスタ内の TCP / UDP(レベル 4)ロードバランサと HTTP(S)(レベル 7)ロードバランサのテンプレートを定義するリソースです。GKE は、クラスタ スコープ リソースとして GatewayClasses を提供します。クラスタ オペレータは、クラスタで Gateway を作成する際に GatewayClass を指定します。

GatewayClass によって対応する Google Cloud ロードバランサが異なります。GatewayClass を使用して Gateway を作成すると、対応する構成が作成され、指定した構成が実装されます。一部の GatewayClass はマルチクラスタ負荷分散をサポートしています。

次の表に、GKE クラスタで使用可能な GatewayClass と、その基になるロードバランサ タイプを示します。GatewayClass の詳細については、GatewayClass の機能と仕様をご覧ください。

クラス名 説明
gke-l7-rilb 内部 HTTP(S) 負荷分散上に構築されたリージョン内部 HTTP(S) ロードバランサ
gke-l7-gxlb グローバル外部 HTTP(S) ロードバランサ(従来版)上に構築されたグローバル外部 HTTP(S) ロードバランサ
gke-l7-rilb-mc 内部 HTTP(S) 負荷分散上に構築されたマルチクラスタ リージョンのロードバランサ
gke-l7-gxlb-mc グローバル外部 HTTP(S) ロードバランサ(従来版)上に構築されたマルチクラスタ グローバル ロードバランサ
gke-td マルチクラスタ Traffic Director サービス メッシュ

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 は、リクエスト ヘッダーの詳細に基づいてリクエストを照合できます。

ポリシー

ポリシーは、クラスタ オペレータがゲートウェイ、ルート、または Kubernetes Service に接続できる Gateway リソースの特性(通常は実装固有)を定義します。ポリシーは、基盤となる Google Cloud インフラストラクチャの動作を定義します。

ポリシーは、通常、名前空間に関連付けられており、RBAC を使用して同じ名前空間内のリソースを参照できます。Gateway API は階層的な性質を持つため、名前空間内のトップレベルのリソース(Gateway)にポリシーを接続し、異なる名前空間の下のすべてのリソースにポリシーの特性を適用できます。

GKE Gateway コントローラは、次の 2 つのポリシーをサポートします。

  • LBPolicy: Google Cloud ロードバランサの特定のパラメータを定義します。これは、Ingress リソースの BackendConfig と似ています。
  • HealthCheckPolicy: バックエンド Pod のヘルス ステータスの確認に使用されるヘルスチェックのパラメータと動作を定義します。

Gateway のオーナー権限と使用パターン

Gateway と Route のリソースは、組織内での所有とデプロイに柔軟性を提供します。つまり、インフラストラクチャ チームは単一のロードバランサをデプロイし、管理できますが、特定のドメインまたはパスの下のルーティングは、別の Kubernetes Namespace の別のチームに委任できます。GKE Gateway コントローラは、Namespace、クラスタ、リージョン間で共有されるロードバランサのマルチテナント使用をサポートします。また、分散オーナー権限がさらに必要な場合は、Gateway を共有する必要はありません。GKE の Gateway の一般的な使用パターンの一部を次に示します。

セルフマネージド Gateway

1 人のオーナーが、アプリケーション用に Gateway と Route をデプロイし、排他的に使用できます。この方法でデプロイされた Gateway と Route は Ingress と似ています。次の図は、独自の Gateway をデプロイして管理する 2 人の異なるサービス オーナーを示しています。Ingress と同様に、各 Gateway は固有の IP アドレスとロードバランサに対応しています。TLS、ルーティングなどのポリシーはサービス オーナーによって完全に制御されます。

1 人のオーナーが、Gateway と Route の両方を完全に制御できます。

この使用パターンは Ingress では一般的ですが、共有リソースがないため、多くのチームでスケーリングが困難です。Gateway API のリソースモデルは、分散制御とオーナー権限のさまざまなオプションを提供する以下の使用パターンを可能にします。

Namespace ごとのプラットフォーム マネージド Gateway

Gateway と Route のリソースを分離することで、プラットフォーム管理者はサービス オーナーに代わって Gateway を制御できます。プラットフォーム管理者は、Namespace またはチームごとに Gateway をデプロイし、その Namespace に Gateway を使用するための排他的アクセス権を付与できます。これにより、サービス オーナーは、他のチームとの競合のリスクなしに、ルーティング ルールを完全に制御できます。これにより、プラットフォーム管理者は、IP 割り振り、ポート公開、プロトコル、ドメイン、TLS などのアスペクトを制御できます。プラットフォーム管理者は、チームが使用できる Gateway の種類(内部 Gateway や外部 Gateway、パブリック Gateway など)を決定することもできます。この使用パターンにより、ロール間の責任が明確に分離されます。

Namespace をまたがるルーティングにより、Route が Namespace の境界を超えて Gateway に接続できるようになります。Gateway は、Route が接続できる Namespace を制限できます。同様に、Route は、接続する Gateway を指定しますが、接続できるのは Route の Namespace を許可している Gateway だけです。この双方向のアタッチメントは、多様な使用パターンを可能にする柔軟な制御を各側に提供します。

次の図では、プラットフォーム管理者が各 Namespace に排他的にアクセスできる Gateway をデプロイしています。たとえば、store Gateway は、store Namespace からの Route のみが接続できるように構成されています。各 Gateway は一意のロード バランシングされた IP アドレスを表すため、各チームは、選択したドメインまたはルートに対して、Gateway に任意の数の Route をデプロイできます。

Namespace ごとに Gateway を指定すると、その Namespace への Gateway の排他的アクセスが可能になります。

クラスタごとの共有 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 内で限定公開で通信できます。

各クラスタに 1 つの Gateway を使用すると、クラスタ内の複数の Namespace で 1 つの Gateway を共有できます。

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/* へのトラフィックはクライアントに最も近いクラスタに明示的な方法でルーティングされます。この柔軟性により、サービス オーナーはアプリケーションに最適なルーティング戦略を定義できます。

1 フリートあたりの Gateway 数は、マルチクラスタ、マルチリージョンでロード バランシングされます。

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 を管理します。複数クラスタ ゲートウェイのコントローラは、プレビュー リリース ステージであり、SLA やテクニカル サポートはありません。

どちらの Gateway コントローラも Google がホストするコントローラで、GKE クラスタの Kubernetes API を監視します。GKE Ingress コントローラとは異なり、Gateway コントローラは GKE コントロール プレーンまたはユーザー プロジェクトでホストされないため、スケーラビリティと堅牢性が向上します。

Gateway コントローラ自体はネットワーク データプレーンではなく、トラフィックは処理されません。トラフィックから帯域外で、トラフィックを処理するさまざまなデータプレーンを管理します。次の図は、単一クラスタと複数クラスタの GKE Gateway コントローラのアーキテクチャを示しています。使用される基礎となるコントローラは、デプロイされた Gateway の GatewayClass によって異なります。

マルチクラスタと単一クラスタの Gateway コントローラは、GKE のロードバランサをデプロイして管理しますが、ネットワーク トラフィック自体は処理しません。

コントローラ 単一クラスタ Gateway コントローラ 複数クラスタ Gateway コントローラ
管理者 Google Google
クラスタのスコープ 単一クラスタ Gateway 複数クラスタ Gateway
デプロイする場所 GKE クラスタと同じリージョンにデプロイされます。 複数の Google Cloud リージョンにグローバルにデプロイされます。
有効にする方法 GKE では、デフォルトで有効になっています。 マルチクラスタ Ingress API を使用して有効にし、フリートに登録します。マルチクラスタ Gateway の有効化をご覧ください。
サポートされている GatewayClass
  • gke-l7-rilb
  • gke-l7-gxlb
  • gke-l7-rilb-mc
  • gke-l7-gxlb-mc
リリース ステージ 一般提供 プレビュー

GKE クラスタでは、複数の Gateway コントローラ(Google が提供していないコントローラも含む)を同時に使用できます。どの GatewayClass も 1 つの Gateway コントローラのみでサポートされているため、単一クラスタとマルチクラスタのロード バランシングを同時に使用できます。

Ingress と Gateway

Ingress から Gateway への移行

Ingress と Gateway の間の移行は、同じ Service のセットを指す Ingress リソースと Gateway リソースの両方を同時にデプロイすることで行えます。これにより、同じバックエンド アプリケーション用の 2 つのエントリ ポイントが作成されます。Ingress と Gateway はそれぞれ、個々のロードバランサの IP アドレスに対応しています。Gateway のパスをテストし、検証したら、DNS を使用して Ingress から Gateway にトラフィックを切り替えます。

Gateway への Ingress の直接変換はサポートされていません。ただし、現在 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

ゲートウェイ

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

ルーティング

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

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

料金

Gateway コントローラを介してデプロイされたすべての Compute Engine リソースは、GKE クラスタが存在するプロジェクトに対して課金されます。リージョン Gateway コントローラは、GKE Standard と Autopilot の一部として追加料金なしで提供されます。マルチクラスタ Gateway コントローラは、プレビュー期間中は追加料金なしで使用できます。一般提供になると、マルチクラスタ Gateway はマルチクラスタ Ingress と Gateway の料金に従って課金されます。

次のステップ