[{"data":1,"prerenderedAt":325},["ShallowReactive",2],{"blog-ja-k3s-ingress-gateway-api-migration-traefik-gap":3,"blog-related-ja-k3s-ingress-gateway-api-migration-traefik-gap":273,"blog-ja-k3s-ingress-gateway-api-migration-traefik-gap-alt":261},{"id":4,"title":5,"author":6,"body":7,"date":255,"description":256,"extension":257,"image":258,"locale":259,"meta":260,"navigation":261,"path":262,"seo":263,"stem":264,"tags":265,"__hash__":272},"blog\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap.md","Ingressはもう終わる。Gateway APIに移行したら、K3sのTraefikは半分しか乗り換えられなかった","Kubo Team",{"type":8,"value":9,"toc":244},"minimark",[10,15,27,36,45,52,56,65,68,74,78,102,105,112,118,122,134,152,160,166,170,177,183,187,200,203,209,212,215,222,235],[11,12,14],"h2",{"id":13},"なぜ今ingressからgateway-apiへなのか","なぜ今「IngressからGateway APIへ」なのか",[16,17,18,19,26],"p",{},"K3s Gateway API 移行を検討し始めたきっかけは、多くの現場で同じだろう。Kubernetes SIG NetworkとSecurity Response Committeeは2025年11月、Ingress NGINXのベストエフォート保守を2026年3月までで打ち切ると発表した（",[20,21,25],"a",{"href":22,"rel":23},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F11\u002F11\u002Fingress-Nginx-retirement\u002F",[24],"nofollow","Kubernetes公式ブログ","）。それ以降は新しいリリースもバグ修正もセキュリティパッチも提供されない。既存のデプロイが即座に止まるわけではないが、「今のうちに移行先を決めておく」ことが現実的な選択になった。",[16,28,29,30,35],{},"移行先として公式に名指しされているのがGateway APIだ。Gateway APIは2023年10月にGAとなり、Ingressの後継として位置づけられている（",[20,31,34],{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2023\u002F10\u002F31\u002Fgateway-api-ga\u002F",[24],"Kubernetes公式ブログ: Gateway API GA","）。Ingress時代のようにベンダー独自のアノテーションに頼るのではなく、重み付けルーティングやロール分離といった機能がAPI仕様そのものに組み込まれている点が大きな違いだ。",[16,37,38,39,44],{},"K3sユーザーにとって都合がいいのは、K3sにTraefikが標準搭載されていることだ。「じゃあTraefikを使っているK3sなら、もうGateway APIに対応しているのでは」と考えるのは自然だが、実際に手を動かしてみると、そう単純ではないことがすぐにわかる。こうしたネットワーキング周りの仕様変更への追従を手動で抱え込み続けるのか、それとも",[20,40,43],{"href":41,"rel":42},"https:\u002F\u002Fkubo.hexabase.io\u002F",[24],"Kubo","のようなマネージドK3sに任せるのかは、この記事を読み終えた後に考えてみてほしい論点の一つだ。",[16,46,47],{},[48,49],"img",{"alt":50,"src":51},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap\u002Fsection01.webp",[11,53,55],{"id":54},"k3s標準のtraefikは移行済みではないという誤解","K3s標準のTraefikは「移行済み」ではない、という誤解",[16,57,58,59,64],{},"結論から言うと、K3sにTraefikが入っているからといって、Gateway APIがすぐ使えるわけではない。Traefik公式ドキュメントでは、Gateway APIを使うにはGateway API CRD（標準チャネル）を別途インストールし、さらにTraefik用のRBAC設定を追加する必要があると明記されている（",[20,60,63],{"href":61,"rel":62},"https:\u002F\u002Fdoc.traefik.io\u002Ftraefik\u002Fv3.5\u002Freference\u002Finstall-configuration\u002Fproviders\u002Fkubernetes\u002Fkubernetes-gateway\u002F",[24],"Traefik公式ドキュメント","）。Helm Chart経由でインストールしていればCRDとRBACは自動管理されるが、K3sの組み込みTraefik（Helm管理ではない簡易セットアップ）ではこの前提が崩れる。",[16,66,67],{},"つまり「TraefikがGateway APIに対応している」ことと「K3s環境でGateway APIがすぐ使える」ことの間には、CRDインストールという明確な一手間が存在する。ここを見落として「GatewayClassがない」「Gatewayリソースを作ってもProgrammedにならない」というエラーに最初にぶつかる人が多い。",[16,69,70],{},[48,71],{"alt":72,"src":73},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap\u002Fsection02.webp",[11,75,77],{"id":76},"k3sをアップグレードしたら起きたこと-traefik-v40の破壊的変更","K3sをアップグレードしたら起きたこと — Traefik v40の破壊的変更",[16,79,80,81,86,87,91,92,95,96,101],{},"もう一つ実務上のハマりどころがある。K3s v1.36系ではTraefikのHelm Chartがv40系に上がり、最新のv1.36.5+k3s1ではTraefik 3.7.13が採用されている（",[20,82,85],{"href":83,"rel":84},"https:\u002F\u002Fdocumentation.suse.com\u002Fcloudnative\u002Fk3s\u002Flatest\u002Fes\u002Frelease-notes\u002Fv1.36.X.html",[24],"SUSE公式ドキュメント: K3s v1.36 リリースノート","）。このv40.0.0には、ingress-nginxからの移行を見据えた設定項目名の変更という破壊的変更が含まれている。具体的には、プロバイダー名が ",[88,89,90],"code",{},"kubernetesIngressNginx"," から ",[88,93,94],{},"kubernetesIngressNGINX"," に変わった（",[20,97,100],{"href":98,"rel":99},"https:\u002F\u002Fgithub.com\u002Ftraefik\u002Ftraefik-helm-chart\u002Freleases\u002Ftag\u002Fv40.0.0",[24],"Traefik Helm Chart v40.0.0 リリースノート","）。",[16,103,104],{},"ingress-nginxのアノテーションをTraefikに読み替える設定を組んでいた環境では、このアップグレードだけで「設定は変えていないのに、ある日突然ルーティングが効かなくなる」という事象が起こり得る。Gateway API移行を検討するタイミングは、同時にK3sそのもののアップグレードと重なることが多いため、この2つを切り離さずにセットで計画する必要がある。",[16,106,107,108,111],{},"こうしたマイナーバージョンアップに潜む破壊的変更を一件ずつ手動で追いかけるのは、インフラチームにとって地味に消耗する作業だ。",[20,109,43],{"href":41,"rel":110},[24],"のAI-Driven Deploymentは、こうしたバージョン間の差分を踏まえた上でデプロイ指示を自然言語で出せるため、Captain UIで変更内容を可視化しながら進められる。",[16,113,114],{},[48,115],{"alt":116,"src":117},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap\u002Fsection03.webp",[11,119,121],{"id":120},"canaryリリースがingress時代と同じようにいかない","CanaryリリースがIngress時代と同じようにいかない",[16,123,124,125,128,129,101],{},"Ingress NGINXのアノテーション（",[88,126,127],{},"canary-weight","等）でカナリアリリースを組んでいたチームは、Gateway APIへの移行でもう一段のつまずきを経験する。Gateway APIのHTTPRouteは重み付けルーティングを仕様として標準搭載しているが、これはIngressのアノテーションとは別物の書き方になる。Datadog社のブログでも、Gateway APIは「設定をカスタムアノテーションから外し、HTTPRouteのような標準リソースに統合した」ため、既存のアノテーション設定を1対1で変換することはできないと指摘されている（",[20,130,133],{"href":131,"rel":132},"https:\u002F\u002Fwww.datadoghq.com\u002Fblog\u002Fmigrate-to-gateway-api\u002F",[24],"Datadog公式ブログ",[16,135,136,137,140,141,146,147,101],{},"さらにK3s\u002FTraefik環境特有の事情として、TraefikにはGateway API登場以前から独自の",[88,138,139],{},"TraefikService","というCRDがあり、重み付けロードバランシングやミラーリングを実現してきた（",[20,142,145],{"href":143,"rel":144},"https:\u002F\u002Fdoc.traefik.io\u002Ftraefik\u002Freference\u002Frouting-configuration\u002Fkubernetes\u002Fcrd\u002Fhttp\u002Ftraefikservice\u002F",[24],"Traefik公式ドキュメント: TraefikService","）。Argo Rolloutsのような段階的デプロイツールも、このTraefikServiceと連携してカナリアの重みを自動調整する仕組みを持っている（",[20,148,151],{"href":149,"rel":150},"https:\u002F\u002Fargo-rollouts.readthedocs.io\u002Fen\u002Flatest\u002Ffeatures\u002Ftraffic-management\u002Ftraefik\u002F",[24],"Argo Rollouts公式ドキュメント",[16,153,154,155,159],{},"ここで起きるのは「既存のカナリア構成はTraefikService＋IngressRouteという独自CRDの組み合わせで動いているのに、Gateway APIへ移行するとHTTPRouteという別のオブジェクトモデルで書き直す必要がある」という事態だ。Gateway API自体に機能が欠けているわけではなく、",[156,157,158],"strong",{},"移行時に置き換えるべきリソースの種類が変わる","という理解が必要になる。",[16,161,162],{},[48,163],{"alt":164,"src":165},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap\u002Fsection04.webp",[11,167,169],{"id":168},"証明書自動更新cert-managerとの整合をどう取るか","証明書自動更新（cert-manager）との整合をどう取るか",[16,171,172,173,176],{},"K3sでcert-managerを使っている場合、ServiceLBがHTTP-01チャレンジ用のポートを横取りしてしまい証明書の自動更新が止まる、という問題は本ブログでも以前取り上げた。Gateway API経由にルーティングを切り替えると、証明書発行のトリガーとなるリソースがIngressからHTTPRoute\u002FGatewayに変わるため、cert-managerの",[88,174,175],{},"Certificate","リソースがどのリソースを見て発行判定をしているかを、移行のタイミングで必ず再確認する必要がある。IngressとHTTPRouteを並走させている間は、片方にしか証明書設定が反映されず「新しいルートだけTLSが効かない」という状態になりやすい。",[16,178,179,182],{},[20,180,43],{"href":41,"rel":181},[24],"はcert-manager + Let's Encryptをモニタリング（Prometheus + Grafana）と合わせて標準搭載しており、こうした証明書まわりの整合確認を含めた運用をあらかじめ組み込んだ状態で提供している。",[11,184,186],{"id":185},"移行は一気にではなく並走で進める","移行は「一気に」ではなく「並走」で進める",[16,188,189,190,193,194,199],{},"Kong社の移行ガイドでは、IngressからGateway APIへの移行を一度に終わらせるのではなく、段階的に進めることを推奨している。具体的には、ingress2gatewayのようなツールで既存のIngressマニフェストをGateway\u002FHTTPRouteに変換し、新しいGatewayが",[88,191,192],{},"Programmed","状態になったことを確認したうえで、一部のリソースから少しずつ切り替えていくアプローチだ（",[20,195,198],{"href":196,"rel":197},"https:\u002F\u002Fdeveloper.konghq.com\u002Fkubernetes-ingress-controller\u002Fmigrate\u002Fingress-to-gateway\u002F",[24],"Kong公式移行ガイド","）。すべてを一度に削除せず、1つずつ検証しながら進めることが推奨されている点は、K3s環境でも同様に当てはまる。",[16,201,202],{},"K3sの場合は、これに「K3sそのもののバージョンアップとTraefikのバージョンアップが連動している」という事情が加わる。したがって現実的な順序は、(1) 現在のK3s\u002FTraefikバージョンと対応するGateway APIのバージョンを確認する、(2) Gateway API CRDとRBACを導入する、(3) 一部のIngressをHTTPRouteに変換して並走させる、(4) カナリア・証明書まわりの検証を終えてから段階的に切り替える、という流れになる。",[16,204,205],{},[48,206],{"alt":207,"src":208},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap\u002Fsection05.webp",[11,210,211],{"id":211},"まとめ",[16,213,214],{},"K3sはTraefikを標準搭載しているぶん、「Gateway APIへの移行も簡単だろう」と思われがちだが、実際にはCRDの追加導入、K3sバージョンアップに伴うTraefikの破壊的変更、カナリアリリースのオブジェクトモデルの変更、証明書発行リソースの整合という、K3s特有の具体的な論点がいくつも存在する。ingress-nginxの保守終了という外部要因で移行を急かされている今こそ、こうした落とし穴を事前に押さえておく価値がある。",[16,216,217,218,221],{},"こうした移行作業や、K3sクラスタのバージョン追従そのものを手動で管理し続けるのは、インフラチームにとって小さくない負荷だ。",[20,219,43],{"href":41,"rel":220},[24],"はK3sベースのマネージドKubernetesサービスで、AI-Driven DeploymentとCaptain UIにより、こうした構成変更を自然言語の指示と可視化された管理画面で安全に進められる。EKS\u002FAKSのようなフルスペックのKubernetes機能を保ちながら、運用の複雑さを引き受けてくれる選択肢として検討してみてほしい。",[16,223,224,225,228,229,234],{},"Gateway API移行のようなネットワーキング変更は、本番環境で試行錯誤するにはリスクが大きい。",[20,226,43],{"href":41,"rel":227},[24],"ならPure Kubernetes準拠の環境で、GitOps（ArgoCD\u002FFlux）とも標準で統合されているため、HTTPRouteへの段階移行もGit管理のワークフローに乗せて進められる。K3sの運用コストを下げながら本格的なKubernetesの機能を使いたい場合は、",[20,230,233],{"href":231,"rel":232},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[24],"Kuboの料金プラン","でAWS EKS・Azure AKSとのコスト比較を確認してみるとよい。",[16,236,237,238,243],{},"もし「K3sの細かいバージョン管理やネットワーキングの検証にこれ以上工数を割けない」と感じているなら、",[20,239,242],{"href":240,"rel":241},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[24],"お問い合わせ","からKuboの導入相談をしてみてはどうだろうか。",{"title":245,"searchDepth":246,"depth":246,"links":247},"",2,[248,249,250,251,252,253,254],{"id":13,"depth":246,"text":14},{"id":54,"depth":246,"text":55},{"id":76,"depth":246,"text":77},{"id":120,"depth":246,"text":121},{"id":168,"depth":246,"text":169},{"id":185,"depth":246,"text":186},{"id":211,"depth":246,"text":211},"2026-10-10","K3s Gateway API 移行を試みると、標準搭載のTraefikでもCRD未導入・Canary設定の作り直し・証明書連携の見直しが必要になる。2026年のingress-nginx退役とKubernetes 1.36移行を踏まえ、K3s特有の落とし穴と実務対応をまとめた。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap",{"title":5,"description":256},"blog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap",[266,267,268,269,270,271],"k3s","kubernetes","gateway-api","traefik","ingress","networking","hQpbN3DlAE6CQ1qN2OKrW6N1PW6np8abZUKixiEwWTs",[274,285,294,302,309,317],{"path":275,"title":276,"description":277,"date":278,"tags":279},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[266,267,280,281,282,283,284,271],"cni","flannel","calico","cilium","networkpolicy",{"path":286,"title":287,"description":288,"date":289,"tags":290},"\u002Fblog\u002Fja\u002Fk3s-traefik-servicelb-ingress-nginx-port-conflict","K3sのTraefikを無効化したはずなのに、ingress-nginxが443番を取れない。ServiceLBという見えない同居人","K3sでTraefik無効化を実行したのにingress-nginxが443番ポートを取れない――原因はServiceLB(klipper-lb)というもう一つのデフォルトコンポーネント。診断から正しい無効化手順、MetalLB併用時の注意まで解説する。","2026-09-19",[266,267,269,291,292,293],"servicelb","ingress-nginx","load-balancer",{"path":295,"title":296,"description":297,"date":298,"tags":299},"\u002Fblog\u002Fja\u002Fk3s-flannel-vxlan-overlay-mtu-troubleshooting","pingは通るのにHTTPだけ詰まる。K3sのFlannel VXLANオーバーレイネットワークがMTUで壊れる理由","K3sクラスタでpingは通るのにHTTPリクエストだけ詰まる——それはVXLANオーバーレイネットワークのMTU不整合が原因かもしれない。Flannel\u002FCalicoのMTU設計、PMTUブラックホールの正体、3ステップの診断手順とクラウド別の恒久対策までを解説する。","2026-09-01",[266,267,271,300,281,301],"vxlan","mtu",{"path":303,"title":304,"description":305,"date":306,"tags":307},"\u002Fblog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf","OSPFなら1分で直る障害が、KubernetesのCNIだと半日かかる理由","Kubernetesのオーバーレイネットワークはなぜトラブルシューティングに時間がかかるのか。CNIの仕組み、Flannel VXLANとCalico BGPの違い、MTU不一致の切り分け手順まで、K3s運用者が押さえるべきポイントを解説する。","2026-08-16",[266,267,280,308,271],"overlay-network",{"path":310,"title":311,"description":312,"date":313,"tags":314},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[266,267,315,271,316],"kubevirt","managed-kubernetes",{"path":318,"title":319,"description":320,"date":321,"tags":322},"\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer","サブネットは計算できるのに、Podは繋がらない。Kubernetesネットワーキングで最初にハマる壁","サブネット設計は得意なのに、なぜKubernetesのPod間通信では毎回つまずくのか。CNI・Service Mesh・NetworkPolicyというKubernetesネットワーキングの基礎を、伝統的なネットワーク設計の知識と対比しながら整理する。","2026-07-22",[267,266,271,280,323,324],"service-mesh","network-policy",1792592607201]