Kubernetes Gateway API v1.0: 切り替えるべきか？

Navendu Pottekkat

Navendu Pottekkat

December 15, 2023

Ecosystem

Kubernetes Gateway APIがv1.0リリースされてから1ヶ月以上が経過し、主要なAPIが一般利用可能（GA）ステータスに昇格しました。

昨年、Gateway APIがベータ版に昇格した際にIngress APIとの比較について書きましたが、1年経った今でも同じ疑問が残っています。Ingress APIからGateway APIに切り替えるべきでしょうか？

昨年の私の答えは「切り替えるべきではない」でした。そして、その理由は非常に強力なものでした。

当時、Gateway APIとその実装はまだ初期段階でした。一方、Ingress APIは安定しており、多くのユーザーにとって十分な主要なユースケースをカバーしていました。

より多くの機能を必要とするユーザーには、Ingressコントローラが提供するカスタムリソースを使用し、移植性（異なるIngress実装間での切り替え）を犠牲にすることを提案しました。

しかし、v1.0リリースにより、この状況が変わる可能性があります。Gateway APIは現在、はるかに強力になり、20以上の実装が急速に追いついています。

したがって、新規に始める場合でIngressとGateway APIのどちらかを選ぶ必要があるなら、APIと選択した実装があなたが必要とするすべての機能をサポートしているのであれば、Gateway APIを選ぶことをお勧めします。

Ingress APIの問題点

Ingress APIは、一部の一般的なユースケースでは非常にうまく機能しますが、その機能を拡張するために、Ingress実装はカスタムアノテーションを使用し始めました。

例えば、Nginx Ingressを選択した場合、その数十のアノテーションの一部を使用することになりますが、これらはApache APISIXのような別のIngress実装に切り替える場合には移植性がありません。

これらの実装固有のアノテーションは管理が煩雑で、Kubernetesネイティブな方法でIngressを管理する目的を損なうことになります。

最終的に、Ingressコントローラの実装は、Kubernetesユーザーにより多くの機能を提供するために独自のCRDを開発し始めました。これらのCRDはIngressコントローラに固有のものです。しかし、移植性を犠牲にして1つのIngressコントローラに固執できるのであれば、CRDは扱いやすく、より多くの機能を提供します。

Gateway APIは、Ingress APIのベンダー中立性とCRDの柔軟性を提供することで、この問題を一挙に解決することを目指しています。この目標を達成するために、非常に良い位置にあります。

長期的には、Ingress APIには新機能が追加されることはなく、すべての努力がGateway APIとの統合に向けられるでしょう。したがって、Ingress APIを採用すると、その機能の限界に達した際に問題が発生する可能性があります。

明らかな利点

表現力豊かで、拡張可能で、役割指向であることが、Gateway APIの開発を形作った主要なアイデアです。

Ingress APIとは異なり、Gateway APIは複数のAPI（HTTPRoute、Gateway、GatewayClassなど）の集合体であり、それぞれが異なる組織の役割に対応しています。

例えば、アプリケーション開発者はHTTPRouteリソースのみを気にすればよく、トラフィックをルーティングするためのルールを定義できます。クラスタレベルの詳細は、クラスタを管理し、開発者のニーズを満たすためにGatewayリソースを使用するオペレーターに委任できます。

Gateway API

この役割指向の設計により、異なる人々がクラスタを使用しながらも制御を維持できます。

Gateway APIは、Ingress APIよりもはるかに多くの機能を備えています。Ingress APIではアノテーションが必要だった機能が、Gateway APIでは標準でサポートされています。

公式の拡張機能

Gateway APIは公式のKubernetes APIですが、一連のCRDとして実装されています。

これはデフォルトのKubernetesリソースを使用するのと変わりませんが、これらのCRDを公式の拡張機能としてインストールする必要があります。

APISIXのGateway APIサポート

これにより、Kubernetesが長期的な安定性に向かってゆっくりと進む中で、迅速な反復が可能になります。

普及するか？

この有名なXKCDコミックが頻繁に思い出させてくれるように、標準は増殖する傾向があります。

