---
title: "Discussion on \"Migrating from ingress-nginx to Kubernetes Gateway API: A Complete Technical Guide\" | Hashnode"
description: "Discussion on \"Migrating from ingress-nginx to Kubernetes Gateway API: A Complete Technical Guide\". How to migrate from the archived ingress-nginx controller to Gateway API v1.4 using ingress2gateway 1.0, with zero downtime"
url: "https://hashnode.com/posts/migrating-from-ingress-nginx-to-kubernetes-gateway-api-a-complete-technical-guide/6a45921a39d1ef59af6692f8"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Migrating from ingress-nginx to Kubernetes Gateway API: A Complete Technical Guide](https://mateenali66.hashnode.dev/migrating-from-ingress-nginx-to-kubernetes-gateway-api-a-complete-technical-guide?utm_source=hashnode&utm_medium=feed)

How to migrate from the archived ingress-nginx controller to Gateway API v1.4 using ingress2gateway 1.0, with zero downtime

Jul 1 · 7 min read · mateenali66.hashnode.dev  
Read the article

-   [#kubernetes](https://hashnode.com/tag/kubernetes)
-   [#devops](https://hashnode.com/tag/devops)
-   [#gateway-api](https://hashnode.com/tag/gateway-api)
-   [#infrastructure](https://hashnode.com/tag/infrastructure)

## Written by

[Mateen Anjum](https://hashnode.com/@mateenali66)

@mateenali66 · Kitchener, ON, Canada

  
[View profile](https://hashnode.com/@mateenali66)

DevOps & Site Reliability Engineer building scalable cloud platforms across AWS, Azure, and Kubernetes.

Cloud DevOps/SRE engineer working with Kubernetes, GitHub Actions, Terraform, and distributed systems. I share practical guides, architecture patterns, and troubleshooting stories learned from running production systems.

## Responses 1

Markdown supported · ⌘↵ to post

[Edge Ops](https://hashnode.com/@edgecacheops)

[Nov 5](https://hashnode.com/posts/migrating-from-ingress-nginx-to-kubernetes-gateway-api-a-complete-technical-guide/6a45921a39d1ef59af6692f8/comment/6aec5c5b43cd4e50efdd8fb1)

When you leave Ingress NGINX for Gateway API, treat GatewayClass, Gateway listeners, and route parentRefs as the cutover surface, not a one-shot YAML rewrite. Pin one controller name on the GatewayClass, keep TLS termination on a single layer (LB, Gateway listener, or upstream), and migrate Host by Host so the old IngressClass still owns leftover rules until health checks and DNS agree. Empty Endpoints or a second controller claiming the same class usually look like random 502s even when the route object itself is valid.

Ops prove-out after the first Host moves: confirm the Gateway shows programmed addresses and Accepted routes, then hit the public Host and expect the upstream status rather than a default backend. If only one path fails, check Service port names versus the backend port and that pods stayed Ready. When routes vanish after a controller upgrade, verify parentRefs still match a Ready listener and that NetworkPolicies did not start dropping node-to-pod paths — most failed cutovers are class or parentRef mismatch, not the Gateway CRD shape.