AKS ingress controller

Understand the concept

In plain English

An AKS ingress controller is the traffic router that makes web applications inside a Kubernetes cluster reachable through host names and paths. Developers define Ingress rules, and the controller turns those rules into HTTP or HTTPS routing. Without one, teams often expose every service separately, which becomes messy and expensive. In AKS, ingress may use managed application routing, NGINX-based controllers, or other Azure application networking choices where DNS, TLS, public access, and private access meet.

Why it matters

AKS ingress controllers matter because the first broken symptom users see is often a web outage, but the cause may be routing, certificates, DNS, load balancer health, controller pods, or backend endpoints. A well-designed ingress layer lets services share a controlled entry point, enforce TLS, route by host or path, and keep private workloads private. A poorly understood layer causes public exposure mistakes, certificate expirations, confusing 404 or 502 errors, and duplicated load balancers. The controller gives teams a shared troubleshooting map from client request to pod. A small routing change can redirect or expose production traffic. Tracing must start at hostname and end at ready pods, not stop at the load balancer.

Technical context

Technically, an ingress controller runs in or alongside an AKS cluster and watches Kubernetes Ingress resources, Services, Secrets, ingress classes, and controller configuration. It updates a data plane that accepts HTTP or HTTPS traffic and forwards requests to the right Kubernetes service. AKS designs may involve Azure Load Balancer, Azure DNS, private DNS zones, TLS certificates, Application Gateway, Front Door, or Gateway API migration plans. Operators distinguish the Ingress object from controller pods and Azure resources.

Exam context

What to know

operator-ready

Compare with

Where it is used

Where you see it

1. In Kubernetes manifests, Ingress resources define hosts, paths, TLS secret names, service backends, annotations, and ingress class selection for each route. for reconciliation decisions for reconciliation decisions
2. In AKS and CLI output, application routing add-on state, load balancer IPs, DNS configuration, and cluster networking explain how traffic enters. before route changes before route changes
3. In logs and events, controller pods report certificate issues, invalid backends, rejected annotations, empty endpoints, and routing failures behind 404 or 502 responses. during outage triage

Common situations

• Expose several AKS services through one HTTPS entry point using host and path routing.
• Publish private internal applications through internal ingress and private DNS without public IPs.
• Centralize TLS certificate handling for Kubernetes apps that share domain ownership.
• Troubleshoot 404, 502, or certificate errors by tracing DNS to service endpoints.
• Plan migration from older ingress patterns to supported application routing or Gateway API designs.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

I use Azure CLI for AKS ingress work because problems cross Azure and Kubernetes boundaries. CLI tells me whether application routing is enabled, which resource group and network profile are in use, and which managed add-ons are active. Kubernetes commands then show ingress classes, controller pods, services, endpoints, secrets, and events. In production, I want evidence for add-on state, load balancer address, DNS record, TLS secret, and backend endpoints before changing routing. CLI retrieves the AKS cluster profile before kubectl checks inspect ingress resources. Evidence is stronger when Azure and Kubernetes output tell the same route story. Scripts can compare controller deployments, services, certificates, and endpoints across clusters.

az aks show --resource-group <resource-group> --name <cluster-name>

az aks update --resource-group <resource-group> --name <cluster-name> --enable-app-routing

kubectl get ingress --all-namespaces

kubectl describe ingress <ingress-name> -n <namespace>

kubectl get svc,endpoints,pods -n <namespace>

Architecture context

Architecturally, the AKS ingress controller is where cluster networking becomes application access. I decide early whether ingress should be public, private, protected by Front Door or Application Gateway, or replaced by a Gateway API pattern for newer designs. That decision affects certificates, DNS ownership, WAF placement, source IP preservation, path routing, health probes, and who can publish routes. Shared ingress is efficient, but it needs governance so one namespace cannot hijack another team's host name. Ingress design decides whether teams share controllers or isolate traffic paths. The route model becomes part of the platform contract. Architects should align controller choice with WAF, TLS, private access, and DNS needs.

Security

Security impact is direct because ingress controls how clients reach workloads. Mistakes can expose private APIs, terminate TLS incorrectly, accept weak host rules, or route traffic to the wrong namespace. Teams should restrict who can create Ingress resources, review annotations, automate certificate management, and decide where WAF protection belongs. Private ingress should use internal load balancers and private DNS rather than accidental public IPs. TLS secrets must be protected, rotated, and separated by environment. TLS termination, allowed hostnames, source restrictions, and WAF placement all matter. Controller permissions should be limited to the namespaces and resources it needs. A wildcard route or stale certificate can expose services unexpectedly.

Cost

Cost impact is usually indirect but noticeable. A shared ingress controller can reduce public IPs and load balancers created for individual services. Adding Application Gateway, Front Door, private DNS, WAF, extra controller replicas, or verbose access logs can increase cost. Poor routing design can create unnecessary data transfer or duplicate edge layers. FinOps reviews should check LoadBalancer services, unused controllers, log retention, private versus public routing, and ownership tags. Ingress cost often comes from adjacent load balancers, public IPs, WAF, and logging. Dedicated controllers may be justified for regulated or high-traffic workloads. Sharing controllers can lower cost but increases coordination overhead.

Reliability

Reliability depends on controller health, replica count, load balancer behavior, DNS, certificates, backend services, and pod readiness. If controller pods crash, endpoints are empty, or certificates expire, many applications can fail together. Shared ingress creates shared blast radius, so operators monitor controller pods, service IPs, status codes, backend latency, certificate expiration, and DNS changes. Rolling changes to ingress classes or controller configuration need canary testing and rollback. Controller replicas, load balancer health, DNS TTL, and backend readiness affect uptime. A broken shared controller can impact many services at once. Rollback plans should include ingress objects and controller configuration. AKS ingress controller reliability evidence should be captured before approval 1.

Performance

Performance depends on the full ingress path, not just the application pod. Controller capacity, TLS termination, request buffering, path matching, backend endpoints, network hops, WAF inspection, and upstream timeouts influence response time. A single under-resourced controller can throttle many services. Operators should monitor request rate, latency, connection counts, 502 and 504 rates, controller CPU and memory, and backend readiness before changing application code. Routing latency depends on controller health, backend readiness, TLS, and load balancer behavior. Performance checks should include ingress metrics and pod-level response time. Misconfigured timeouts or buffers can look like application slowness. AKS ingress controller performance evidence should be captured before approval 1.

Operations

Operators troubleshoot ingress by following the request path: DNS name, public or private IP, load balancer or gateway, ingress controller service, Ingress rule, Kubernetes service, endpoints, and pods. Common tasks include listing ingress objects, checking controller pods, validating TLS secrets, reviewing events, confirming DNS records, and comparing expected host rules with live configuration. Change records should name hostname, path, namespace, ingress class, certificate, address, and rollback command. Operators should inspect ingress, service, endpoint, certificate, and controller pod state together. Ownership labels help route incidents to the right application team. Runbooks must show how to test each hostname before and after a change. AKS ingress controller operations evidence should be captured before approval 1.

Common mistakes

• Creating an Ingress object without a matching controller or ingress class.
• Pointing DNS to an old load balancer address after recreating the controller service.
• Storing TLS secrets in the wrong namespace or letting certificates expire.
• Assuming a 502 means the controller is broken when the service has no endpoints.
• Allowing any namespace owner to claim shared production host names.