This section maps to exam objective 3.1 — to describe the Kubernetes networking model, DNS resolution, and CNI plugins. If you have ever wondered how thousands of tiny software containers talk to each other without crossing lines or getting lost, Kubernetes Networking and DNS is the engine behind that magic. It matters for the KCNA exam because understanding this model is the foundation for deploying any real-world application securely and reliably.
Jump to a section
A simple way to picture Kubernetes Networking and DNS
Have you ever tried to send a letter to a friend who lives in a giant apartment block, but you only know their name and not the flat number? How do you get it to the right place?
That is the exact problem Kubernetes solves with its networking model. In an apartment block, the building has one main address (like a cloud data centre), and each flat has a unique number (like a container). But those flat numbers can change – a friend might move from Flat 3A to Flat 5B. If you just addressed the letter to 'Flat 3A', it would arrive at the wrong place. The post office needs a directory that always knows which flat your friend is in right now.
Kubernetes creates its own internal 'postal system'. It gives every container its own unique IP address (a private flat number), and then acts like a smart mailroom. It assigns a stable name (like 'service-email') to a group of containers, regardless of which flat they currently occupy. When a pod (a container group) moves or fails, the mailroom automatically updates its directory. The network plugin (CNI) is the team of postworkers who physically connect the mailroom to every single flat. The DNS is the phone book that lets other services look up 'service-email' and get the correct, current internal address. No one ever needs to know the exact flat number; they just know the service name.
Let us start with a simple truth: in Kubernetes, everything is about communication. Containers (your mini-computers running your app) need to talk to each other. They need to talk to the outside world. And they need to do it without you having to manually plug cables or update address books every time a container crashes or scales up.
The classic old way is what we call 'static networking'. You had one server with one IP address (like a house number). If it broke, everything broke. If you wanted more capacity, you bought another server, gave it a new IP, and manually told every other server about it. For a few servers, it is manageable. For thousands of microservices (tiny specialised apps that each do one job), it is chaos.
Kubernetes replaces that chaos with a clean, consistent model. The Kubernetes networking model has four core rules, and every single container and pod must follow them:
Every pod (the smallest deployable unit in Kubernetes, usually one or a few containers) gets its own unique IP address. No sharing.
Every pod can talk to every other pod directly, using that IP, without Network Address Translation (NAT – a trick that hides internal addresses behind one public address). It is a flat network.
The agent on each node (the machine or virtual machine that runs pods) can talk to all pods on that node.
You, from outside the cluster, can access services but not individual pods directly.
Why is this a big deal? It eliminates port conflicts. In the old way, if two apps both wanted to use port 8080 on the same server, you had a fight. Now, each pod has its own IP, so they can all use port 8080 without collision. It also lets you move pods from machine to machine without re-addressing the whole world.
Now, how do pods actually connect? This is where the Container Network Interface (CNI) comes in. CNI is a standard – think of it as a universal plug shape. Different networking vendors (like Calico, Flannel, Weave) all follow the CNI standard so that Kubernetes can use any of them. When a pod is created, the CNI plugin is the software that automatically assigns it an IP address and connects it to the network. It runs a small program on the node that says 'create a virtual ethernet cable from this pod to the node's network'. Without CNI, your pods are just isolated software with no way to send messages.
Then we have Kubernetes DNS. DNS stands for Domain Name System – the same technology that translates google.com into numbers on the internet. Inside Kubernetes, DNS translates service names into IP addresses. When you create a 'Service' (a stable endpoint for a set of pods), Kubernetes automatically creates a DNS record for it. So a pod that needs to talk to the 'database' service can just ping 'database' (or 'database.namespace.svc.cluster.local' for the full name) and the DNS system will resolve it to whichever pod is currently serving. This is automatic and updates as pods come and go.
For example, imagine you run a front-end pod and a back-end pod called 'api'. The front-end pod can simply send a request to 'http://api:8080' without ever knowing the back-end pod's IP address. When the back-end pod restarts and gets a new IP, the DNS record updates automatically. The front-end never breaks.
Finally, the networking model also includes Services types. ClusterIP (internal only), NodePort (expose on each node's IP), and LoadBalancer (give it a public cloud load balancer) are the main ones. Each is a different way to let traffic reach your pods. But all of them rely on the same underlying rule: every pod has its own IP, and DNS makes finding them simple.
Pod Creation Triggers CNI Plugin
When a pod is scheduled to a node, the kubelet (the node agent) calls the CNI plugin. The plugin allocates a unique IP address from the cluster's CIDR range and creates a virtual network interface (veth pair) connecting the pod's network namespace to the node's root network. This step is automatic and happens in milliseconds.
CNI Configures Node-Level Routing
The CNI plugin adds routes on the node so that traffic destined for the pod's IP is sent to the correct virtual interface. Depending on the plugin (e.g., Flannel uses an overlay tunnel; Calico uses BGP routing), it also ensures traffic can reach pods on other nodes. Without this step, the pod would be isolated to the node.
Service and Endpoint Creation
When you create a Service, Kubernetes assigns it a stable ClusterIP and creates Endpoint objects (or EndpointSlice) that track the IPs of the pods matching the Service's selector. This mapping is continuously updated as pods scale or restart. The Service does not have a network interface; it is a set of iptables or IPVS rules on each node.
DNS Record Registration by CoreDNS
CoreDNS watches the Kubernetes API Server for new Services. When it sees a Service, it creates a DNS record like `servicename.namespace.svc.cluster.local` pointing to the Service's ClusterIP. Pods in the same namespace can simply use the short name `servicename`. CoreDNS also handles reverse DNS lookups and external queries.
Traffic Forwarding via kube-proxy
The kube-proxy component running on each node implements the Service rules. When a pod sends traffic to the Service IP, kube-proxy intercepts it (using iptables or IPVS) and forwards it to one of the backing pod IPs. It performs round-robin load balancing by default. This step ensures that traffic is distributed evenly across healthy pods.
External Traffic Arrives via Ingress or LoadBalancer
If you expose a Service as type LoadBalancer, the cloud provider creates a load balancer with a public IP. Traffic hits the load balancer, which forwards it to the NodePort on any node. From there, kube-proxy routes it to a healthy pod. Optionally, an Ingress controller gives you hostname-based routing and SSL termination.
Imagine you work for an online shop called 'Bookworm'. Your Kubernetes cluster runs a dozen microservices: a front-end website, a product catalogue, a shopping cart, a payment service, a recommendation engine, and a database. Each microservice runs as multiple pods for reliability. The site has to handle traffic spikes on Black Friday.
In the old world, you would have a fixed set of servers. When the recommendation engine crashed, the site would show blank recommendations until you manually fixed it. In Kubernetes, you set up a Deployment that says 'I always want three copies of the recommendation engine running'. If one crashes, Kubernetes creates a new pod automatically. But that new pod gets a brand new IP address. Without a stable network model, the front-end would suddenly try to talk to a dead IP or not know the new one.
Here is what you actually do as an IT professional:
Step 1: Design the network. You choose a CNI plugin. For simplicity, you pick Flannel because it is easy to set up. You install it as a DaemonSet (a pod that runs on every node).
Step 2: Define Services. For the recommendation engine, you create a Service named 'recommendations' of type ClusterIP. This gives it a stable internal IP and a DNS name.
Step 3: Configure DNS. You rely on the built-in CoreDNS service that comes with Kubernetes. You do not need to do much. CoreDNS automatically creates a record for 'recommendations' in the cluster.local domain.
Step 4: Use the service name in code. In your front-end configuration, you set the recommendation API URL to 'http://recommendations:8080'. No IP addresses are hardcoded.
Step 5: Test resilience. You deliberately kill one recommendation pod. The service instantly routes traffic to the remaining pods. The front-end never notices. When the new pod starts, CoreDNS updates its records within seconds.
Step 6: Expose externally. You want customers to reach the front-end. You change the front-end Service type to LoadBalancer. The cloud provider (AWS, GCP, Azure) automatically creates a public IP address and routes traffic to the pods.
Troubleshooting: When something fails, you check the CNI plugin logs (kubectl logs -n kube-system <calico-pod>) to see if IP allocation failed. You check CoreDNS logs if services cannot be resolved. You use 'kubectl exec <pod> -- nslookup recommendations' to test DNS from inside a pod.
This approach means you can scale the recommendation engine from 3 to 30 pods during Black Friday, and the network automatically handles the new IPs. You can also move the whole cluster to a new set of machines without updating a single application configuration, because everything uses service names, not IP addresses. The business gets a resilient, adaptable system that just works.
The KCNA exam expects you to understand the networking model at a conceptual level, not to configure a CNI plugin from memory. But you do need to know the key rules and their implications. Expect multiple-choice questions that test your ability to identify which statement about the networking model is true.
Here are the exact topics the exam loves to test:
The four rules of the Kubernetes networking model: every pod gets its own IP, direct pod-to-pod communication without NAT, the node agent can reach all pods on that node, and external traffic goes to services, not pods. Memorise these. The exam will often give you a list of statements and ask which is NOT a rule.
CNI plugin role: They are the implementation of the model. Know that CNI is a standard interface. Common plugins: Calico (network policies), Flannel (simple overlay), Weave. The exam will not ask you to distinguish them deeply, but recognise that CNI handles IP assignment and connectivity.
DNS resolution in Kubernetes: CoreDNS is the default. It creates DNS records for Services and pods. The format: <service-name>.<namespace>.svc.cluster.local. The exam may test that DNS is used for service discovery, not for external internet URLs.
Service types: ClusterIP (default, internal only), NodePort (exposes on every node's IP at a static port), LoadBalancer (integrates with cloud provider). Know what each does and when you would use it.
Common traps the exam will set for you:
Trap: 'Pods must use NAT to communicate between nodes.' Wrong. The model says no NAT between pods, even across different nodes.
Trap: 'You must manually assign IP addresses to pods.' Wrong. CNI does this automatically.
Trap: 'DNS is only for external websites.' Wrong. Internal DNS for services is the key use in Kubernetes.
Trap: 'A Service IP is the same as a pod IP.' Wrong. Service IP is virtual and stable; pod IPs are ephemeral.
Trap: 'All CNI plugins are exactly the same.' Wrong. They vary in features (network policies, encryption, performance). But they all follow the CNI standard.
Key definitions to memorise for the exam:
Pod IP: unique, routable within cluster, changes on restart.
Service IP: cluster-internal virtual IP, stable, does not change.
DNS record: maps service name to service IP.
CNI: Container Network Interface – the plugin standard.
CoreDNS: the default DNS server in Kubernetes.
Typical question: 'You create a Service named frontend in the default namespace. What DNS name should a pod use to reach it?' Answer: 'frontend.default.svc.cluster.local' or simply 'frontend' within the same namespace.
Another typical question: 'Which component assigns IP addresses to pods?' Answer: the CNI plugin (e.g., Calico or Flannel).
Do not over-engineer your study. Focus on the model rules, the purpose of CNI, and how DNS works for services. The exam is about concepts, not command-line details.
Every pod in Kubernetes gets its own unique IP address, and all pods can communicate directly without NAT, forming a flat network.
The Container Network Interface (CNI) is the open standard that plugins like Calico and Flannel use to assign IPs and connect pods.
Kubernetes DNS, powered by CoreDNS, automatically creates stable DNS records for every Service, allowing pods to find each other by name instead of ephemeral IP addresses.
There are three main Service types: ClusterIP for internal-only access, NodePort for exposing on each node's IP, and LoadBalancer for cloud-based public access.
A Service IP is virtual and stable, while pod IPs change on restart; this decoupling keeps applications resilient and easy to scale.
Kubernetes networking replaces the chaos of manual IP assignments with a fully automated, self-healing system that scales from one pod to thousands.
These come up on the exam all the time. Here's how to tell them apart.
Pod IP
Assigned automatically by CNI plugin at pod creation
Ephemeral: changes when pod is recreated or moved
Used for direct pod-to-pod communication if you know the exact address
Service ClusterIP
Assigned automatically by Kubernetes API at Service creation
Stable: never changes for the life of the Service
Used as a virtual front-end for load balancing traffic to pods
CNI Plugin (e.g., Calico)
Handles IP address allocation and network connectivity for pods
Works at Layer 3 (network layer) of the OSI model
Must be installed separately; not built into Kubernetes
CoreDNS
Handles name resolution for Services within the cluster
Works at Layer 7 (application layer) using DNS protocols
Comes pre-configured in most Kubernetes distributions
ClusterIP Service
Only accessible from inside the cluster
Uses a virtual IP that is routable only within the cluster network
Default Service type; no external exposure
NodePort Service
Accessible from outside the cluster via any node's IP and a static port
Exposes on every node's IP (range 30000-32767 by default)
Used for development or when a cloud load balancer is not available
kube-proxy (iptables mode)
Create iptables rules to forward traffic to pods
Less efficient for clusters with many services (linear performance drop)
Default mode in most distributions; simpler to debug
kube-proxy (IPVS mode)
Uses IPVS (IP Virtual Server) in the kernel for load balancing
More efficient for large-scale clusters (O(1) lookup)
Requires the ipvsadm tool and kernel modules; more complex to set up
Mistake
Pods inside the same node can communicate, but pods on different nodes need a special gateway or NAT to talk.
Correct
The Kubernetes networking model requires that every pod can communicate with every other pod directly, even across nodes, without any NAT. The CNI plugin creates an overlay or routing that makes this work transparently.
Beginners often think of traditional data centre networking where different subnets are isolated by routers. They assume Kubernetes has the same barriers, but the whole design is to eliminate them.
Mistake
A Service and a pod have the same IP address, so you can use them interchangeably.
Correct
A Service has its own virtual IP (ClusterIP) that is completely different from the IPs of the pods it targets. The Service IP is stable and forwards traffic to one of the pod IPs behind the scenes.
The names sound similar, and both are used to route traffic. Beginners conflate the two, not realising the Service is a load balancer abstraction, not a direct endpoint.
Mistake
Kubernetes DNS only works for internet domains like google.com, not for internal service names.
Correct
Kubernetes runs its own DNS server (CoreDNS) specifically to resolve internal service names. It can also forward external DNS queries, but its primary purpose is service discovery within the cluster.
People know DNS from their home internet (google.com) and assume Kubernetes DNS is the same thing. They do not realise it is a separate, internal system for microservice-to-microservice communication.
Mistake
You have to manually configure every container's network settings, like IP address and gateway, before it can run.
Correct
The CNI plugin automatically handles all IP address allocation and network configuration when a pod starts. The container just needs to be assigned to a pod, and the plugin does the rest.
In traditional server setups, manually assigning IPs was common. Beginners carry that expectation into Kubernetes, not realising automation is a core feature.
Mistake
Changing a Service's type from ClusterIP to NodePort changes the DNS record for that Service.
Correct
The DNS record is based on the Service name and namespace, not its type. Changing the type affects how external traffic reaches the Service, but internal DNS resolution remains the same.
Beginners think DNS and Service type are tightly coupled because both involve networking. They are separate concerns: DNS is just name resolution; the type defines external access.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Kubernetes does not ship with a default CNI plugin. You must install one (like Calico, Flannel, or Weave) after setting up the cluster. Without it, pods will stay in 'ContainerCreating' state and never start.
No. The Kubernetes networking model guarantees every pod gets a unique IP address within the cluster. This is enforced by the CNI plugin, which manages an IP address pool.
CoreDNS automatically removes the DNS record for the deleted Service within a few seconds. Any pod that tries to resolve that name afterward will receive a 'NXDOMAIN' (non-existent domain) response.
You can run `kubectl exec <pod-name> -- nslookup <service-name>` or `kubectl exec <pod-name> -- curl http://<service-name>:<port>`. If it resolves, the DNS is working. If not, check CoreDNS logs with `kubectl logs -n kube-system -l k8s-app=kube-dns`.
Not by itself. NodePort exposes ports on every node's IP, which can be a security risk if not firewalled. It is typically used for development or testing. For production, you use LoadBalancer or an Ingress controller with proper security groups.
Yes, if you change the port in the Service spec, the DNS record still points to the same ClusterIP, but the new port takes effect. In-flight connections using the old port will fail. You must coordinate changes with clients or use a rolling update strategy.
You've finished Kubernetes Networking and DNS. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?