CLOUD SECURITY LAB

🚀 Kubernetesネットワーキングの新しい標準：Gateway APIを完全にマスターする (GatewayClass, Gateway, HTTPRoute)

—

by

cslab
in

こんにちは！ 👋 今日は、Kubernetes (k8s) クラスターへのインバウンドトラフィックを管理する新しい標準であるGateway APIについて深く掘り下げていきます。既存のIngress方式に限界を感じ、Gateway APIがどのようにそれらの問題を解決し、より良い体験を提供するのか疑問に思っていましたか？この記事では、GatewayClass、Gateway、HTTPRouteという主要なリソースを中心に、TLS証明書の適用方法からIngressとの違いまで、すっきりと説明します！ 🤓

🤔 Kubernetesはなぜ新しいトラフィック管理方式を必要としたのか？

Kubernetes環境が複雑化し、複数のチームが1つのクラスターを共有するケースが増えるにつれて、既存のIngress方式はいくつかの明確な限界に直面しました。

  • 役割分担の欠如: クラスター管理者とアプリケーション開発者の間の責任と権限が明確に分離されていませんでした。インフラ設定とルーティングルールが1つのIngressオブジェクトに混在しており、些細なルーティング変更がインフラ全体に影響を与えるリスクがありました。 😰
  • 標準化されていない拡張: 基本的な機能以外に、トラフィック重み付けベースのルーティング、ヘッダーベースのルーティングなどの高度な機能を使用するには、各Ingressコントローラー（Nginx、Traefikなど）ごとに異なるアノテーションを使用する必要がありました。これは特定のベンダーに依存させ、設定を他の環境に移植することを困難にしました。
  • 限定的なプロトコルサポート: Ingressは基本的にHTTP/HTTPSトラフィックにのみ焦点を当てており、TCP、UDP、gRPCなどの他のプロトコルを扱うには不十分でした。

これらの問題を解決するために、より柔軟で表現力豊か、かつ役割ベースで設計されたGateway APIが登場したのです。 🎉

GATEWAY APIの主要3要素: GatewayClass, Gateway, HTTPRoute

Gateway APIは、役割を明確に分ける3つの主要なリソースを中心に動作します。これは、役割を分担して効率的に働くチームのようです。
リソース 担当者 (ペルソナ) 役割
GatewayClass インフラ提供者 (Infra Provider) どのような種類のロードバランサーを使用するかを定義するテンプレート (例: AWS LB, GCP LB, Nginx)
Gateway クラスター運用者 (Cluster Operator) GatewayClassを使用して実際のロードバランサーインスタンスを作成し、どのポートとプロトコルを使用するか、どのルーティングルールを許可するかを定義
HTTPRoute アプリケーション開発者 (App Developer) Gatewayに接続して、特定のホスト名やパスで入ってくるトラフィックをどのサービスに送るか、詳細なルーティングルールを定義

このような役割分担により、各担当者が自身の責任領域にのみ集中できるようになり、安定性とセキュリティが大幅に向上します。

1. GatewayClass: ロードバランサーの青写真 📜

GatewayClassはクラスター全体に適用されるリソースで、どのコントローラーがゲートウェイを管理するかを定義します。クラウドプロバイダーのロードバランサーを使用することも、クラスター内に直接インストールされたNginxやIstioのようなコントローラーを指定することもできます。

YAML 例:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: example.com/gateway-controller
  • controllerName: このGatewayClassを実装および管理するコントローラーの名前を指定します。

2. Gateway: トラフィックが入ってくる門 🚪

GatewayはGatewayClassを参照して実際のロードバランサーインスタンスを作成します。クラスター運用者はこのリソースを通じて、外部トラフィックを受け入れるポート、プロトコル、およびTLS証明書などを設定します。

