Overview
Services and Networking covers how traffic reaches application Pods. You expose a Deployment with a ClusterIP, NodePort or LoadBalancer Service and make sure its selector, port and targetPort match the Pods. When a Service does not answer, you check its endpoints: an empty list means the selector matches no ready Pods, while endpoints that refuse connections point to the wrong targetPort. You also use cluster DNS names such as service.namespace.svc.cluster.local to reach Services across namespaces.
NetworkPolicy questions stay at a basic level compared with the CKS. You read or write policies that allow ingress from Pods with certain labels, restrict egress, or apply a default deny, and you often fix connectivity by adding the right labels to Pods instead of editing policies. Ingress tasks ask you to route a host and path to a Service port with the correct pathType and ingressClassName.
How it's tested
Networking tasks usually involve a connection that should or should not work. You may expose a Deployment on a named port, repair a Service whose endpoints are empty, label Pods so an existing NetworkPolicy lets them talk, or route a path on an Ingress host to a backend. Graders often test with real requests.
-
Expose and type
Create a Service of a stated type, port and targetPort for a Deployment, sometimes with a fixed nodePort in the 30000-32767 range.
-
Repair connectivity
A Service returns nothing or times out, and you correct its selector, targetPort or the Pod labels until endpoints appear and requests succeed.
-
Policy-aware labelling
Existing NetworkPolicies allow traffic only between certain labels, and you label or relabel Pods so the required flow works and others stay blocked.
Service backend has no endpoints although three Pods are Running. The Service selects app=backend, while the Pods are labelled app=back-end. Changing the Service selector to match, or relabelling the Deployment's Pod template, makes the endpoints appear. Changing the Service type to NodePort would not help, because every Service type relies on the same selector to find Pods.
Competencies 3
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
5.1 Demonstrate basic understanding of NetworkPoliciesReading and writing simple ingress and egress NetworkPolicies.
- What it means
- NetworkPolicies restrict which connections Pods accept or make. They select Pods by label and allow traffic from or to other Pods, namespaces or IP ranges on listed ports.
- What to understand
- Once a policy selects a Pod for a direction, only allowed traffic passes in that direction; unselected Pods accept everything. Policies add together, so another policy can only allow more. Use podSelector, namespaceSelector and ipBlock in from and to lists, with ports and protocols. In CKAD tasks it is often quicker to label a Pod so an existing policy covers it than to write a new policy. Test with a temporary Pod running wget or nc.
- How it shows up
- Expect to make one Pod reachable from another under existing policies, or write a policy allowing a single source.
- Common confusion
- Thinking a NetworkPolicy can deny a specific flow; policies only allow, and denial comes from selection.
5.2 Provide and troubleshoot access to applications via servicesCreating Services and fixing selectors, ports and endpoints.
- What it means
- A Service gives a stable virtual IP and DNS name to a changing set of Pods matched by a label selector. Its type decides whether it is reachable only inside the cluster or from outside.
- What to understand
- ClusterIP is internal; NodePort opens a port from 30000-32767 on every node; LoadBalancer requests an external load balancer; a headless Service with clusterIP None returns Pod IPs directly. port is what clients use, targetPort is the container port, and nodePort is the node port. Create with kubectl expose or kubectl create service. Troubleshoot with kubectl get endpointslices or endpoints, kubectl describe svc and requests from a test Pod.
- How it shows up
- Expect to expose a Deployment with exact ports and type, or repair a Service that has no endpoints.
- Common confusion
- Copying the Service port into targetPort although the application inside the container listens on another port.
5.3 Use Ingress rules to expose applicationsHost and path routing to Services through an Ingress.
- What it means
- An Ingress defines HTTP and HTTPS routing rules from hostnames and paths to Services. An Ingress controller in the cluster reads those rules and does the routing.
- What to understand
- Each rule has an optional host and a list of paths with pathType Prefix, Exact or ImplementationSpecific and a backend of service name and port number or name. Set spec.ingressClassName to the class the cluster provides. kubectl create ingress name --class=x --rule='host/path=svc:port' builds one quickly. Test with curl using the host header or --resolve. A defaultBackend catches requests that match no rule.
- How it shows up
- You may add a path rule to an existing Ingress or create one that routes a host to a Service port.
- Common confusion
- Pointing the backend at a Pod or Deployment name instead of a Service.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Service selector
Labels a Service uses to find Pods.
- Remember
- Every selector label must be present on a Pod for it to match.
- Tested as
- Most broken Service tasks come back to this.
- Trap
- Copying the Deployment's selector field instead of checking the Pod template labels.
-
port, targetPort, nodePort
Client port, container port and node port of a Service.
- Remember
- targetPort can be a named container port.
- Tested as
- Exact ports are graded.
- Trap
- Mixing up port and targetPort.
-
Endpoints and EndpointSlices
Lists of ready Pod IPs behind a Service.
- Remember
- Empty means no matching ready Pods.
- Tested as
- First check for an unreachable Service.
- Trap
- Assuming Running Pods are always listed; readiness controls it.
-
Service types
ClusterIP, NodePort, LoadBalancer and ExternalName.
- Remember
- NodePort range is 30000-32767 by default.
- Tested as
- Tasks state the type needed.
- Trap
- Expecting a LoadBalancer to get an external IP in a lab without a provider.
-
Cluster DNS
Services resolve as name.namespace.svc.cluster.local.
- Remember
- The short name works only inside the same namespace.
- Tested as
- Cross-namespace connectivity tasks.
- Trap
- Using the short name from another namespace.
-
kubectl expose
Creates a Service from an existing workload's labels.
- Remember
- --port, --target-port, --type and --name set the details.
- Tested as
- Fastest way to expose a Deployment.
- Trap
- Exposing a Pod whose labels differ from the Deployment's other Pods.
-
NetworkPolicy selection
A Pod becomes isolated for a direction when a policy selects it.
- Remember
- Unselected Pods have no restrictions.
- Tested as
- Explains why some Pods ignore a policy.
- Trap
- Expecting a policy in one namespace to isolate Pods in another.
-
Labelling to satisfy a policy
Adding a label lets a Pod match an existing allow rule.
- Remember
- Change the Deployment template so new Pods keep the label.
- Tested as
- Common quick fix in CKAD tasks.
- Trap
- Labelling only the running Pod, which loses the label on replacement.
-
Ingress pathType
Prefix matches path segments; Exact matches only the full path.
- Remember
- ImplementationSpecific depends on the controller.
- Tested as
- Routing tasks state the match type.
- Trap
- Assuming Prefix /api matches /apiv2; it matches by segment.
-
ingressClassName
Names the controller that should handle an Ingress.
- Remember
- Check kubectl get ingressclass for the available class.
- Tested as
- Without it, routing may not be set up.
- Trap
- Using the older kubernetes.io/ingress.class annotation.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Service types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| ClusterIP | Internal virtual IP only | Default type | Expecting access from outside the cluster |
| NodePort | Opens a port on every node | Port in 30000-32767 | Picking a nodePort outside the range |
| LoadBalancer | Requests a cloud or external load balancer | Builds on NodePort and ClusterIP | Waiting on a pending external IP in a lab |
| Headless | clusterIP None; DNS returns Pod IPs | No virtual IP or load balancing | Using it when a stable single IP is needed |
Why a Service does not answer
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| No endpoints | Selector matches no ready Pods | Fix labels, selector or readiness | Changing ports instead |
| Connection refused | Endpoints exist but nothing listens on targetPort | Fix targetPort or containerPort | Recreating the Service unchanged |
| Timeout | Traffic blocked, often by a NetworkPolicy | Check policies selecting the Pods | Assuming the application is down |
Ingress compared with a Service
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Service | Layer 4 access to a set of Pods | Works with any TCP or UDP protocol | Expecting host or path routing |
| Ingress | Layer 7 HTTP routing by host and path to Services | Needs a running Ingress controller | Pointing a rule straight at Pods |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Fixing the wrong layer
- What candidates pick
- Changing Service type to NodePort when a Service has no endpoints.
- Why it looks right
- Exposure seems to be the problem.
- Why it's wrong
- Type does not change which Pods are selected; empty endpoints mean a selector or readiness issue.
Clue to watch for kubectl get endpoints showing none.
-
Policy edited instead of labels
- What candidates pick
- Rewriting an existing NetworkPolicy.
- Why it looks right
- The policy looks like what is blocking traffic.
- Why it's wrong
- Tasks often check that existing policies stay unchanged and expect the Pod labels to be corrected.
Clue to watch for Wording such as 'do not modify the NetworkPolicies'.
-
Temporary label
- What candidates pick
- kubectl label pod for a Deployment Pod.
- Why it looks right
- It fixes the test immediately.
- Why it's wrong
- The next rollout or restart creates Pods from the template without the label, and the grader may check the Deployment.
Clue to watch for Pods owned by a Deployment.
-
Wrong DNS name
- What candidates pick
- Using the short Service name from another namespace.
- Why it looks right
- It works in your own namespace tests.
- Why it's wrong
- Short names resolve only within the client's namespace; cross-namespace calls need name.namespace.
Clue to watch for Client and Service in different namespaces.
-
Backend port mismatch
- What candidates pick
- Ingress backend using the container port.
- Why it looks right
- That is where the app listens.
- Why it's wrong
- Ingress backends reference the Service port, which may differ from the container port.
Clue to watch for A Service whose port and targetPort differ.
-
Exact versus Prefix
- What candidates pick
- pathType Exact for a path that should include subpaths.
- Why it looks right
- Exact sounds more precise and safe.
- Why it's wrong
- Exact matches only the full path, so requests to subpaths fall through to no backend.
Clue to watch for A requirement to route /app and everything under it.
Answer framework
Use these steps for any task about reaching, exposing or restricting an application over the network.
- Trace the full path from client to Pod: DNS name, Service port, targetPort, Pod label and container port.
- Check the Service with kubectl describe and kubectl get endpoints to see whether its selector finds ready Pods on the expected port.
- List NetworkPolicies in the namespace and work out which ones select the source and destination Pods, and in which direction.
- Apply the smallest fix at the right object: Service selector or ports, Deployment template labels, policy rule or Ingress path.
- Test from a temporary Pod with wget, curl or nc, or with curl against the Ingress host, before moving on.
Practice question
Want more like this? The CKAD practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Use a lab cluster with a CNI that enforces NetworkPolicies, such as Calico or Cilium, and an Ingress controller installed. Start with Services. Expose a Deployment several ways, then break it on purpose with a wrong selector, a wrong targetPort and a failing readiness probe, and check endpoints after each break to learn what each symptom looks like.
Next, practise NetworkPolicies at the CKAD level. Deploy frontend, api and db Pods with labels, apply a default deny, then allow frontend to api and api to db. Test every pair with a temporary Pod. Repeat the exercise by changing only labels while leaving policies alone, which mirrors a common task style.
Finish with Ingress. Create a two-host Ingress with kubectl create ingress, add a path to an existing one with kubectl edit, and test with curl -H 'Host: name' against the controller address. Note the ingressClassName your cluster uses. Do a final drill of five networking tasks in twenty-five minutes.
FAQ
How much of the CKAD exam is Services and Networking?
Services and Networking accounts for 20% of the CKAD score in the official curriculum. Expect three or four tasks on Services, NetworkPolicies and Ingress.
How deep are NetworkPolicy questions on the CKAD?
The curriculum asks for a basic understanding. Expect to read existing policies, write simple allow rules and fix connectivity by labelling Pods, rather than complex multi-namespace designs.
Is the Gateway API part of the CKAD?
No. The current CKAD curriculum names Services, NetworkPolicies and Ingress rules only. Gateway API is not listed as a competency.
Which Ingress controller is used in the exam?
The Linux Foundation does not name one in the curriculum. Write controller-neutral Ingress objects and set ingressClassName to the class listed by kubectl get ingressclass.
How do I test a Service quickly?
Run kubectl run tmp --rm -it --image=busybox --restart=Never -- wget -qO- svc.ns:port, or use a curl image. The Pod is removed when the command exits.
Why does my LoadBalancer Service show a pending external IP?
No load balancer provider is installed in that cluster. The Service still works internally and through its automatically allocated NodePort.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
Practise exposing Deployments, fixing empty Service endpoints, labelling Pods for NetworkPolicies and writing Ingress rules under realistic time pressure.