Gateway API v1.1: サービスメッシュ、GRPCRoute、そして更なる進化

By Richard Belleville (Google), Frank Budinsky (IBM), Arko Dasgupta (Tetrate), Flynn (Buoyant), Candace Holman (Red Hat), John Howard (Solo.io), Christine Kim (Isovalent), Mattia Lavacca (Kong), Keith Mattix (Microsoft), Mike Morris (Microsoft), Rob Scott (Google), Grant Spence (Red Hat), Shane Utt (Kong), Gina Yeh (Google), and other review and release note contributors | 翻訳: Taisuke Okamoto (IDC Frontier Inc.), Daiki Hayakawa(bells17) (3-shake Inc.), Junya Okabe (University of Tsukuba) | 2024.05.09

昨年10月のGateway APIの正式リリース後、Kubernetes SIG NetworkはGateway APIのv1.1リリースを発表しました。このリリースでは、いくつかの機能が 標準機能 (GA)に昇格しています。特にサービスメッシュとGRPCRouteのサポートが含まれます。また、セッション維持とクライアント証明書の検証を含む新しい実験的機能も導入しています。

新機能

GAへの昇格

このリリースでは、4つの待望の機能が標準機能に昇格しました。これにより、これらの機能は実験的な段階を卒業したことになります。 GAへの昇格が行われたということは、APIの設計に対する高い信頼性を示すとともに、後方互換性を保証するものです。他のKubernetes APIと同様に、GAへ昇格した機能も時間とともに後方互換性を保ちながら進化していきます。今後もこれらの新機能のさらなる改良と改善が行われることを期待しています。これらの仕組みについて詳しくは、Gateway APIのバージョニングポリシーをご覧ください。

サービスメッシュのサポート

Gateway APIのサービスメッシュサポートにより、サービスメッシュユーザーは同じAPIを使用してIngressトラフィックとメッシュトラフィックを管理することが可能になります。これにより同じポリシーとルーティングインターフェースを再利用することができます。また、Gateway API v1.1では、HTTPRouteなどのルートがServiceをparentRefとして持つことができるようになり、特定のサービスへのトラフィックの動作を制御できます。詳細については、Gateway APIのサービスメッシュドキュメントをお読みいただくか、Gateway APIの実装リストをご覧ください。

例えば、アプリケーションのコールグラフの深部にあるワークロードに対して、HTTPRouteを使用してカナリアデプロイメントを行うことができます。以下はその例です：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

これにより、名前空間faces内のcolorサービスに送信されるトラフィックが、元のcolorサービスとcolor2サービスの間で50対50に分割されます。この設定は移植性が高く、あるメッシュから別のメッシュへ簡単に移行できます。

GRPCRoute

すでにGRPCRouteの実験的機能バージョンを使用している場合、使用しているコントローラーがGRPCRoute v1をサポートするようアップデートされるまで、標準バージョンのGRPCRouteへのアップグレードは控えることをお勧めします。それまでは、v1alpha2とv1の両方のAPIバージョンを含むv1.1の実験的チャンネルバージョンのGRPCRouteにアップグレードしても問題ありません。

ParentReference Port

ParentReferenceにportフィールドが追加されました。これにより、リソースをGatewayのリスナー、Service、あるいは他の親リソース(実装によって異なります)に関連付けることができるようになりました。ポートにバインドすることで、複数のリスナーに一度に関連付けることも可能です。

例えば、HTTPRouteをGatewayの特定のリスナーに関連付ける際、リスナー名ではなくリスナーのポートを指定できるようになりました。これにより、一つまたは複数の特定のリスナーに関連付けることができます。

詳細については、Gatewayへの関連付けを参照してください。

適合性プロファイルとレポート

適合性レポートのAPIが拡張され、実装の動作モードを指定するmodeフィールドと、Gateway APIのチャネル(標準版または実験的機能版)をしめすgatewayAPIChannelが追加されました。 gatewayAPIVersionとgatewayAPIChannelは、テスト結果の簡単な説明とともに、テストスイートの仕組みによって自動的に入力されるようになりました。レポートの構成がより体系的に整理され、実装者はテストの実行方法に関する情報を追加し、再現手順を提供できるようになりました。

