Azure Kubernetes Service (AKS) can expose web applications through Kubernetes Services and traffic-routing controllers, but an older popular implementation is no longer a safe default. The Kubernetes project retired its community Ingress NGINX controller in March 2026, ending maintenance and security fixes. The Kubernetes Ingress API itself remains supported, while separately maintained NGINX-branded products have different lifecycles. This updated guide explains how to assess a maintained routing implementation and migrate without recommending the old controller’s installation commands.
Identify the actual controller and its support status
A Kubernetes Ingress resource expresses routing intent, such as mapping a hostname and URL path to a backend Service. It does not itself run the reverse proxy that handles traffic. An Ingress controller must interpret those resources and provide a data plane. The community ingress-nginx implementation had a long operational history, but the Kubernetes Steering and Security Response Committees explicitly warned that no new fixes would be issued after its retirement. A Helm release might continue forwarding requests even though it no longer receives security patches. Continued packet delivery is not evidence of an acceptable production security posture.
Before migration, inventory the controller image, deployment namespace, Helm chart and version, public or private endpoints, TLS certificates, annotations, snippets, and team responsible for upgrades. Distinguish ingress-nginx from other NGINX offerings whose maintainers provide separate support. Do not infer identical maintenance from a product name or configuration syntax. Evaluate candidate implementations against the vendor’s current support policy, required security controls, AKS compatibility, operational ownership and feature coverage. The historical lesson is useful, but the original installation command is not a sensible new production recommendation.
Trace the request through Azure and Kubernetes
An application Deployment maintains Pods, a Kubernetes Service provides a stable destination for selected endpoints, and a Gateway or Ingress controller directs client requests to that Service. Depending on architecture, Azure Load Balancer, a public IP, a private endpoint, DNS, network security groups and virtual network routes may also participate. Draw a concrete path from a client hostname to the Azure entry point, gateway, Service and ready application Pod. Mark where TLS terminates and whether it must be established again for backend traffic. A healthy AKS control plane can coexist with a broken application entry path.
Test the path in a nonproduction environment. Start with a known healthy service, send a request through the intended hostname, and record the response. Change the backend Service name to an invalid value and observe controller conditions, logs and client status. Restore the name, then deliberately make one Pod unready. Distinguish a routing failure from missing Service endpoints or failed application initialization before changing unrelated infrastructure. The Azure Kubernetes Service architecture helps explain which resources belong to the cluster platform and which are owned by the application team.
Inventory route behavior before migrating
Ingress-nginx installations often configured redirect behavior, rewrite rules, header forwarding, timeouts, request-body limits, rate controls or session affinity through annotations or controller configuration. Those details may not map directly to a new Gateway API implementation. Begin with a full inventory of Ingress objects, hostnames, certificate secrets, path rules, controller-specific extensions and applications affected by the same shared entry point. Separate portable API behavior from features that are specific to the retired controller. A replacement that faithfully copies only the visible hostnames may accidentally remove a security or routing control that a business workflow depended upon.
Plan a parallel test path where feasible. Deploy a supported alternative in a staging cluster or isolated entry point, recreate representative route rules, and test real requests with controlled hostnames. Check HTTP status codes, redirect targets, forwarded headers, TLS validation, multi-path precedence and session handling. If a production cutover is needed, account for DNS caching and the possibility that different clients reach different entry points temporarily. Establish who can authorize changes and how rollback would work. Returning temporarily to an unsupported implementation may be an emergency contingency, but it should not be the long-term security architecture.
Understand Gateway API responsibility boundaries
Gateway API separates infrastructure from application routing through resources such as GatewayClass, Gateway and HTTPRoute. A platform team can manage which supported controller supplies entry infrastructure, while application teams manage permitted routes to their Kubernetes Services. That model helps reduce the need for every application owner to edit global proxy settings. A Gateway resource expresses intended listeners and associated route policies; it does not automatically prove that traffic is reachable. A real implementation must reconcile the resources and configure the network data plane appropriately.
Confirm the version, conformance level and implementation-specific options before choosing the controller. Header matching, weighted traffic distribution, TLS options and cross-namespace references may differ among providers and releases. An accepted HTTPRoute is only one part of an end-to-end test; a service can still have no endpoints, a DNS record can be wrong, or an Azure network rule may block access. The Kubernetes cluster architecture framework is useful for separating declarative desired state, controller reconciliation and the actual application network path. Do not assume API portability guarantees that every feature of a retired controller has an exact replacement.
Keep TLS, identity and network authorization separate
A certificate used for HTTPS establishes and protects the connection where it is configured; it does not decide whether a signed-in user may read a particular business record. Define the TLS termination point, backend re-encryption requirements, secret storage, certificate ownership and renewal process. Restrict who can update listeners and routes in shared namespaces. For applications using Azure services, prefer supported workload identities with narrow permissions to long-lived credentials embedded in container images. Review key access and route changes as independent security decisions, since the compromise of an entry point can affect multiple workloads.
Network isolation also depends on the chosen AKS networking implementation. Kubernetes NetworkPolicies need appropriate enforcement, while Azure virtual networks, network security groups, DNS and private connectivity may impose additional boundaries. A public gateway should be able to reach the intended Service without becoming a path to unrelated administrative workloads. Test an allowed request and a deliberately denied request in an authorized environment. Do not confuse a Pod that reports Ready, a Gateway that reports an accepted route, a successful TLS handshake, and a properly authorized application transaction: they represent different layers that can succeed or fail independently.
Test reliability and operational failure paths
Use a test application that exposes an endpoint reporting both health and deployment version. Configure a Service and a supported controller with one known hostname and path. Verify that requests reach the expected version. Introduce a wrong selector or remove one healthy backend and watch how the endpoint set and user responses change. If a gateway is programmed but clients receive a 503, check backend readiness, Service selector behavior and controller logs. If clients cannot connect at all, investigate public or private DNS, IP assignment, firewall decisions and Azure routing before altering application code.
A liveness probe helps Kubernetes decide when to restart a container that cannot recover, while a readiness probe helps decide whether a Pod receives normal Service traffic. These are not interchangeable with external gateway health or a security policy. A badly configured liveness probe can trigger repeated restarts and make an outage worse. The readiness and liveness probes concepts show why an application might be running without being ready to accept requests. During migration, check whether both the new controller and the workload use health criteria that reflect real application functionality rather than merely an open TCP port.
Operate the gateway as critical shared infrastructure
The selected controller should have an identified platform owner, a supported image and chart upgrade process, capacity limits, security scanning, and operational telemetry. Monitor request failure rate, gateway latency, certificate expiry, reconciliation errors and controller restarts. Keep access logs useful without retaining sensitive headers or personal data unnecessarily. An unsupported component cannot be made fully safe just by placing a firewall in front of it. Treat migration away from retired ingress-nginx as a planned security and availability change, with staged tests and a documented decision about when the old infrastructure can be removed.
Entry-point infrastructure also has financial implications. A test Azure load balancer, public IP address, node pool, retained disk and log workspace can generate charges even if a lab serves only a few requests. Use a disposable subscription or resource group with clear budget controls, then delete unneeded components when verification ends. In production, the operational evidence should show which version is deployed, which routes depend on it, what changed in the last release, who can roll it back and how the team will respond to a controller vulnerability announcement. These questions matter more than remembering a particular historical Helm chart argument.
Preserve historical context without repeating an unsafe tutorial
The old NGINX-on-AKS walkthrough remains an instructive snapshot of Kubernetes Ingress, reverse proxies and service routing. It should, however, be labeled as historical rather than a current recommendation to install the retired community controller. A reader should learn to distinguish a Kubernetes API from its implementation, map the client-to-Pod path, plan a safe migration for controller-specific annotations, test identity and TLS, and observe failure conditions. Gateway API and maintained ingress controllers can support these needs when their capabilities and release status are verified against the current documentation.
For a real deployment, select a maintained implementation with explicit vendor support for the intended AKS release and network model. Run functional and security tests using nonproduction traffic before cutover, preserve a rollback record and train the operations team on the new reconciliation and logging model. Successful migration means customers can still reach intended applications, unauthorized access remains blocked, and the team can explain and recover from failure. That is a durable cloud-native engineering skill, unlike an outdated command that simply recreates unmaintained software.