Gateway API を使用した GKE Ingress モジュール

※この投稿は米国時間 2023 年 8 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

目的   

Kubernetes Ingress 向け Gateway API は、元の Kubernetes Ingress よりも幅広い機能を処理できます。このブログ投稿では、Google Kubernetes Engine（GKE）上でのゲートウェイの実装について見ていきます。最初の設定方法と、GKE でモニタリングする方法を確認します。また、GCP ゲートウェイ ポリシーの形式でセキュリティを設定する点についても確認します。

はじめに

NodePort および LoadBalancer サービス オブジェクトは当初、Kubernetes のサービスを外部の世界に公開するためのものでした。その後、Ingress リソース上で定義されたルールによって制御されるサービスにトラフィックをルーティングする Ingress が開発されました。Kubernetes Gateway API は Ingress の進化版であり、同じ機能を提供しますが、Ingress 機能のスーパーセットとして提供されています。

GKE Gateway Controller は、Google がロード バランシングに実装した Gateway API です。Gateway コントローラは Gateway API リソースを監視し、Cloud Load Balancing リソースを調整して、Gateway リソースで指定されたネットワーク動作を実装します。GKE Gateway Controller は、Namespace、クラスタ、リージョン間で共有されるロードバランサのマルチテナント使用をサポートします。

Gateway API を使用すると、Ingress の実装は次のような個別のリソースに分割されます。これにより、役割やチームに合わせたコンポーネントの連携が可能になります。そのため、GatewayClass はプラットフォームによって提供されます（GKE の GatewayClass を参照）。クラスタ オペレータはゲートウェイをプロビジョニングします。アプリケーション チームは、HTTPRoutes を個別にデプロイし、ゲートウェイに安全に接続することで、アプリケーションを公開できます。下記の図をご参照ください。

目標

ここでは、GKE Gateway を使用して、GKE で実行されている twsttech.io というサンプル ウェブ アプリケーションに外部 Ingress を設定することを目標とします。そのためには、次のことを行う必要があります。

• 外部 L7 ゲートウェイ クラスに基づいてグローバル ゲートウェイを作成します - 証明書マッピングを参照します

• アプリケーションへのルートパスに基づいて HTTPRoute を作成します。

• 以前に生成された SSL ポリシーを参照して、TLS を v1.2 に制限する SSL ベースの GatewayPolicy を作成します。

また、上記のリソースの仕様と、さまざまな GKE Ingress ユースケースで使用するためのリソースの構成方法について、もう少し理解したいと考えています。

次の前提条件は、実際のゲートウェイの実装ではなく、Ingress のセキュリティに重点を置いているため、このブログ投稿の範囲外です。

• 外部ドメイン名を静的 IP で設定する

• ドメイン証明書を作成する

• Google Certificate Manager を使用して作成する証明書マッピング

• TLS バージョンを適用する SSL ポリシー

使ってみる

クラスタで Gateway API を有効にしてみましょう。私たちのクラスタは既存の GKE Standard クラスタであるため、次のコマンドを実行する必要があります。

他の GKE クラスタのタイプで Gateway API を有効にする際は、クラスタで Gateway API を有効にするのドキュメントの指示に沿って操作します。

ゲートウェイ クラスがクラスタにインストールされていることを確認します。

出力は次のようになります（簡潔にするために一部省略されています）。

外部ゲートウェイを作成する

次のマニフェストを gateway.yaml として保存します。

このファイルは、次の仕様でゲートウェイを定義します。

• ゲートウェイは op-gateway と呼ばれ、名前空間 ns-gateway に作成されます

• ゲートウェイ クラスは gke-l7-global-external-managed です

• ゲートウェイは、アノテーションを介して適用される証明書マッピング Certificate Manager である wildcard-op-twsttech-io-cert-map を使用して構成されます。これはパブリック ドメイン *.twsttech.io 用に事前構成された証明書です。Certificate Manager の利点は、ワイルドカード ドメイン名の DNS 認証を備えた Google が管理する証明書を使用できることです。

• ゲートウェイには 80 と 443 の両方のリスナーがあり、すべての名前空間からのバインディングが可能です。

• また、事前構成された管理対象パブリック IP である twst-public-ip-op も使用します。

HTTPRoute を作成する

これにより、ゲートウェイに接続するルートが定義されます。

次のマニフェストを httproute.yaml として保存します。

このファイルは、次の仕様で HTTPRoute を定義します。

• HTTPRoute 名は training-route1-api です

• これは、ゲートウェイ op-gateway を参照します。そして、同じ名前空間 ns-gateway に作成されます。HTTPRoutes は、共有ゲートウェイを使用して、異なる名前空間に存在できます。

• ホスト名は training.twsttech.io.com として定義され、ルールはルートパス（/）として設定されます。

• BeckendRef は、公開される GKE サービス（training）として定義されます。

GCPGatewayPolicy を作成する

これにより、最小の TLS バージョンで、ロードバランサ トラフィックに合わせてクライアントをカスタマイズできるようになります。これは、以前に作成した SSL ベースのポリシーを参照します。

次のマニフェストを gw-policy-tls.yaml として保存します。

このファイルは、次の仕様で GCPGatewayPolicy を定義します。

• GCPGatewayPolicy の名前は、ゲートウェイと同じ名前空間 ns-gateway で gp-tls-12 と名付けられます。

• このポリシーは、sslp-tls-12 という名前の事前構成された SSL ポリシーを参照します。

ファイルをデプロイする

kubectl apply を使用して 3 つの yaml ファイルのすべてをデプロイします。3 つすべてがデプロイされていることを確認します。

ゲートウェイにルートが接続されていることを確認します。

これで完了です。GKE のサンプル ウェブ アプリケーションが、Gateway API を使用して公開されるようになりました。ゲートウェイ ポリシーを使用して、TLS バージョンの追加のセキュリティを指定しました。

Gateway API は、個別または共有の Ingress ルートに使用できます。これにより、費用を削減できるだけでなく、組織内の役割やチームと連携できる多数のルートを備えた単一のロードバランサを構成するオプションが提供されます。

次のステップ

上記で使用したファイルは、私の opowbow GitHub リポジトリにあります。お気軽にご覧ください。また、Kubernetes Gateway の動作を確認するには、こちらの動画をご覧ください。GKE へのゲートウェイのデプロイについて詳しくは、「Gateway のデプロイ」ドキュメント ページをご覧ください。