InfraAcademy Blog

Ingress-nginxが引退した2026年。Kubernetesの入口はGateway APIへどう移る？

公開日: 2026-09-04 更新日: 2026-09-04 | #ネットワーク #kubernetes #トレンド

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

2026年3月24日、Kubernetesの世界で長く使われてきたある部品が、静かに役目を終えました。Ingress-nginx というコントローラです。

名前を聞いてピンと来なくても、Kubernetesを触ったことがある人なら、知らないうちにお世話になっているかもしれません。外からのアクセスをクラスタの中のサービスへ振り分ける、いわば建物の入口を担ってきた部品だからです。

その入口が「これ以上メンテナンスしません」と宣言された。これは、地味だけれど無視できないニュースなのです。

今日は、なぜこの引退が起きたのか、そして後継として本命になった Gateway API とは何なのかを、できるだけやさしく整理していきます。

そもそもIngressって、何をしていたの？¶

Kubernetesは、たくさんのコンテナ（アプリの部品）をまとめて動かす仕組みです。そのあたりがまだあいまいな方は、先にKubernetesとは？オーケストレーションの概要やDockerの導入から目を通しておくと、この先がぐっと読みやすくなります。

クラスタの中では、アプリが Service という単位でまとまっています。ただ、それだけでは外の世界からアクセスできません。

たとえるなら、大きなオフィスビルを思い浮かべてください。中にはたくさんの会社（サービス）が入っています。でも、来訪者はいきなり各フロアに上がれませんよね。まず1階の受付に行き、「〇〇社さんはどこですか」と聞いて、案内してもらう。

この受付と案内係の役割を、Kubernetesで担ってきたのが Ingress です。

Ingressがやってくれていたこと¶

Ingressは、外から来たHTTP/HTTPSのリクエストを見て、URLのパスやホスト名に応じて「このリクエストはこのサービスへ」と振り分けます。

たとえば example.com/shop はショップのサービスへ、example.com/blog はブログのサービスへ、といった具合です。この「どこへ流すか」を書いたのが Ingress というマニフェスト（設定ファイル）でした。

ただし、Ingress はあくまでルールを書く紙にすぎません。その紙を読んで実際に交通整理をする係が別に必要で、それが Ingressコントローラ です。世界中でいちばん使われていたコントローラが、今回引退した Ingress-nginx でした。

TLS証明書の付け外しをどうするか、タイムアウトを何秒にするか。こうした細かい指示は、Ingressの標準機能に収まりきりません。そこで各コントローラは annotation（注釈）という欄に独自の指定を書かせてきました。

なぜIngress-nginxが引退したのか¶

理由はシンプルで、少し切ないものです。メンテナンスを続ける人が足りなくなったのです。

世界中で使われている一方で、コードを直し続けるボランティアの担い手が慢性的に不足していました。セキュリティ上の問題が見つかっても直せる人が限られる、という状態が続き、Kubernetesの運営チーム（SIG Networkとセキュリティ対応委員会）が正式に区切りをつけた、というのが今回の経緯です。

引退したからといって、いま動いているクラスタが即座に止まるわけではありません。既存のデプロイは動き続け、インストール用のファイルも残ります。

ただし、引退後は新しいリリースも、バグ修正も、セキュリティパッチも提供されません。つまり、新しい脆弱性が見つかっても誰も直してくれない。入口を守る係が、更新を止めたまま立ち続けている状態です。

これは運用の視点では静かなリスクです。今日壊れなくても、半年後、一年後に「直せない穴」を抱え続けることになります。だから、慌てず、しかし着実に、次を考える必要があるわけです。

似た話は、ソフトウェアの世界でときどき起こります。とても便利で、みんなが当たり前に使っているのに、それを陰で支える人が少ない。その状態が続くと、ある日ふっと灯が消えてしまう。今回の引退は、オープンソースという仕組みの光と影を、あらためて教えてくれる出来事でもありました。使う側の私たちも、ただ使うだけでなく、何に支えられているのかを少し意識しておきたいところです。

後継の本命、Gateway APIとは？¶

では、次は何を使うのか。Kubernetesプロジェクトが「Ingressの後継」として育ててきたのが Gateway API です。2023年10月31日に主要な部品が正式版（GA）となり、2026年時点では標準的な選択肢として定着しました。

名前が似ているので紛らわしいのですが、Ingressとは設計思想からして別物です。単なる後継の新バージョン、というよりも、考え方をいちど作り直したもの、と捉えたほうが近いでしょう。何が新しいのか、二つの軸で見てみましょう。

役割ごとに設定を分ける、という発想¶

いちばん大きな違いは、関わる人の役割で設定を分けたことです。

さきほどのビルのたとえで言えば、Ingressは受付の設定を一枚の紙に全部書いていました。ビルの設備担当も、フロアを貸す管理会社も、入居している会社も、みんな同じ紙に書き込む。だから紙がごちゃごちゃになりがちでした。

Gateway APIは、この紙を三枚に分けます。

部品	担当する人	決めること
GatewayClass	基盤・インフラの提供側	どの実装（部品の種類）を使うか
Gateway	クラスタの運用担当	入口の口（ポート・TLS・受け入れ範囲）
HTTPRoute	アプリの開発者	どのパスをどのサービスへ流すか

こうして分けると、アプリ開発者は自分の担当する HTTPRoute だけを触ればよくなります。クラスタ全体のTLS設定を触ってしまう、といった事故が起きにくい。役割の境界がそのまま設定の境界になるわけです。

