なぜ今「IngressからGateway APIへ」なのか
K3s Gateway API 移行を検討し始めたきっかけは、多くの現場で同じだろう。Kubernetes SIG NetworkとSecurity Response Committeeは2025年11月、Ingress NGINXのベストエフォート保守を2026年3月までで打ち切ると発表した（Kubernetes公式ブログ）。それ以降は新しいリリースもバグ修正もセキュリティパッチも提供されない。既存のデプロイが即座に止まるわけではないが、「今のうちに移行先を決めておく」ことが現実的な選択になった。
移行先として公式に名指しされているのがGateway APIだ。Gateway APIは2023年10月にGAとなり、Ingressの後継として位置づけられている（Kubernetes公式ブログ: Gateway API GA）。Ingress時代のようにベンダー独自のアノテーションに頼るのではなく、重み付けルーティングやロール分離といった機能がAPI仕様そのものに組み込まれている点が大きな違いだ。
K3sユーザーにとって都合がいいのは、K3sにTraefikが標準搭載されていることだ。「じゃあTraefikを使っているK3sなら、もうGateway APIに対応しているのでは」と考えるのは自然だが、実際に手を動かしてみると、そう単純ではないことがすぐにわかる。こうしたネットワーキング周りの仕様変更への追従を手動で抱え込み続けるのか、それともKuboのようなマネージドK3sに任せるのかは、この記事を読み終えた後に考えてみてほしい論点の一つだ。
K3s標準のTraefikは「移行済み」ではない、という誤解
結論から言うと、K3sにTraefikが入っているからといって、Gateway APIがすぐ使えるわけではない。Traefik公式ドキュメントでは、Gateway APIを使うにはGateway API CRD（標準チャネル）を別途インストールし、さらにTraefik用のRBAC設定を追加する必要があると明記されている（Traefik公式ドキュメント）。Helm Chart経由でインストールしていればCRDとRBACは自動管理されるが、K3sの組み込みTraefik（Helm管理ではない簡易セットアップ）ではこの前提が崩れる。
つまり「TraefikがGateway APIに対応している」ことと「K3s環境でGateway APIがすぐ使える」ことの間には、CRDインストールという明確な一手間が存在する。ここを見落として「GatewayClassがない」「Gatewayリソースを作ってもProgrammedにならない」というエラーに最初にぶつかる人が多い。
K3sをアップグレードしたら起きたこと — Traefik v40の破壊的変更
もう一つ実務上のハマりどころがある。K3s v1.36系ではTraefikのHelm Chartがv40系に上がり、最新のv1.36.5+k3s1ではTraefik 3.7.13が採用されている（SUSE公式ドキュメント: K3s v1.36 リリースノート）。このv40.0.0には、ingress-nginxからの移行を見据えた設定項目名の変更という破壊的変更が含まれている。具体的には、プロバイダー名が kubernetesIngressNginx から kubernetesIngressNGINX に変わった（Traefik Helm Chart v40.0.0 リリースノート）。
ingress-nginxのアノテーションをTraefikに読み替える設定を組んでいた環境では、このアップグレードだけで「設定は変えていないのに、ある日突然ルーティングが効かなくなる」という事象が起こり得る。Gateway API移行を検討するタイミングは、同時にK3sそのもののアップグレードと重なることが多いため、この2つを切り離さずにセットで計画する必要がある。
こうしたマイナーバージョンアップに潜む破壊的変更を一件ずつ手動で追いかけるのは、インフラチームにとって地味に消耗する作業だ。KuboのAI-Driven Deploymentは、こうしたバージョン間の差分を踏まえた上でデプロイ指示を自然言語で出せるため、Captain UIで変更内容を可視化しながら進められる。
CanaryリリースがIngress時代と同じようにいかない
Ingress NGINXのアノテーション（canary-weight等）でカナリアリリースを組んでいたチームは、Gateway APIへの移行でもう一段のつまずきを経験する。Gateway APIのHTTPRouteは重み付けルーティングを仕様として標準搭載しているが、これはIngressのアノテーションとは別物の書き方になる。Datadog社のブログでも、Gateway APIは「設定をカスタムアノテーションから外し、HTTPRouteのような標準リソースに統合した」ため、既存のアノテーション設定を1対1で変換することはできないと指摘されている（Datadog公式ブログ）。
さらにK3s/Traefik環境特有の事情として、TraefikにはGateway API登場以前から独自のTraefikServiceというCRDがあり、重み付けロードバランシングやミラーリングを実現してきた（Traefik公式ドキュメント: TraefikService）。Argo Rolloutsのような段階的デプロイツールも、このTraefikServiceと連携してカナリアの重みを自動調整する仕組みを持っている（Argo Rollouts公式ドキュメント）。
ここで起きるのは「既存のカナリア構成はTraefikService＋IngressRouteという独自CRDの組み合わせで動いているのに、Gateway APIへ移行するとHTTPRouteという別のオブジェクトモデルで書き直す必要がある」という事態だ。Gateway API自体に機能が欠けているわけではなく、移行時に置き換えるべきリソースの種類が変わるという理解が必要になる。
証明書自動更新（cert-manager）との整合をどう取るか
K3sでcert-managerを使っている場合、ServiceLBがHTTP-01チャレンジ用のポートを横取りしてしまい証明書の自動更新が止まる、という問題は本ブログでも以前取り上げた。Gateway API経由にルーティングを切り替えると、証明書発行のトリガーとなるリソースがIngressからHTTPRoute/Gatewayに変わるため、cert-managerのCertificateリソースがどのリソースを見て発行判定をしているかを、移行のタイミングで必ず再確認する必要がある。IngressとHTTPRouteを並走させている間は、片方にしか証明書設定が反映されず「新しいルートだけTLSが効かない」という状態になりやすい。
Kuboはcert-manager + Let's Encryptをモニタリング（Prometheus + Grafana）と合わせて標準搭載しており、こうした証明書まわりの整合確認を含めた運用をあらかじめ組み込んだ状態で提供している。
移行は「一気に」ではなく「並走」で進める
Kong社の移行ガイドでは、IngressからGateway APIへの移行を一度に終わらせるのではなく、段階的に進めることを推奨している。具体的には、ingress2gatewayのようなツールで既存のIngressマニフェストをGateway/HTTPRouteに変換し、新しいGatewayがProgrammed状態になったことを確認したうえで、一部のリソースから少しずつ切り替えていくアプローチだ（Kong公式移行ガイド）。すべてを一度に削除せず、1つずつ検証しながら進めることが推奨されている点は、K3s環境でも同様に当てはまる。
K3sの場合は、これに「K3sそのもののバージョンアップとTraefikのバージョンアップが連動している」という事情が加わる。したがって現実的な順序は、(1) 現在のK3s/Traefikバージョンと対応するGateway APIのバージョンを確認する、(2) Gateway API CRDとRBACを導入する、(3) 一部のIngressをHTTPRouteに変換して並走させる、(4) カナリア・証明書まわりの検証を終えてから段階的に切り替える、という流れになる。
まとめ
K3sはTraefikを標準搭載しているぶん、「Gateway APIへの移行も簡単だろう」と思われがちだが、実際にはCRDの追加導入、K3sバージョンアップに伴うTraefikの破壊的変更、カナリアリリースのオブジェクトモデルの変更、証明書発行リソースの整合という、K3s特有の具体的な論点がいくつも存在する。ingress-nginxの保守終了という外部要因で移行を急かされている今こそ、こうした落とし穴を事前に押さえておく価値がある。
こうした移行作業や、K3sクラスタのバージョン追従そのものを手動で管理し続けるのは、インフラチームにとって小さくない負荷だ。KuboはK3sベースのマネージドKubernetesサービスで、AI-Driven DeploymentとCaptain UIにより、こうした構成変更を自然言語の指示と可視化された管理画面で安全に進められる。EKS/AKSのようなフルスペックのKubernetes機能を保ちながら、運用の複雑さを引き受けてくれる選択肢として検討してみてほしい。
Gateway API移行のようなネットワーキング変更は、本番環境で試行錯誤するにはリスクが大きい。KuboならPure Kubernetes準拠の環境で、GitOps（ArgoCD/Flux）とも標準で統合されているため、HTTPRouteへの段階移行もGit管理のワークフローに乗せて進められる。K3sの運用コストを下げながら本格的なKubernetesの機能を使いたい場合は、Kuboの料金プランでAWS EKS・Azure AKSとのコスト比較を確認してみるとよい。
もし「K3sの細かいバージョン管理やネットワーキングの検証にこれ以上工数を割けない」と感じているなら、お問い合わせからKuboの導入相談をしてみてはどうだろうか。