--- title: "Kubernetes Gateway API v1.0: 切り替えるべきか？ - API7.ai" description: "Kubernetes APIが最近一般提供されるようになりました。これは、Ingress APIから切り替えるべきだという意味なのでしょうか？" url: "https://api7.ai/ja/blog/gateway-api-v1" --- [Blog](https://api7.ai/ja/blog) [Products](https://api7.ai/ja/category/products)[Technology](https://api7.ai/ja/category/technology)[Ecosystem](https://api7.ai/ja/category/ecosystem)[Case Study](https://api7.ai/ja/category/usercase)[Team & Community](https://api7.ai/ja/category/community) Search ⌘ + K [Blog](https://api7.ai/blog) Ecosystem # Kubernetes Gateway API v1.0: 切り替えるべきか？ [![Navendu Pottekkat](https://avatars.githubusercontent.com/u/49474499?v=4)](https://github.com/pottekkat) [Navendu Pottekkat](https://github.com/pottekkat) December 15, 2023 [Ecosystem](https://api7.ai/category/ecosystem) [Kubernetes Gateway APIがv1.0リリース](https://kubernetes.io/blog/2023/10/31/gateway-api-ga/)されてから1ヶ月以上が経過し、主要なAPIが一般利用可能（GA）ステータスに昇格しました。 昨年、Gateway APIがベータ版に昇格した際に[Ingress APIとの比較について書きました](https://api7.ai/ja/blog/gateway-vs-ingress-api)が、1年経った今でも同じ疑問が残っています。Ingress APIからGateway APIに切り替えるべきでしょうか？ [昨年の私の答え](https://api7.ai/blog/gateway-vs-ingress-api#is-this-the-end-of-ingress-api)は「切り替えるべきではない」でした。そして、その理由は非常に強力なものでした。 当時、Gateway APIとその実装はまだ初期段階でした。一方、Ingress APIは安定しており、多くのユーザーにとって十分な主要なユースケースをカバーしていました。 より多くの機能を必要とするユーザーには、Ingressコントローラが提供するカスタムリソースを使用し、移植性（異なるIngress実装間での切り替え）を犠牲にすることを提案しました。 しかし、v1.0リリースにより、この状況が変わる可能性があります。Gateway APIは現在、はるかに強力になり、[20以上の実装](https://gateway-api.sigs.k8s.io/implementations/)が急速に追いついています。 したがって、新規に始める場合でIngressとGateway APIのどちらかを選ぶ必要があるなら、APIと[選択した実装](https://apisix.apache.org/docs/ingress-controller/tutorials/configure-ingress-with-gateway-api/)があなたが必要とするすべての機能をサポートしているのであれば、Gateway APIを選ぶことをお勧めします。 ## Ingress APIの問題点 [Ingress API](https://kubernetes.io/docs/concepts/services-networking/ingress/)は、一部の一般的なユースケースでは非常にうまく機能しますが、その機能を拡張するために、Ingress実装はカスタムアノテーションを使用し始めました。 例えば、Nginx Ingressを選択した場合、その[数十のアノテーション](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md)の一部を使用することになりますが、これらは[Apache APISIX](https://apisix.apache.org/docs/ingress-controller/concepts/annotations/)のような別の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](https://static.api7.ai/uploads/2023/12/08/winePDii_gateway-api.png?imageMogr2/format/webp) この[役割指向の設計](https://gateway-api.sigs.k8s.io/#why-does-a-role-oriented-api-matter)により、異なる人々がクラスタを使用しながらも制御を維持できます。 Gateway APIは、Ingress APIよりもはるかに多くの機能を備えています。Ingress APIではアノテーションが必要だった機能が、Gateway APIでは標準でサポートされています。 ## 公式の拡張機能 Gateway APIは公式のKubernetes APIですが、一連のCRDとして実装されています。 これはデフォルトのKubernetesリソースを使用するのと変わりませんが、[これらのCRDを公式の拡張機能としてインストールする](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api)必要があります。 ![APISIXのGateway APIサポート](https://static.api7.ai/uploads/2023/12/08/XllJX2YG_apisix-ingress.png?imageMogr2/format/webp) これにより、Kubernetesが長期的な安定性に向かってゆっくりと進む中で、迅速な反復が可能になります。 ## 普及するか？ [この有名なXKCDコミック](https://xkcd.com/927/)が頻繁に思い出させてくれるように、標準は増殖する傾向があります。 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)](https://smi-spec.io/)プロジェクトは、Kubernetesでのサービスメッシュの設定を標準化するための同様の試みでした。しかし、このプロジェクトはサービスメッシュプロジェクトの初期の関与の後、ほとんど注目されず、徐々に消えていきました。 SMIは、ユーザーがサービスメッシュに期待する多くの共通機能をサポートしていませんでした。また、これらの機能をサポートするために十分に迅速に動きませんでした。最終的に、サービスメッシュの実装はSMIへの準拠が遅れました（私は[CNCF TAG Network](https://github.com/cncf/tag-network)の下でSMIに密接に関わり、SMI準拠を報告するプロジェクトに取り組んでいました）。 これらは普遍的な理由ですが、このプロジェクトは現在、Gateway APIを通じて復活しています。[Gateway API for Mesh Management and Administration (GAMMA)イニシアチブ](https://gateway-api.sigs.k8s.io/#gateway-api-for-service-mesh-the-gamma-initiative)は、Gateway APIをサービスメッシュと連携させることを目指しています。 SMIプロジェクトは[最近GAMMAイニシアチブと統合されました](https://smi-spec.io/blog/announcing-smi-gateway-api-gamma/)、これはGateway APIにとって非常に良いことです。間違いなく最も人気のあるサービスメッシュであるIstioも、[Gateway APIが将来Istioを管理するためのデフォルトAPIになることを発表しました](https://istio.io/latest/blog/2022/gateway-api-beta/)。このような採用は、標準の増殖を防ぎます。 ## 移行ガイド [Gateway APIのドキュメント](https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/)には、IngressリソースをGatewayリソースに移行するための包括的なガイドがあります。それを繰り返す代わりに、[ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway)ツールを使用して、Ingressリソースを対応するGateway APIリソースに変換してみましょう。 [リリースページ](https://github.com/kubernetes-sigs/ingress2gateway/releases/tag/v0.1.0)から直接、お使いのオペレーティングシステム用のバイナリをダウンロードしてインストールできます。 以下のようなシンプルな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では、[スタンドアロンモード](https://apisix.apache.org/docs/apisix/next/deployment-modes/#standalone)でデプロイし、yamlファイルでルート設定を定義できます。このyamlファイルを従来のワークフローで更新でき、Kubernetes APIを介してゲートウェイ設定を管理する必要がないシナリオでは非常に役立ちます。 [実装固有のカスタムCRD](https://apisix.apache.org/docs/ingress-controller/tutorials/proxy-the-httpbin-service/)も、異なるソリューションに切り替える予定がない場合や、設定が小さくて簡単に移行できる場合には有効な代替手段です。 いずれにせよ、Gateway APIはここに残るでしょう。 Tags: [Gateway API](https://api7.ai/tags/gateway-api) [Kubernetes](https://api7.ai/tags/kubernetes) Share article link Share Related Posts [![Kubernetes GatewayとIngress APIの比較](https://static.api7.ai/uploads/2023/01/12/61sLscma_k8s.png)](https://api7.ai/blog/gateway-vs-ingress-api) ## [Kubernetes GatewayとIngress APIの比較](https://api7.ai/blog/gateway-vs-ingress-api) [![Apache APISIX 与 open-appsec WAF 集成](https://static.api7.ai/uploads/2024/10/18/8d1iVJWL_logo%20x%20open-appsec.png)](https://api7.ai/blog/apisix-integrates-with-open-appsec-waf) ## [Apache APISIX 与 open-appsec WAF 集成](https://api7.ai/blog/apisix-integrates-with-open-appsec-waf) Table of Contents - [Ingress APIの問題点](#ingress-api%E3%81%AE%E5%95%8F%E9%A1%8C%E7%82%B9) - [明らかな利点](#%E6%98%8E%E3%82%89%E3%81%8B%E3%81%AA%E5%88%A9%E7%82%B9) - [公式の拡張機能](#%E5%85%AC%E5%BC%8F%E3%81%AE%E6%8B%A1%E5%BC%B5%E6%A9%9F%E8%83%BD) - [普及するか？](#%E6%99%AE%E5%8F%8A%E3%81%99%E3%82%8B%E3%81%8B) - [移行ガイド](#%E7%A7%BB%E8%A1%8C%E3%82%AC%E3%82%A4%E3%83%89) - [代替手段](#%E4%BB%A3%E6%9B%BF%E6%89%8B%E6%AE%B5) ## Related Posts [![Kubernetes Gateway API の概要](https://static.api7.ai/uploads/2023/01/12/61sLscma_k8s.png)](https://api7.ai/ja/blog/a-quick-glance-at-the-kubernetes-gateway-api) Ecosystem September 7, 2022 #### [Kubernetes Gateway API の概要](https://api7.ai/ja/blog/a-quick-glance-at-the-kubernetes-gateway-api) 私の最近のブログ記事の1つで、いくつかの方法について説明しました... [Kubernetes](https://api7.ai/tags/kubernetes) [Gateway API](https://api7.ai/tags/gateway-api) [![APISIX Ingress Controller と AWS ACM の使用](https://static.api7.ai/uploads/2024/12/25/dCJQYedL_apisix-aws-certificate-manager.png)](https://api7.ai/ja/blog/using-apisix-ingress-with-aws-acm) Ecosystem December 30, 2022 #### [APISIX Ingress Controller と AWS ACM の使用](https://api7.ai/ja/blog/using-apisix-ingress-with-aws-acm) APISIX Ingress Controller が AWS ACM と連携し、Kubernetes で TLS 証明書を終端するための2つの設定方法（NLB と Ingress）について学びましょう。 [APISIX Ingress Controller](https://api7.ai/tags/apisix-ingress-controller) [AWS](https://api7.ai/tags/aws) [Kubernetes](https://api7.ai/tags/kubernetes) [![APISIX Ingress ControllerでGateway APIを使用する方法](https://static.api7.ai/uploads/2024/09/06/jTbR13pX_Gateway%20API.png)](https://api7.ai/ja/blog/how-to-use-gateway-api-in-apisix-ingress-controller) Products November 11, 2022 #### [APISIX Ingress ControllerでGateway APIを使用する方法](https://api7.ai/ja/blog/how-to-use-gateway-api-in-apisix-ingress-controller) 本記事では、外部にサービスを公開するための仕様であるKubernetes Gateway APIと、APISIX Ingress ControllerでGateway APIを使用する方法について紹介します。 [APISIX Ingress Controller](https://api7.ai/tags/apisix-ingress-controller) [Gateway API](https://api7.ai/tags/gateway-api) [Kubernetes](https://api7.ai/tags/kubernetes)