Gateway API v1.1: サービスメッシュ、GRPCRoute、そして更なる進化
昨年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の未来を築いていきましょう!