実験的機能版チャンネルへの新機能追加

Gatewayのクライアント証明書の検証

Gatewayの各リスナーでクライアント証明書の検証が設定できるようになりました。これは、tls内に新しく追加されたfrontendValidationフィールドによって実現されています。このフィールドでは、クライアントが提示する証明書を検証するための信頼アンカーとして使用できるCA証明書のリストを設定できます。

以下の例は、ConfigMapのfoo-example-com-ca-certに保存されているCA証明書を使用して、Gatewayリスナーのfoo-httpsに接続するクライアントの証明書を検証する方法を示しています。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
  tls:
    certificateRefs:
      kind: Secret
      group: ""
      name: foo-example-com-cert
    frontendValidation:
      caCertificateRefs:
        kind: ConfigMap
        group: ""
        name: foo-example-com-ca-cert

セッション維持とBackendLBPolicy

Gateway APIにセッション維持機能が導入されました。これは新しいポリシー(BackendLBPolicy)によってサービスレベルで設定でき、さらにHTTPRouteとGRPCRoute内のフィールドを使用してルートレベルでも設定可能です。 BackendLBPolicyとルートレベルのAPIは、セッションのタイムアウト、セッション名、セッションタイプ、クッキーの有効期間タイプなど、同じセッション維持の設定を提供します。

以下は、fooサービスにクッキーベースのセッション維持を有効にするBackendLBPolicyの設定例です。セッション名をfoo-sessionに設定し、絶対タイムアウトとアイドルタイムアウトを定義し、クッキーをセッションクッキーとして設定しています：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

その他の変更点

TLS関連用語の明確化

API全体でTLS関連の用語を統一する取り組みの一環として、BackendTLSPolicyに互換性のない変更を加えました。これにより、新しいAPIバージョン(v1alpha3)が導入されました。既存のv1alpha2を使用している場合は、データのバックアップや古いバージョンのアンインストールなど、適切な対応が必要です。

v1alpha2のBackendTLSPolicyフィールドへの参照は、v1alpha3に更新する必要があります。主な変更点は以下の通りです：

targetRefがtargetRefsに変更(複数のターゲットへの適用が可能に)
tlsがvalidationに変更
tls.caCertRefsがvalidation.caCertificateRefsに変更
tls.wellKnownCACertsがvalidation.wellKnownCACertificatesに変更

このリリースに含まれるすべての変更点については、v1.1.0リリースノートをご覧ください。

Gateway APIの背景

Gateway APIのアイデアは、2019年のKubeCon San Diegoで次世代のIngress APIとして最初に提案されました。それ以来、すばらしいコミュニティが形成され、おそらくKubernetes史上最も協力的なAPIを開発してきました。これまでに200人以上がこのAPIに貢献しており、その数は今も増え続けています。

メンテナーは、リポジトリへのコミット、議論、アイデア、あるいは一般的なサポートなど、あらゆる形でGateway APIに貢献してくださった 全ての方々 に感謝の意を表します。このように献身的で活発なコミュニティのサポートなしでは、ここまで到達することはできませんでした。

実際に使ってみましょう

Gateway APIの特徴として、最新版を使用するためにKubernetesそのものを最新にする必要がありません。 Kubernetes 1.26以降であれば、このバージョンのGateway APIをすぐに利用開始できます。

APIを試すには、スタートガイドをご覧ください。

開発に参加しませんか

Ingressやサービスメッシュ向けのKubernetesルーティングAPIの未来を形作るチャンスがたくさんあります。

ユーザーガイドで、対応可能なユースケースをチェックしてみてください。
既存のGatewayコントローラーを実際に試してみるのもおすすめです。
さらに、コミュニティへの参加もお待ちしています。一緒にGateway APIの未来を築いていきましょう！

Kubernetesブログ