Overview
Domain 3 covers how traffic reaches workloads. You need to understand the Kubernetes network model, where every Pod gets its own IP and can reach any other Pod without NAT, and the CNI plugin that implements it. On top of that sit Services (ClusterIP, NodePort and LoadBalancer) that give a stable virtual IP and DNS name to a changing set of Pods tracked in EndpointSlices; NetworkPolicies that restrict which Pods may talk; and north-south entry through Ingress resources or the newer Gateway API with GatewayClass, Gateway and HTTPRoute objects. CoreDNS ties it together by resolving Service names.
Tasks are practical: expose a Deployment on a given port, write a policy that allows only one client, route a hostname and path to a Service, or find out why a name does not resolve. The domain links to Workloads and Scheduling through labels and readiness, and to Troubleshooting, where Service and DNS failures are a standard scenario.
How it's tested
Networking tasks ask you to create or fix the path between a client and a workload: a Service with the right port mapping, a NetworkPolicy with exact selectors, an Ingress or HTTPRoute for a host and path, or DNS resolution. Grading checks objects and often real connectivity, so a configuration that looks right but blocks traffic scores nothing.
-
Expose and verify
Create a Service of a given type and port for an existing workload, then confirm endpoints exist and a request from another Pod succeeds.
-
Allow exactly this traffic
Write a NetworkPolicy that permits a named client on one port and denies everything else, where the structure of from and to entries decides the result.
-
Route the hostname
Send a host and path to a backend Service with an Ingress or Gateway API HTTPRoute, choosing the right class, listener and path type.
A task: Pods labelled app=api in namespace prod must accept traffic on port 8080 only from Pods labelled role=client in namespace web. The policy selects app=api, sets policyTypes Ingress, and uses one from entry combining namespaceSelector kubernetes.io/metadata.name=web with podSelector role=client, plus port 8080. Splitting those selectors into two entries would allow every Pod in web and every role=client Pod in prod.
Competencies 6
Official competencies from the Linux Foundation outline, in outline order.
3.1 Understand connectivity between PodsThe flat Pod network model and the CNI plugin that provides it.
- What it means
- Kubernetes requires every Pod to have a unique IP and to reach every other Pod, on any node, without NAT; the CNI plugin assigns those IPs from the node's Pod CIDR and builds the routes.
- What to understand
- Containers in one Pod share a network namespace and talk over localhost, while Pods talk by Pod IP. Pod IPs change when Pods are recreated, which is why Services exist. Without a CNI plugin, nodes stay NotReady and Pods stay Pending or ContainerCreating.
- How it shows up
- You test connectivity with kubectl exec or a temporary busybox Pod using wget or nc against a Pod IP to decide whether a problem lies in the Pod network or in a Service.
- Common confusion
- Assuming Pods on different nodes need a Service or NAT to communicate; the model guarantees direct Pod-to-Pod reachability.
3.2 Define and enforce Network PoliciesRestricting Pod traffic with label-based ingress and egress rules.
- What it means
- A NetworkPolicy selects Pods with podSelector and, for the directions listed in policyTypes, allows only traffic matching its rules; anything not allowed to a selected Pod is denied.
- What to understand
- With no policy, all traffic is allowed. Policies are additive allow-lists, never deny rules. Within one from or to entry, namespaceSelector and podSelector are ANDed; separate entries are ORed. A default-deny egress policy also blocks DNS, so allow UDP and TCP port 53 to kube-dns. Enforcement requires a CNI that supports policies.
- How it shows up
- A task asks you to isolate a namespace and then allow one client on one port, and the grader tests both the allowed and the blocked path.
- Common confusion
- Writing namespaceSelector and podSelector as two list items when the requirement is 'Pods with label X in namespace Y'.
3.3 Use ClusterIP, NodePort, LoadBalancer service types and endpointsStable virtual IPs and the endpoints behind them.
- What it means
- A Service gives a stable IP and DNS name to the Pods matching its selector; ClusterIP is internal, NodePort also opens a port in 30000-32767 on every node, and LoadBalancer also asks a cloud or load-balancer controller for an external address.
- What to understand
- port is the Service port, targetPort is the container port, and nodePort is the node port. Ready Pods matching the selector are listed in EndpointSlices; an empty list means a selector mismatch or no ready Pods. kube-proxy programs the node rules that forward traffic. A headless Service (clusterIP: None) returns Pod IPs directly from DNS.
- How it shows up
- You expose a Deployment with kubectl expose on a stated port and type, or fix a Service whose endpoints are empty.
- Common confusion
- Setting targetPort to the Service port when the container listens on a different port.
3.4 Use the Gateway API to manage Ingress trafficGatewayClass, Gateway and HTTPRoute for north-south traffic.
- What it means
- The Gateway API splits ingress into role-oriented resources: a GatewayClass names the controller implementation, a Gateway defines listeners (protocol, port, hostname, TLS), and an HTTPRoute attaches to a Gateway through parentRefs and maps hostnames, paths and headers to backend Services.
- What to understand
- The API is installed as CRDs and needs a controller; it is not built into kube-apiserver. A listener's allowedRoutes defaults to routes from the Gateway's own namespace. backendRefs can carry weights for traffic splitting, and cross-namespace backends need a ReferenceGrant.
- How it shows up
- You create an HTTPRoute that sends a hostname or path prefix to a Service on a given port, or split traffic between two versions by weight, then check the route shows Accepted in its status.
- Common confusion
- Pointing parentRefs at the GatewayClass instead of the Gateway, so the route never attaches.
3.5 Know how to use Ingress controllers and Ingress resourcesHTTP routing with Ingress objects and the controller that implements them.
- What it means
- An Ingress resource declares host and path rules to backend Services, but it does nothing until an Ingress controller, selected through ingressClassName or a default IngressClass, implements it.
- What to understand
- pathType matters: Exact matches one path, Prefix matches by path elements so /app matches /app/x but not /application, and ImplementationSpecific depends on the controller. TLS uses a Secret of type kubernetes.io/tls named in the tls section. kubectl create ingress can generate rules quickly.
- How it shows up
- You route two paths on one host to two Services, add TLS from an existing Secret, or migrate an Ingress rule to an equivalent HTTPRoute.
- Common confusion
- Leaving out ingressClassName when there is no default class, so no controller claims the Ingress and it gets no address.
3.6 Understand and use CoreDNSCluster DNS for Services and Pods.
- What it means
- CoreDNS runs as a Deployment in kube-system behind the Service named kube-dns, and its Corefile, held in the coredns ConfigMap, defines the cluster domain, upstream forwarding and other plugins.
- What to understand
- A Service resolves as NAME.NAMESPACE.svc.cluster.local, and the short name works only from the same namespace because of the search list in the Pod's /etc/resolv.conf. Pod records use the dashed IP, such as 10-244-1-7.NAMESPACE.pod.cluster.local. Changes to the Corefile are reloaded by the reload plugin, or by restarting the CoreDNS Deployment.
- How it shows up
- You resolve a Service from a test Pod with nslookup, record the result to a file, or change upstream forwarding in the Corefile.
- Common confusion
- Using the bare Service name from a Pod in another namespace and concluding DNS is broken.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Kubernetes network model
Every Pod has its own IP and can reach every other Pod and node without NAT, whichever node it runs on.
- Remember
- The CNI plugin implements this; Services and policies are layered on top.
- Tested as
- Connectivity tests separate Pod-network faults from Service faults.
- Trap
- Assuming cross-node Pod traffic needs a Service.
-
Default allow and isolation
Pods accept all traffic until a NetworkPolicy selects them for a direction, after which only listed traffic is allowed for that direction.
- Remember
- A policy with podSelector: {} and policyTypes [Ingress] and no rules denies all ingress in its namespace.
- Tested as
- Default-deny plus a specific allow is the most common policy task.
- Trap
- Expecting a policy in one namespace to protect Pods in another.
-
AND vs. OR selectors
Selectors inside one from entry must all match, while separate entries are alternatives.
- Remember
- One dash with namespaceSelector and podSelector means AND; two dashes means OR.
- Tested as
- Graders test that unintended clients are blocked.
- Trap
- Adding a dash before podSelector and opening the policy wide.
-
DNS with default-deny egress
An egress policy that allows only an application port also blocks name resolution.
- Remember
- Allow UDP and TCP 53 to the kube-dns Pods in kube-system when restricting egress.
- Tested as
- Egress tasks fail quietly when the client resolves by name.
- Trap
- Testing with an IP, seeing success, and missing that names fail.
-
port, targetPort and nodePort
These three fields describe the Service's own port, the container port, and the port opened on every node.
- Remember
- targetPort defaults to port if omitted; nodePort is in 30000-32767 unless configured otherwise.
- Tested as
- Expose tasks state two different ports deliberately.
- Trap
- Swapping port and targetPort.
-
EndpointSlices
EndpointSlices list the IPs and ports of ready Pods that match a Service's selector.
- Remember
- Check with kubectl get endpointslices -l kubernetes.io/service-name=NAME; empty means selector or readiness problem.
- Tested as
- The first check for any Service that does not respond.
- Trap
- Debugging kube-proxy before checking that endpoints exist.
-
Headless Service
A Service with clusterIP: None has no virtual IP; DNS returns the ready Pod IPs.
- Remember
- StatefulSets use one to give each Pod a stable DNS name such as web-0.SERVICE.NAMESPACE.svc.cluster.local.
- Tested as
- Questions ask how Pods get individual DNS names.
- Trap
- Expecting load balancing through a ClusterIP on a headless Service.
-
Gateway API roles
GatewayClass, Gateway and HTTPRoute separate the infrastructure provider, cluster operator and application developer concerns.
- Remember
- HTTPRoute parentRefs name the Gateway, optionally with sectionName for a listener; backendRefs name Services and ports.
- Tested as
- Tasks create a route and check that it is Accepted.
- Trap
- Expecting the Gateway API to work without its CRDs and a controller.
-
HTTPRoute weights
backendRefs in a single rule can carry weights, splitting traffic proportionally across Services.
- Remember
- Weights are relative: 90 and 10 send about 90% and 10% of requests.
- Tested as
- Canary and blue-green tasks use this.
- Trap
- Creating two separate rules that match the same path and expecting a split.
-
Ingress pathType
pathType decides how a request path is compared with the rule.
- Remember
- Prefix matches whole path elements; Exact matches only the identical path.
- Tested as
- Tasks with several paths depend on choosing the right type.
- Trap
- Assuming Prefix /app also matches /application.
-
IngressClass
ingressClassName links an Ingress to the controller that will implement it.
- Remember
- Without a class and without a default IngressClass, no controller processes the Ingress.
- Tested as
- An Ingress with no ADDRESS is a classic symptom.
- Trap
- Editing rules repeatedly while the class is missing.
-
Service DNS names
CoreDNS answers for Services as NAME.NAMESPACE.svc.cluster.local.
- Remember
- Short names work in the same namespace; NAME.NAMESPACE works from others.
- Tested as
- DNS tasks ask you to resolve and record a name or fix a lookup.
- Trap
- Treating a cross-namespace short-name failure as a CoreDNS fault.
-
Corefile
The coredns ConfigMap in kube-system holds the Corefile that configures CoreDNS plugins.
- Remember
- The kubernetes plugin serves cluster.local; forward sends other queries upstream.
- Tested as
- Tasks may add a stub domain or change the upstream resolver.
- Trap
- Editing a node's /etc/resolv.conf to change cluster DNS behaviour.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
ClusterIP vs. NodePort vs. LoadBalancer vs. headless
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| ClusterIP | Internal virtual IP reachable only inside the cluster | Default type; no external exposure | Expecting to reach it from outside the cluster |
| NodePort | ClusterIP plus a port in 30000-32767 opened on every node | Reachable at any node IP on that port | Choosing a nodePort outside the allowed range |
| LoadBalancer | NodePort plus an external address from a cloud or load-balancer controller | EXTERNAL-IP stays pending without such a controller | Treating pending as a Service misconfiguration |
| Headless (clusterIP: None) | No virtual IP; DNS returns Pod IPs | Gives per-Pod DNS records for StatefulSets | Expecting kube-proxy load balancing |
Ingress vs. Gateway API
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Ingress | One resource holding host and path rules plus TLS, implemented by an Ingress controller | HTTP and HTTPS only; advanced features rely on controller annotations | Omitting ingressClassName when no default class exists |
| Gateway | Defines listeners with protocol, port and hostname for a GatewayClass | Owned by the cluster operator; routes attach to it | Expecting it to route traffic on its own without any routes |
| HTTPRoute | Matches host, path and headers and sends to backendRefs, with weights | Attaches to a Gateway through parentRefs | Referencing the GatewayClass rather than the Gateway |
NetworkPolicy selector placement
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| namespaceSelector and podSelector in one entry | Selected Pods in selected namespaces | Logical AND | Adding an extra dash and turning it into OR |
| Separate namespaceSelector and podSelector entries | All Pods in selected namespaces, or selected Pods in the policy's namespace | Logical OR | Assuming podSelector here searches other namespaces |
| ipBlock | CIDR ranges with optional except | Meant for traffic from outside the cluster | Using it for Pod IPs, which change on rescheduling |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Selector OR by accident
- What candidates pick
- Two list items in from: one namespaceSelector and one podSelector.
- Why it looks right
- It reads naturally as 'namespace web, pods role=client'.
- Why it's wrong
- Separate items are ORed, so all Pods in web and role=client Pods in the local namespace are allowed.
Clue to watch for A requirement naming both a namespace and a Pod label for the same client.
-
Egress policy breaks names
- What candidates pick
- Allowing egress only to the database port and testing by Service name.
- Why it looks right
- The rule matches the requirement exactly.
- Why it's wrong
- DNS lookups to kube-dns on port 53 are now denied, so the name never resolves.
Clue to watch for Any default-deny egress requirement where clients use DNS names.
-
Service with no endpoints
- What candidates pick
- Recreating the Service or restarting kube-proxy when requests time out.
- Why it looks right
- The Service object is the visible broken thing.
- Why it's wrong
- The usual cause is a selector that does not match Pod labels or Pods that are not ready, which leaves the endpoint list empty.
Clue to watch for kubectl describe service showing Endpoints: <none>.
-
Route not attached
- What candidates pick
- Writing an HTTPRoute with correct rules and assuming it is live.
- Why it looks right
- kubectl apply succeeded without error.
- Why it's wrong
- If parentRefs, namespace or listener allowedRoutes do not match, the route is not accepted and serves nothing.
Clue to watch for The route's status conditions, which show Accepted False with a reason.
-
Prefix path surprise
- What candidates pick
- Using pathType Prefix /api and expecting /apiv2 to match, or expecting it not to match /api/v2.
- Why it looks right
- Prefix sounds like a string prefix.
- Why it's wrong
- Matching is by path element, so /api matches /api/v2 but not /apiv2.
Clue to watch for Example paths in the task that differ by a slash.
-
LoadBalancer pending
- What candidates pick
- Changing Service type or ports when EXTERNAL-IP stays pending.
- Why it looks right
- It looks like the Service failed.
- Why it's wrong
- LoadBalancer needs a cloud provider or a load-balancer controller; without one, the Service still works as a NodePort.
Clue to watch for A bare-metal or lab cluster with no controller mentioned.
-
Short name across namespaces
- What candidates pick
- Concluding CoreDNS is broken because nslookup api fails from another namespace.
- Why it looks right
- The same command works from the Service's own namespace.
- Why it's wrong
- Short names resolve only within the Pod's namespace through its search list.
Clue to watch for Client and Service in different namespaces.
Answer framework
Use this path for any traffic task, working outwards from the Pod to the client.
- Confirm the target Pods are Running and Ready and note their labels and container port with kubectl get pods --show-labels and describe.
- Create or check the Service, making sure the selector matches those labels and targetPort matches the container port, then confirm EndpointSlices are populated.
- Add the entry path the task names, Ingress or Gateway API, and check the class, parentRefs, hostnames and path type against the requirement.
- Apply NetworkPolicies last, writing selectors in the exact AND or OR structure required and allowing DNS when egress is restricted.
- Test from a temporary Pod in the client's namespace with wget, curl or nslookup, checking both the allowed path and one path that should be blocked.
Practice question
Want more like this? The CKA practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with Services, because everything else in the domain routes to one. Expose a Deployment every way, break the selector and the targetPort on purpose, and learn to read EndpointSlices and kubectl describe service until an empty endpoint list is the first thing you check.
Then move to NetworkPolicies, the highest-risk topic here. Use a CNI that enforces policies, such as Calico or Cilium, write default-deny first, and add allows one at a time while testing from client Pods in different namespaces. Practise the one-dash versus two-dash difference until you can predict the result before applying.
The area most often underestimated is the Gateway API, added in the 2025 curriculum. Install a Gateway controller in your lab, create a Gateway and HTTPRoutes, and read route status conditions. Practise converting a simple Ingress into an HTTPRoute so you can work with either model.
Finish with CoreDNS: resolve names from different namespaces, inspect /etc/resolv.conf in a Pod, and read the Corefile. Afterwards, do timed tasks that combine a Service, a policy and a route, and verify every one from a client Pod.
FAQ
How much of the CKA is Services and Networking?
The Linux Foundation weights it at 20%. Expect several tasks across Services, policies, routing and DNS.
Is the Gateway API really on the CKA?
Yes. 'Use the Gateway API to manage Ingress traffic' is a competency in the current curriculum, alongside Ingress, so practise GatewayClass, Gateway and HTTPRoute objects.
Do I still need to learn Ingress?
Yes. 'Know how to use Ingress controllers and Ingress resources' remains a separate competency, so be able to write rules with ingressClassName, pathType and TLS.
Why does my NetworkPolicy have no effect?
Either no policy selects the target Pods for that direction, or the cluster's CNI plugin does not enforce policies. Check the podSelector and policyTypes first.
Which CNI plugin will the exam use?
The exam clusters come with networking already working for most tasks. You need to understand what the CNI does and where its configuration lives rather than master any one plugin.
How do I test connectivity quickly?
Run a temporary Pod with kubectl run tmp --rm -it --image=busybox --restart=Never -- sh, then use wget -qO- or nslookup against the target from inside it.
How does this domain relate to Troubleshooting?
Troubleshoot services and networking is a Troubleshooting competency, so the same endpoint, DNS and policy checks you learn here are used to fix broken traffic there.
Test your Domain 3 knowledge
Practise exposing workloads, writing exact NetworkPolicies and routing with the Gateway API, verifying each from a client Pod.