YAML 例 (TLS証明書を含む):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: my-app-ns
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: https-listener
    protocol: HTTPS
    port: 443
    hostname: "example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-tls-secret # TLS証明書と秘密鍵が保存されたSecret
        kind: Secret
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            expose: "true"
  • gatewayClassName: 使用するGatewayClassを指定します。
  • listeners: トラフィックを受信するポートとプロトコルを定義します。
  • hostname: 特定のホスト名で入ってくるトラフィックのみを処理するように制限できます。
  • tls.certificateRefs: HTTPS通信に使用するTLS証明書が格納されたSecretを参照します。mode: Terminateは、このゲートウェイでTLS接続を終了し、ゲートウェイと内部Pod間では暗号化されていないHTTP通信を行うことを意味します。
  • allowedRoutes: このゲートウェイに接続できるRoute（例: HTTPRoute）をネームスペースラベルを通じて制限し、セキュリティを強化します。

3. HTTPRoute: 賢い交通警察官 👮

アプリケーション開発者はHTTPRouteを使用して、Gatewayに入ってきたトラフィックをどのように処理するかを詳細に定義します。パスベースのルーティング、ヘッダーベースのルーティング、重み付けベースのトラフィック分割（カナリアデプロイ）など、きめ細やかな制御が可能です。

YAML 例 (重み付けベースのトラフィック分割):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: my-app-ns
  labels:
    expose: "true" # GatewayのallowedRoutesセレクターと一致する必要があります
spec:
  parentRefs:
  - name: my-gateway # 接続する親Gatewayを指定
    namespace: my-app-ns
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-app-v1 # サービス名
      port: 80
      weight: 90
    - name: my-app-v2 # 新しいバージョンのサービス
      port: 80
      weight: 10
  • parentRefs: このルーティングルールを適用するGatewayを指定します。
  • hostnames: このルールが適用されるホスト名を明示します。
  • rules: 実際のルーティングルールを定義します。上記の例は、example.com/に入ってくるトラフィックの90%をmy-app-v1サービスに、10%をmy-app-v2サービスに送るカナリアデプロイのシナリオです。

Gateway API vs Ingress: 何が違うのか？
機能 Ingress Gateway API
役割分担 ❌ なし (単一リソース) ✅ 明確 (GatewayClass, Gateway, Route)
移植性 ⚠️ 低い (ベンダー固有のアノテーション) ✅ 高い (標準化されたフィールド)
表現力 ⚠️ 限定的 (パス/ホストベース) ✅ 非常に優れている (ヘッダー、重み、フィルターなど)
プロトコル HTTP, HTTPS HTTP, HTTPS, TCP, UDP, gRPC, TLS
権限モデル ⚠️ 広範な権限が必要 ✅ 役割ベースのきめ細やかな権限制御
クロスネームスペース ⚠️ 限定的で危険 ✅ 安全な参照モデルを提供 (ReferenceGrant)

最大の相違点は役割ベースのアーキテクチャです。Gateway APIは、インフラ担当者とアプリ開発者の責任を明確に分離し、複数のチームが安全かつ独立して1つのクラスターを共有できる強力な基盤を提供します。開発者はもはやインフラの詳細を気にすることなく、自身のアプリケーションルーティングにのみ集中できるようになります。

✨ 結論: 未来の標準に備えましょう！

Gateway APIは単なるIngressの代替品ではありません。これはKubernetesネットワーキングのパラダイムを変える進化です。役割ベースの柔軟で拡張可能なアーキテクチャを通じて、複雑なマイクロサービス環境のトラフィック管理をはるかに安全かつ効率的にします。

まだIngressを使用している場合でも、将来的にはGateway APIが標準となることは明らかです。今からGateway APIの概念を理解し、皆さんのクラスターにどのように適用できるかを検討してみてください！皆さんのKubernetesの旅がさらに一歩前進するでしょう。 🌟

タグ: Kubernetes, Gateway API, Ingress, GatewayClass, Gateway, HTTPRoute, MSA, DevOps, Cloud Native

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です