CoreDNS — how one Service finds another by name
In §27a you learned to use a Service for ordinary app-to-app traffic because pod addresses change. Direct pod access can still help with debugging. Your application usually does not carry the Service's stable ClusterIP either — it carries a name. Inside the cluster a pod that wants the payments service opens a connection to payments, or payments.shop.svc.cluster.local, and something has to turn that name into the Service's ClusterIP. That something is CoreDNS, a DNS server AKS runs for you as pods in kube-system. It watches the API server, and for every Service it publishes a name that resolves to that Service's ClusterIP.
The shape of the name is worth holding: service.namespace.svc.cluster.local. Within one namespace the bare name is enough — payments resolves — because CoreDNS appends the caller's namespace by default.1 Across namespaces you spell it out: payments.billing. That is the whole mechanism behind "services find each other by name," and it is why a typo in a namespace, not a broken app, is the usual reason one service cannot reach another. When you next debug a connection that hangs, resolving the name by hand from inside a pod tells you in one command whether DNS or the network is the problem.
Ingress — one front door for many Services
A ClusterIP Service is for in-cluster callers. An ingress controller can receive HTTP or HTTPS traffic at a shared entry point and route by hostname or path to several Services. An Ingress resource describes those routing rules; the controller implements them. The entry point can be public or internal, depending on its configuration. Sharing it can reduce duplicated infrastructure, but it also creates shared capacity and failure considerations.
AKS's application-routing add-on offers managed NGINX Ingress for existing workloads, but Microsoft says its critical security-patch support ends in November 2026 and recommends planning a move to its Gateway API implementation.3 Application Gateway for Containers is another managed option. This lesson's NGINX lab teaches the route-to-Service model; do not select NGINX as a new long-lived production edge without reviewing its support timeline and a migration path. Routing alone does not authenticate a client or authorize it to call a partner API.
One door. The proxy decides who goes where.
Play it through
Three minutes. Connect an Ingress route to a Service, then replace one of three ready pods. In this scenario the other two keep serving; a stable address alone does not guarantee uninterrupted requests.
Try the demo, in stages. First test one Service from inside the cluster, then one ingress route, then the blocked pod. The AKS ingress and network-policy lab routes to two Services and tests a policy that blocks one internal pod. It creates billable resources and an unauthenticated public HTTP demo route; do not use that route for real data or treat the policy as partner authentication.
The data plane — where pods get their addresses
Under the names and the proxy sits a plainer question: where does a pod's IP address come from? The answer is the cluster's network model, chosen when the cluster is created, and the current recommended default on AKS is Azure CNI Overlay.2 Pods receive addresses from a private overlay range that is separate from the virtual network's own address space; the node translates between the two. The reason this is the default is unglamorous and important: it solves IP exhaustion. Under the flat models, every pod consumed a real VNet address, and a busy cluster could drain a subnet — the kind of ceiling you hit at 2am during a scale-out, not in planning.
You will still meet the older names, and it is worth being precise about them so an interview does not catch you. Legacy kubenet is on a deprecation path — do not describe it as "the default." Flat Azure CNI, where pods sit directly in the VNet, is still available and correct when a pod genuinely needs a routable VNet address, but it trades away the address-space savings. For a new, deliberately ordinary cluster, Overlay is the choice that will not surprise you later. The distinction that matters is the one you can state in a sentence: Overlay hands pods overlay IPs and spares your subnet; the flat models spend a real VNet address on every pod.
Network policies — pods talk to everyone until you say otherwise
Without enforced NetworkPolicies, pod-to-pod traffic is generally allowed across namespaces. A NetworkPolicy selects destination pods and names allowed sources, destinations or ports. Once an ingress policy selects a pod, traffic not allowed by any applicable ingress policy is denied. A namespace label can permit traffic from an ingress-controller namespace; that does not identify or authenticate the original internet client. Client access control belongs at the external entry point or application as well.
NetworkPolicy objects require a compatible enforcement engine. Current AKS choices and support dates differ: Azure NPM is legacy; Cilium and Calico have different dataplane and support tradeoffs. Verify the cluster's network profile before relying on a policy. Test both allowed and denied paths, because a manifest that applies successfully is not proof that packets are filtered. An audit also needs evidence of the engine, policy selection, and observed behavior.
Private clusters — taking the API server off the internet
One address is left to account for: the API server, the endpoint kubectl talks to. By default it has a public IP, reachable from anywhere and guarded by authentication. A private cluster replaces that with a private endpoint — the API server is reachable only over the virtual network, with no public IP at all. Administrators reach it from inside the VNet, over a peering, or through a VPN or bastion, and a scanner on the open internet cannot even see that it exists.
This is defence in depth, not a substitute for the authentication and RBAC of §27e; a private endpoint narrows who can reach the door, while RBAC decides what they may do once they knock. The cost is operational — your pipelines and your engineers now need a network path in, which is real work to arrange and a real thing to get wrong. Whether that trade is worth it is exactly the judgement call a regulated tenant faces, and the three networking concerns below are the ones you weigh together when you design a cluster's edge.
- Reach in — the API server
- Public endpoint by default; a private cluster gives it a private endpoint on the VNet. Authentication and RBAC still gate what a caller may do (§27e); the private endpoint only narrows who can reach it.
- Reach in — application traffic
- One ingress controller as the single front door, routing external HTTP or HTTPS by host and path to many ClusterIP Services. On AKS, the managed application routing add-on or Application Gateway for Containers.
- Reach across — pod to pod
- All-to-all by default; a network policy narrows it to only the sources that must connect. Requires a policy engine chosen at cluster creation. This is the clause an auditor checks.
The partner gateway needs two different access checks
In this fictional case, the gateway sits behind a ClusterIP Service. An external HTTP entry point can route a partner request to it, but a route is not a partner allow-list. The team must decide how to authenticate and authorize the partner at the edge or application, configure HTTPS, and test an unauthorized request. The storefront remains on App Service and the batch job on Container Apps.
Separately, a NetworkPolicy can allow the ingress-controller pods to reach gateway pods while denying an unrelated pod's direct connection. The policy sees the controller as its source on that path; it cannot prove which outside partner made the request. For the contract, a reviewer needs the policy, proof the engine enforces it, and evidence that the external partner check works. Neither object alone satisfies the whole requirement.
"The service is up but I can't reach it"
Start with the caller and target. Resolve the Service name from a pod in the caller's namespace. Then check the Service selector and ready endpoints. If those exist but the connection fails, inspect NetworkPolicies and their enforcement engine. For an external caller, also check the route, entry-point address, TLS, and authentication. A failed name lookup does not by itself prove CoreDNS is broken; a typo or missing Service is often enough.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. CoreDNS is the in-cluster resolver that watches the API server and publishes a name for every Service, resolving payments to that Service's stable ClusterIP. A confuses layers: the ingress controller is the edge proxy for traffic arriving from outside, not the resolver for internal names. C reaches for the wrong resolver — cluster-internal names like payments.billing.svc.cluster.local mean nothing to public Azure DNS. D is the pod-IP sin the whole Service model exists to prevent; wire to a pod address and it goes stale the first time that pod is replaced. The name-to-ClusterIP hop is CoreDNS, and it is the first thing to check when one service cannot find another.
B. An HTTP ingress controller can share one configured public entry point and route by hostname to five Services. It still needs TLS, capacity, availability and access controls. A dedicated LoadBalancer Service per app can be justified by isolation needs but does not meet this one-IP requirement. NodePort does not supply host routing, and ClusterIP pods do not need public IPs. For a new AKS production edge, check Microsoft's current Gateway API and Application Gateway for Containers guidance rather than assuming the older NGINX add-on is a long-term choice.
The all-to-all default, Azure CNI Overlay, and the private endpoint. The two rejects are the traps interviewers set. Kubenet is not the default — it is on a deprecation path, and calling it the default is the tell of someone reading an old guide; Azure CNI Overlay is the current recommendation. CoreDNS resolves in-cluster Service names, turning payments into a ClusterIP. It can also forward other DNS queries upstream, so the false option gets its in-cluster role backward. The all-to-all default is the one to carry into any security conversation: the network wall between pods does not exist until you build it with a policy.
# plan: exposing partner-gw to the wholesale partner
1. An Ingress on the app-routing add-on gives it one
public hostname over managed NGINX.
2. CoreDNS resolves partner-gw to its ClusterIP for
internal callers.
3. Pods are all-to-all by default, so no network policy
is needed to restrict who reaches the gateway.
4. A private cluster would take the API server off the
public internet.
Line three. The permissive pod-to-pod default is a reason to evaluate an enforced NetworkPolicy, not to skip one. Select the gateway pods, allow only required in-cluster sources such as the ingress controller, and test a denied pod path. That still does not identify the outside partner: authentication and authorization must be configured at the edge or application and tested separately.
The other lines describe routing and DNS correctly. The application-routing add-on still offers managed NGINX for existing use, but its support timeline matters for new designs. CoreDNS resolves internal Service names. A private cluster restricts API-server reachability. A NetworkPolicy controls pod traffic only when an engine enforces it; external-client authorization remains a separate check.
Clarify the need for independence. Separate entry points can reduce shared failure risk or meet a dedicated-IP requirement, but they add infrastructure and configuration to operate. A LoadBalancer Service does not automatically supply a certificate; TLS must be designed separately.
Explain the shared route. For HTTP apps that can share an edge, one controller can route hosts and paths to separate Services. It reduces duplicated entry-point configuration but becomes shared capacity and a shared failure domain. Plan replicas, certificates, access controls and monitoring. On AKS, review the current managed Gateway API path and the NGINX support deadline before choosing a controller.
State the tradeoff. Use a shared HTTP edge when the apps can share its policy and failure domain. Consider a separate edge for non-HTTP traffic, different security controls, independent availability, or a required dedicated address. Price and test the chosen design rather than assuming one route is always better.
Separate the paths. The ingress route tells HTTP requests where to go; it does not prove that only the partner may use it. An unrelated pod may also reach the ClusterIP directly unless an enforced policy or other control blocks it.
Name both missing controls. Authenticate and authorize the external partner at the edge or application, with TLS and tested denial for other clients. Use an enforced NetworkPolicy to restrict direct pod-to-pod access to the gateway. A policy allowing the ingress-controller namespace cannot distinguish one outside partner from another.
Verify behavior. Test an authorized partner request, an unauthorized external request, an allowed ingress-controller path, and a denied internal pod path. Keep the configuration and results as evidence for the review.
Five things worth carrying out of Part C
- CoreDNS is the in-cluster resolver: it turns a Service name into that Service's ClusterIP. The name is service.namespace.svc.cluster.local; the bare name works within a namespace.
- An ingress controller can share an HTTP entry point across Services. It may be public or private and needs separate TLS and client-access configuration. AKS NGINX support has a November 2026 deadline.
- Azure CNI Overlay is the current recommended network model — pods get overlay IPs, sparing the VNet subnet from exhaustion. Legacy kubenet is deprecating; do not call it the default.
- Pod-to-pod traffic is generally open without enforced policies. NetworkPolicy narrows selected traffic only when a compatible engine is active; test allowed and denied paths.
- A private cluster gives the API server a private endpoint with no public IP. It narrows who can reach the door; RBAC still decides what they may do once they knock.
- The precise DNS suffix and search behaviour has edge cases worth knowing before they bite: a pod's resolver is configured to append a search list, which is why payments resolves within a namespace but a partially-qualified name like payments.billing is needed across one. It is also why the occasional slow DNS lookup traced to unnecessary search-domain expansion is a real, if niche, performance story on busy clusters — not something to tune on day one, but the kind of detail that separates "DNS works" from "I know why it sometimes doesn't." ↩
- Treat the specifics of which network model is "default" as a moving target, and the direction as settled. Azure has shifted its recommendation over time as Overlay matured, and the exact wording in the docs may read differently by the time you provision a cluster; what is stable is the reasoning — overlay addressing exists to spare the VNet, and reaching for a model that spends a real subnet address on every pod should be a deliberate choice with a reason behind it, not the path of least resistance. ↩
- Microsoft's application-routing guidance says critical security-patch support for the managed NGINX add-on runs through November 2026 and recommends migration planning toward Gateway API. ↩
Put an ingress in front of a workload and a network policy behind it.
Play the lesson above to stamp this class.