これは、少し大きめの組織ほどありがたみが分かります。基盤チームと開発チームが分かれている現場では、「誰がどこまで触っていいのか」が曖昧だと、変更のたびに確認や調整が必要になり、スピードが落ちます。Gateway APIのように部品ごとに担当が決まっていれば、開発者は基盤チームを待たずに自分のルートを足せますし、基盤チームは入口の安全な部分だけをしっかり管理できます。お互いの領域を踏まないから、余計な衝突が減るのです。

annotationの沼から抜け出す¶

もう一つの違いは、表現力です。

Ingressで細かい制御をしようとすると、コントローラごとにバラバラの annotation を書く必要がありました。あるコントローラで動いた設定が、別のコントローラでは通じない。これでは移行のたびに書き直しです。

Gateway APIは、こうした「あると便利な機能」を最初から標準の仕様に取り込みました。パスやヘッダーでの振り分け、トラフィックを重み付けして分けるカナリアリリース、ヘッダーの書き換え。これらが annotation の裏技ではなく、正式なフィールドとして書けます。

実際の HTTPRoute は、こんなふうに読みやすい形になります。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /shop
      backendRefs:
        - name: shop-service
          port: 8080

/shop で始まるリクエストを shop-service へ流す、と素直に読めますよね。どこがパスの条件で、どこが流し先なのか。設定を初めて見る人でも、なんとなく意味を追えるのではないでしょうか。この読みやすさは、チームで運用するうえで地味に効いてきます。

しかもこの標準化のおかげで、Envoy Gateway・Istio・Cilium・kgatewayなど、いろいろな実装が同じ書き方で動くようになりました。実装を乗り換えても、書いた設定の大部分はそのまま使えます。特定の製品に縛られにくい、というのは、長く付き合う基盤ほど効いてくる安心感です。

引退後、私たちは何をすればいい？¶

「では明日から全部Gateway APIに書き換えるのか」というと、そこまで急ぐ必要はありません。落ち着いて順番に進めましょう。

まず知っておきたいのは、Ingress という仕組み自体は廃止されていないことです。今後の新機能追加は止まる（機能凍結）ものの、APIとして削除されたわけではありません。引退したのは、あくまで Ingress-nginx という一つのコントローラです。

だから選択肢は、大きく二つに分かれます。

Ingressのまま、別のコントローラに乗り換える：Traefikなど、Ingressを引き続き扱えるコントローラへ移る。書き換えが少なく、当面の延命としては現実的です。
Gateway APIへ移行する：将来の標準に合わせる。Envoy GatewayやCilium、クラウド事業者が提供するコントローラなど、実装は豊富です。

どちらが正解ということはなく、チームの体力と時期で選べばよいと思います。ただ、新しく作るなら最初からGateway APIを選んでおくのが、いちばん手戻りが少ないでしょう。

判断に迷ったら、まず自分たちの入口がどれだけ複雑かを見てみてください。単純なパス振り分けしかしていないなら、移行はそれほど大変ではありません。一方で、annotation を駆使して細かい制御を積み上げてきた現場ほど、一つひとつの設定が何のためにあるのかを棚卸しする作業が待っています。逆に言えば、これは設定を見直す良い機会でもあります。「昔つけたけれど、今はもう要らない指定」が、案外たくさん見つかるものです。入口の引っ越しは、荷造りのついでに不要な荷物を捨てられる、ちょっとした断捨離のチャンスだと思えば、少し前向きになれるはずです。

移行を助けるツール Ingress2Gateway¶

「今ある大量のIngress設定を、一から書き直すのは無理…」という声が聞こえてきそうです。そこでKubernetesコミュニティは、移行を助ける公式ツール Ingress2Gateway を用意しました。2026年3月にバージョン1.0が公開されています。

これは、既存の Ingress の定義を読み込んで、対応する Gateway と HTTPRoute に自動変換してくれる道具です。もちろん全部が完璧に変換できるわけではなく、独自の annotation は人の手で確認が要ります。それでも、たたき台を機械が作ってくれるだけで、移行のハードルはずいぶん下がります。ゼロから書き起こすのと、下書きを直すのとでは、心理的な重さがまるで違いますよね。

進め方としては、まず本番ではない検証用のクラスタで変換ツールを走らせ、生成された HTTPRoute を目で確認するところから始めるのがおすすめです。そこで挙動を確かめてから、影響の小さいサービスを一つだけ新しい入口に載せ替えてみる。問題がなければ、次のサービスへ。この「小さく試して、少しずつ広げる」やり方なら、大きな事故を避けながら着実に前へ進めます。

移行は「一気に全部」ではなく「新しいものからGateway API、古いものは変換ツールで少しずつ」が現実的です。入口を替える工事は、営業を止めずに進めたいですからね。

慌てないための下ごしらえ¶

移行そのものより前に、足元を固めておくと安心です。トラフィックがどこをどう流れているのかを把握できていないと、入口を替えたときに何が壊れたか分からなくなります。

このあたりは、ルーティングの基本やネットワークの始め方で扱ってきた考え方がそのまま効いてきます。パケットがどこへ向かうのかを追えること。それが、こうした基盤の入れ替えを怖くなくする土台です。

あわせて、変更の前後で挙動を比べられるように、監視の仕組みも整えておきたいところです。オブザーバビリティ（可観測性）や、設定変更をGit経由で安全に流すGitOpsの考え方を組み合わせると、入口の入れ替えのような大きな工事も、記録を残しながら落ち着いて進められます。

こうしたクラウドネイティブの土台を体系立てて学びたい方は、InfraAcademyのネットワーク学習ロードマップから始めてみてください。Ingressの裏側にあるルーティングやDNSといった基礎から順番に積み上げれば、Gateway APIのような新しい仕組みも「なるほど、そういうことか」と腹落ちするようになります。