Networking is where a lot of KCNA candidates lose easy points — not because it’s hard, but because the pieces (Services, Ingress, DNS, the CNI) blur together if you never see how they fit. The good news: Kubernetes networking follows a small set of clear rules, and once you internalize them, the exam questions become pattern matching.
This guide is written from a practitioner’s perspective. We’ll walk through the Kubernetes networking model, why Services exist, the four Service types you must know cold, how Ingress adds smart HTTP routing, how pods find each other by name through cluster DNS, and the roles of the CNI and NetworkPolicy. Along the way you’ll see the YAML and the exam signals that make each topic click. If you want the full exam picture first, start with the KCNA Exam Guide 2026, then come back here to go deep on networking.
The Kubernetes Networking Model: Four Rules to Memorize
Kubernetes doesn’t invent a brand-new network; it imposes a model that every conforming cluster must satisfy. Four rules capture it:
- Every Pod gets its own unique IP address. Containers in the same Pod share that IP and communicate over
localhost. - Pods can reach every other Pod directly, without NAT. The network is flat — a Pod on node A talks to a Pod on node B using its IP, as if they were on the same LAN.
- Nodes can reach all Pods (and vice versa) without NAT.
- The IP a Pod sees for itself is the same IP others use to reach it.
Kubernetes itself doesn’t implement this network — it delegates that to a CNI plugin (more on that below). The exam expects you to know the model’s promise: a flat, NAT-free network where every Pod is individually addressable.
The catch is that Pod IPs are ephemeral. Pods are created and destroyed constantly — during scaling, rolling updates, and failures — and each new Pod gets a new IP. You can never rely on a Pod’s IP address as a stable endpoint. That single fact is why Services exist.
Why Services Exist: Pods Are Cattle, Not Pets
A Service is a stable, abstract endpoint in front of a set of Pods. Instead of chasing changing Pod IPs, clients talk to the Service, which provides:
- A stable virtual IP (the ClusterIP) that never changes for the life of the Service.
- A stable DNS name so clients can connect by name, not IP.
- Automatic load balancing across all the healthy Pods behind it.
Think of a Deployment as a herd of interchangeable Pods (“cattle, not pets”) and the Service as the single, unchanging front door to that herd. When Pods come and go, the Service keeps pointing traffic to whatever Pods are currently healthy.
How a Service Finds Its Pods: Labels, Selectors & EndpointSlices
A Service doesn’t hard-code Pod IPs. It uses a label selector to dynamically match Pods:
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web # matches every Pod labeled app=web
ports:
- port: 80 # the port the Service listens on
targetPort: 8080 # the port on the PodAny Pod carrying the label app: web is automatically added to the Service. Behind the scenes Kubernetes maintains EndpointSlices — the live list of Pod IPs and ports that currently match the selector. As Pods appear and disappear, the EndpointSlices update, and the Service always routes to the current set. This is the mechanism that makes Services resilient to Pod churn, and it builds directly on the labels-and-selectors model covered in the Kubernetes object model.
The Four Service Types
Services come in four types. Knowing when to use each — and how they layer on top of one another — is the highest-value networking topic on the KCNA.
ClusterIP (the default)
ClusterIP exposes the Service on an internal virtual IP that is only reachable from inside the cluster. This is the default and the most common type — perfect for internal communication, like a frontend talking to a backend API.
apiVersion: v1
kind: Service
metadata:
name: backend
spec:
type: ClusterIP # default; can be omitted
selector:
app: backend
ports:
- port: 80
targetPort: 8080Signal: “internal only,” “service-to-service,” “not exposed outside the cluster” → ClusterIP.
NodePort
NodePort builds on ClusterIP and additionally opens a static port (by default in the range 30000–32767) on every node. Traffic hitting NodeIP:NodePort is forwarded to the Service and on to a Pod. It’s the simplest way to reach a Service from outside the cluster, but exposing raw node ports is rarely how you’d do it in production.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
type: NodePort
selector:
app: web
ports:
- port: 80
targetPort: 8080
nodePort: 30080 # optional; auto-assigned if omittedSignal: “reach the app on a port on each node,” “simple external access for dev/test” → NodePort.
LoadBalancer
LoadBalancer builds on NodePort and provisions an external load balancer from the underlying cloud provider (AWS, GCP, Azure), giving the Service a single external IP or DNS name. This is the standard way to expose a single Service to the internet in a cloud cluster.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 8080Signal: “expose to the internet with a cloud load balancer,” “public IP for one service” → LoadBalancer.
ExternalName
ExternalName is the odd one out. It doesn’t select Pods at all — it maps the Service name to an external DNS name via a CNAME record, letting in-cluster clients reach an external service using a local name.
apiVersion: v1
kind: Service
metadata:
name: db
spec:
type: ExternalName
externalName: database.example.comSignal: “alias to an external DNS name,” “point a cluster name at an outside endpoint” → ExternalName.
Quick comparison
| Type | Reachable from | Builds on | Typical use |
|---|---|---|---|
| ClusterIP | Inside the cluster only | — | Internal service-to-service |
| NodePort | Outside, via NodeIP:port | ClusterIP | Simple/dev external access |
| LoadBalancer | Outside, via cloud LB | NodePort | Public-facing single service |
| ExternalName | Inside → external DNS | — (CNAME) | Alias to an external endpoint |
The key insight: NodePort includes ClusterIP, and LoadBalancer includes NodePort. Each type adds a layer of external reachability on top of the one before it.
kube-proxy: The Engine Behind Services
How does a virtual ClusterIP actually route to real Pods? That’s the job of kube-proxy, a component running on every node. It watches the API server for Services and EndpointSlices and programs the node’s networking (using iptables by default, or IPVS at larger scale) so that traffic to a ClusterIP is transparently load-balanced to a backing Pod. You rarely touch kube-proxy directly, but the KCNA expects you to know it’s the piece that implements Services at the node level.
Ingress: Smart HTTP Routing at Layer 7
A LoadBalancer Service exposes one Service per external IP — which gets expensive and inflexible when you have many services. Ingress solves this. An Ingress is a set of Layer 7 (HTTP/HTTPS) routing rules: route by hostname and URL path to different backend Services, terminate TLS, and do it all behind a single entry point.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: site
spec:
rules:
- host: shop.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 80There’s one crucial gotcha the exam loves: an Ingress resource does nothing on its own. You must run an Ingress Controller (for example the NGINX Ingress Controller) in the cluster — it’s the actual proxy that reads Ingress rules and routes traffic. No controller, no routing.
Ingress vs. LoadBalancer: use a LoadBalancer Service to expose a single service on its own external IP; use an Ingress to route many HTTP services through one entry point with host/path rules and shared TLS.
It’s also worth knowing that the Gateway API is the newer, more expressive successor to Ingress, designed to cover more protocols and give cleaner role separation. You don’t need to configure it for KCNA, but recognize the name as the evolving direction of Kubernetes traffic routing.
Cluster DNS: How Pods Find Services by Name
Kubernetes runs an internal DNS service — CoreDNS — so workloads can reach Services by name instead of chasing IPs. Every Service gets a DNS record following a predictable pattern:
<service-name>.<namespace>.svc.cluster.localSo a Service named backend in the payments namespace is reachable at backend.payments.svc.cluster.local. A Pod in the same namespace can use the short name backend; a Pod in another namespace uses backend.payments. This name-based discovery is what lets you wire microservices together without ever hard-coding an IP — it’s the practical payoff of the whole Service abstraction.
A quick way to see it in action:
# From inside a Pod, resolve a Service by name
kubectl run tmp --rm -it --image=busybox --restart=Never -- \
nslookup backend.payments.svc.cluster.localThe CNI: Who Actually Wires the Network
Remember that Kubernetes defines the networking model but doesn’t implement it. The Container Network Interface (CNI) is the standard plugin interface that does. When a Pod is scheduled, the kubelet calls a CNI plugin to give the Pod its IP address and connect it to the cluster network. Popular CNI plugins include Calico, Cilium, and Flannel — each implements the flat Pod network, and some add extra features like network policy enforcement or eBPF-based performance.
For the KCNA, know that:
- The CNI is a CNCF project and a pluggable standard, not a single product.
- The plugin you install determines how the networking model is realized and which advanced features (like NetworkPolicy) you get.
- Container runtimes and the CNI are the layer beneath Services — a good complement to container orchestration fundamentals.
NetworkPolicy: Controlling Pod-to-Pod Traffic
By default, the flat network means any Pod can talk to any other Pod — there’s no isolation. A NetworkPolicy changes that by defining allowed ingress and egress traffic, selected by labels. As soon as a Pod is selected by any policy, it becomes “default-deny” for the direction the policy covers, and only the explicitly allowed traffic gets through.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-web-to-api
spec:
podSelector:
matchLabels:
app: api
policyTypes: ["Ingress"]
ingress:
- from:
- podSelector:
matchLabels:
app: webOne essential caveat: NetworkPolicies are only enforced if your CNI plugin supports them. Flannel alone, for example, does not enforce NetworkPolicy, while Calico and Cilium do. The KCNA expects you to understand NetworkPolicy as the mechanism for Pod-level network isolation and micro-segmentation — a foundational security concept.
What the KCNA Exam Expects You to Know
Pulling it together, here are the networking signals worth memorizing before test day:
- Pod IPs are ephemeral → use a Service for a stable endpoint.
- ClusterIP = internal, NodePort = node port, LoadBalancer = cloud LB, ExternalName = DNS alias. Each external type layers on the previous one.
- Ingress = Layer 7 host/path routing, and it requires an Ingress Controller to function.
- CoreDNS provides Service discovery via
<service>.<namespace>.svc.cluster.local. - The CNI implements the Pod network; plugins like Calico and Cilium also enforce NetworkPolicy.
- NetworkPolicy provides default-deny, label-based Pod isolation — but only with a supporting CNI.
For a wider view of how these fit the KCNA domains, see the KCNA study guide and revisit the Kubernetes architecture fundamentals that underpin the network.
Frequently Asked Questions
What is the difference between ClusterIP, NodePort, and LoadBalancer?
ClusterIP exposes a Service on an internal virtual IP reachable only inside the cluster — it’s the default and is used for service-to-service communication. NodePort builds on ClusterIP and also opens a static port (30000–32767 by default) on every node, so the Service is reachable from outside via NodeIP:NodePort. LoadBalancer builds on NodePort and provisions an external cloud load balancer with a single public IP or DNS name. Each type adds a layer of external reachability on top of the previous one.
Why do Pods need a Service instead of connecting by IP?
Pod IP addresses are ephemeral — every time a Pod is recreated during scaling, an update, or a failure, it gets a new IP. A Service provides a stable virtual IP and DNS name in front of a dynamic set of Pods, selected by labels, and load-balances traffic across whichever Pods are currently healthy. Clients talk to the Service and never have to track changing Pod IPs.
What is the difference between an Ingress and a LoadBalancer Service?
A LoadBalancer Service exposes a single Service on its own external IP through a cloud load balancer. An Ingress is a set of Layer 7 HTTP/HTTPS routing rules that send traffic to multiple backend Services based on hostname and URL path, behind a single entry point, and can terminate TLS. Use LoadBalancer for one service; use Ingress to route many HTTP services efficiently through one endpoint. Note that Ingress requires an Ingress Controller to actually do the routing.
What is the CNI in Kubernetes?
The Container Network Interface (CNI) is the standard, pluggable interface Kubernetes uses to implement Pod networking. Kubernetes defines the networking model — every Pod gets a unique IP and can reach every other Pod without NAT — but delegates the actual implementation to a CNI plugin such as Calico, Cilium, or Flannel. The plugin assigns Pod IPs, wires them into the cluster network, and, depending on the plugin, may also enforce NetworkPolicy.
How does DNS work inside a Kubernetes cluster?
Kubernetes runs CoreDNS as an internal DNS server. Each Service gets a DNS name in the form <service-name>.<namespace>.svc.cluster.local. Pods in the same namespace can use the short service name; Pods in a different namespace use <service>.<namespace>. This lets workloads discover and connect to each other by name instead of by IP, which is essential because Pod and Service IPs are managed dynamically.
Do NetworkPolicies work with every cluster?
No. A NetworkPolicy is only enforced if the cluster’s CNI plugin supports it. Plugins like Calico and Cilium enforce NetworkPolicy, while some simpler plugins (such as Flannel on its own) do not. Without a supporting CNI, a NetworkPolicy resource is accepted by the API server but has no effect on traffic.
Conclusion and Next Steps
Kubernetes networking stops being intimidating once you see the layers: a flat Pod network where IPs are ephemeral, Services that put a stable front door on a changing set of Pods, Ingress that adds Layer 7 routing, DNS that makes discovery name-based, and the CNI that quietly implements it all. Learn the four Service types and how they stack, remember that Ingress needs a controller, and know the role of CoreDNS, the CNI, and NetworkPolicy — and networking becomes one of the most reliable scoring areas on the KCNA.
The fastest way to turn this understanding into exam-day reflexes is realistic practice. Sailor.sh’s Kubernetes and Cloud Native Associate (KCNA) Mock Exam Bundle gives you exam-style questions that mirror the real format and difficulty — including the Service-type and Ingress distinctions covered here — with detailed explanations that surface the exact concepts the exam tests. Working through realistic questions is the surest way to find your gaps before they cost you points.
Pair the practice with the KCNA study guide, then round out your fundamentals with the Kubernetes object model & kubectl, scheduling & resource management, and cloud native architecture & observability.