Search for a command to run...
A practical framework for evaluating and migrating from deprecated ingress controllers to Gateway API or Envoy Gateway, including risk assessment and zero-downtime migration patterns.
Senior Freelancer & Technical Lead
Working as a Golang developer since 2020. Working as a mobile developer since 2013.
Focussed on architecture, testability and clean code. Open minded & product driven. Based in Rhede, available world-wide
No comments yet. Be the first to comment.
How to implement comprehensive software supply chain tracking using Open Component Model that captures dependencies, deployment artifacts, signatures, and version constraints across distributed systems.
How modern software supply chains use component models to track dependencies, artifacts, and metadata across distributed systems, moving beyond traditional SBOMs to comprehensive delivery tracking.
How to implement comprehensive software supply chain tracking using the Open Component Model that captures dependencies, deployment artifacts, configurations, and runtime bindings across multi-repository environments.
Master React performance optimization through systematic profiling, efficient rendering patterns, and smart bundle splitting strategies for production applications. Learn practical techniques that actually move the performance needle.
The Kubernetes community's announcement of Ingress NGINX's retirement in March 2026 has created an urgent need for migration planning across thousands of production clusters. With no security patches, bug fixes, or updates coming after the final v1.15.1 release, organizations must act now to avoid running unmaintained software with escalating security risks.
This isn't just about swapping one ingress controller for another. It's an opportunity to modernize your Kubernetes networking stack with better abstractions, improved security models, and future-proof architectures. This guide provides a practical framework for evaluating your options and executing a zero-downtime migration.
Before choosing a migration path, you need to audit what you're actually using. The migration assessment tool helps identify feature dependencies, but start with this basic check:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
If this returns pods, you're affected. Now catalog your ingress resources and their complexity:
kubectl get ingress --all-namespaces -o yaml > current-ingress-config.yaml
kubectl get configmap -n ingress-nginx ingress-nginx-controller -o yaml > current-configmap.yaml
Pay special attention to:
The complexity of these configurations will determine your migration strategy and timeline.
You have three primary migration targets, each with distinct trade-offs:
The most direct path for teams heavily invested in NGINX-specific features. NGINX Ingress Controller v5.4.0 introduces native validation and CORS support specifically to ease ingress-nginx migrations.
Best for: Organizations with complex NGINX configurations, custom snippets, or NGINX Plus licensing.
Migration complexity: Low to medium, depending on annotation usage.
The forward-looking choice that embraces Kubernetes' networking future. Gateway API provides role-based configuration, better traffic management primitives, and vendor neutrality.
Best for: Teams building new applications or willing to invest in modern Kubernetes networking patterns.
Migration complexity: Medium to high, requires rethinking traffic management concepts.
Platform-specific controllers that integrate deeply with cloud load balancers. AWS recommends migrating to AWS Load Balancer Controller first, then to Gateway API when ready.
Best for: Teams already committed to a specific cloud platform.
Migration complexity: Medium, with vendor lock-in considerations.
Evaluate each migration option against these critical factors:
Not every ingress-nginx feature has direct equivalents in alternative controllers. Create a feature mapping document:
# Example feature assessment
current_features:
- ssl_redirect: "nginx.ingress.kubernetes.io/ssl-redirect"
- rate_limiting: "nginx.ingress.kubernetes.io/rate-limit"
- custom_headers: "nginx.ingress.kubernetes.io/configuration-snippet"
migration_gaps:
nginx_controller:
- ssl_redirect: "Direct annotation support"
- rate_limiting: "VirtualServer CRD required"
- custom_headers: "Policy CRD recommended"
gateway_api:
- ssl_redirect: "HTTPRoute redirect filter"
- rate_limiting: "Implementation-specific policy"
- custom_headers: "ExtensionRef to controller policy"
Consider the blast radius of your migration:
Each migration path has different security characteristics:
Run both controllers simultaneously during the transition period. This approach minimizes risk but requires careful traffic management.
# Install new controller in separate namespace
kubectl create namespace nginx-ingress-new
# Deploy with different ingress class
helm install nginx-ingress-new nginx-stable/nginx-ingress \
--namespace nginx-ingress-new \
--set controller.ingressClass=nginx-new
Gradually migrate services by updating the ingressClassName field:
# Before
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-app
spec:
ingressClassName: nginx # Old controller
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
# After
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-app
spec:
ingressClassName: nginx-new # New controller
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
For organizations with sophisticated deployment pipelines, migrating entire clusters provides the cleanest separation.
# Create new cluster with target ingress controller
# Deploy applications to new cluster
# Switch DNS/load balancer traffic
# Decommission old cluster
This pattern works well with GitOps workflows where infrastructure and applications are versioned together.
When migrating to Gateway API, start with basic HTTP routing and gradually adopt advanced features:
# Phase 1: Basic routing
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example-app
spec:
parentRefs:
- name: example-gateway
hostnames:
- app.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: example-service
port: 80
# Phase 2: Add traffic policies
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example-app
spec:
parentRefs:
- name: example-gateway
hostnames:
- app.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /
filters:
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
backendRefs:
- name: example-service
port: 80
The NGINX Ingress Migration Tool provides automated assessment and conversion suggestions. For Gateway API migrations, consider tools like:
Many teams discover they're using dozens of controller-specific annotations. The NGINX documentation recommends a "CRD-first" approach, migrating to policy-based configuration instead of annotation sprawl.
Cloud controller migrations often result in new load balancer IPs. Plan DNS TTL reductions and consider using CNAME records pointing to load balancer hostnames instead of A records with IPs.
Not every ingress-nginx feature has direct equivalents. Document these gaps early and plan workarounds or application changes. Sometimes the "missing" feature represents an opportunity to simplify your architecture.
The ingress-nginx retirement forces a decision that many teams have been postponing. While disruptive in the short term, this migration presents an opportunity to modernize your Kubernetes networking stack with better security models, improved observability, and future-proof APIs.
Gateway API represents the future of Kubernetes networking, with growing ecosystem support and vendor adoption. Even if you choose an intermediate migration target like NGINX Ingress Controller or a cloud provider solution, plan for eventual Gateway API adoption as the standard matures.
The key to success is starting early, testing thoroughly, and migrating incrementally. The March 2026 deadline may seem distant, but complex production environments require months of planning and validation to ensure zero-downtime transitions.
Your future self will thank you for investing in this migration properly rather than rushing through it under deadline pressure.