IngressとGateway APIでも同様のことが見られました。通常、以下のような流れです：

  1. 異なるプロジェクト/標準を統一するための標準が登場する（Kubernetes Ingress API）。
  2. 統一された標準には、実装者が克服したい制限がある（Ingress APIは制限されていた）。
  3. これらの制限により、実装が標準から逸脱する（カスタムCRD、アノテーション）。
  4. 各実装が独自の標準を持つようになる（移植性のないCRD、アノテーション）。
  5. これらの異なる標準を統一する新しい標準が登場する（Kubernetes Gateway API）。

Gateway APIが最終的な解決策ではないと考えるのは合理的です。しかし、私はこれがKubernetesでのルーティングの標準になる可能性が十分にあると信じています。

繰り返しになりますが、私にはそのための強力な理由があります。

標準の増殖を防ぐためには、広範な採用が重要です。実装が異なる標準に取り組むインセンティブが少なくなるためです。Gateway APIはすでに25以上の実装があります。

実装は、Gateway APIに異なるレベルで準拠できます：

  1. コア: すべての実装がこれに準拠することが期待されます。
  2. 拡張: 一部の実装でのみ利用可能ですが、標準APIです。
  3. 実装固有: 実装に固有ですが、標準の拡張ポイントを通じて追加されます。

ニッチな機能は、より多くの実装がその機能をサポートするにつれて、実装固有から拡張、そしてコアに移行することができます。つまり、APIは標準に従いながら、カスタム拡張の余地を確保しています。

Service Mesh Interface (SMI)プロジェクトは、Kubernetesでのサービスメッシュの設定を標準化するための同様の試みでした。しかし、このプロジェクトはサービスメッシュプロジェクトの初期の関与の後、ほとんど注目されず、徐々に消えていきました。

SMIは、ユーザーがサービスメッシュに期待する多くの共通機能をサポートしていませんでした。また、これらの機能をサポートするために十分に迅速に動きませんでした。最終的に、サービスメッシュの実装はSMIへの準拠が遅れました（私はCNCF TAG Networkの下でSMIに密接に関わり、SMI準拠を報告するプロジェクトに取り組んでいました）。

これらは普遍的な理由ですが、このプロジェクトは現在、Gateway APIを通じて復活しています。Gateway API for Mesh Management and Administration (GAMMA)イニシアチブは、Gateway APIをサービスメッシュと連携させることを目指しています。

SMIプロジェクトは最近GAMMAイニシアチブと統合されました、これはGateway APIにとって非常に良いことです。間違いなく最も人気のあるサービスメッシュであるIstioも、Gateway APIが将来Istioを管理するためのデフォルトAPIになることを発表しました。このような採用は、標準の増殖を防ぎます。

移行ガイド

Gateway APIのドキュメントには、IngressリソースをGatewayリソースに移行するための包括的なガイドがあります。それを繰り返す代わりに、ingress2gatewayツールを使用して、Ingressリソースを対応するGateway APIリソースに変換してみましょう。

リリースページから直接、お使いのオペレーティングシステム用のバイナリをダウンロードしてインストールできます。

以下のようなシンプルなIngressリソースを例に取ります：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

これは、指定されたホストアドレスを持つすべてのトラフィックをhttpbinサービスにルーティングします。

これをGateway APIリソースに変換するには、以下のコマンドを実行します：

ingress2gateway print --input_file=ingress.yaml

このGateway APIリソースは以下のようになります：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

代替手段

Kubernetesでゲートウェイを設定するための他の有効な代替手段もあります。

Apache APISIXでは、スタンドアロンモードでデプロイし、yamlファイルでルート設定を定義できます。このyamlファイルを従来のワークフローで更新でき、Kubernetes APIを介してゲートウェイ設定を管理する必要がないシナリオでは非常に役立ちます。

実装固有のカスタムCRDも、異なるソリューションに切り替える予定がない場合や、設定が小さくて簡単に移行できる場合には有効な代替手段です。

いずれにせよ、Gateway APIはここに残るでしょう。

Tags:
Gateway API
Kubernetes