Back to Certified Kubernetes Administrator (CKA)

Services & Networking

Configure and manage Kubernetes networking, services, and network policies (20% of exam).

This domain covers understanding connectivity between Pods, defining and enforcing Network Policies, using ClusterIP, NodePort, LoadBalancer service types and endpoints, using the Gateway API to manage Ingress traffic, knowing how to use Ingress controllers and Ingress resources, and understanding and using CoreDNS.
5 minutes 5 Questions

In the context of the CKA exam, Services and Networking form the backbone of cluster communication. Because Pods are ephemeral and their IP addresses change, **Services** define a logical set of Pods and a policy to access them. You must understand the four primary Service types: **ClusterIP** (def…

Concepts covered: Understand connectivity between Pods, Define and enforce Network Policies, Use ClusterIP, NodePort, LoadBalancer service types and endpoints, Use the Gateway API to manage Ingress traffic, Know how to use Ingress controllers and Ingress resources, Understand and use CoreDNS, Kubernetes networking model, CNI plugins and configuration, Service discovery and DNS, Endpoints and EndpointSlices, External traffic policy and session affinity, Headless services

Test mode:
Start practice test
CKA - Services & Networking Example Questions

Test your knowledge of Services & Networking

Question 1

A Kubernetes cluster uses a CNI plugin that implements the standard networking model. A pod running on worker-node-1 with IP 10.244.1.15 needs to communicate with a pod on worker-node-2 with IP 10.244.2.23. When the receiving pod inspects incoming traffic, what source IP address does the Kubernetes networking model require it to observe?

Correct Answer: The original sending pod's IP address 10.244.1.15 as assigned by the CNI

The Kubernetes networking model has a fundamental requirement that all pods can communicate with each other across nodes using their actual pod IP addresses, with no Network Address Translation (NAT) occurring. This is one of the core principles of Kubernetes networking.

When a pod on worker-node-1 (with IP 10.244.1.15) sends traffic to a pod on worker-node-2 (with IP 10.244.2.23), the receiving pod must see the original source IP address of 10.244.1.15. This is explicitly stated in the Kubernetes networking requirements: pods must be able to communicate with all other pods on any other node with their original IP address preserved.

The answer suggesting the worker node IP would be used is incorrect because the Kubernetes networking model explicitly prohibits NAT between pods. The source IP should never be translated to the node's IP address during pod-to-pod communication.

The answer suggesting a virtual gateway IP is incorrect because CNI plugins implementing the standard Kubernetes networking model do not insert gateway IPs as source addresses. The traffic must appear to come from the actual pod IP.

The answer suggesting the source IP depends on kube-proxy mode is incorrect because kube-proxy handles Service traffic routing, not pod-to-pod communication. Pod-to-pod communication goes through the CNI networking layer, and regardless of kube-proxy configuration, the networking model requires the original pod IP to be preserved for inter-pod traffic.

Question 2

A DevOps engineer is creating a headless Service for a ZooKeeper ensemble running as a StatefulSet with 3 replicas. The pods are named zk-0, zk-1, and zk-2 in the 'data' namespace, and the headless Service is named 'zk-hs'. When the engineer queries the DNS from within the cluster, what type of response should they expect from a lookup against 'zk-hs.data.svc.cluster.local'?

Correct Answer: Multiple A records are returned, each containing the IP address of an individual pod backing the Service

When querying a headless Service in Kubernetes, the DNS lookup returns multiple A records, each containing the IP address of an individual pod backing the Service.

A headless Service is created by setting the clusterIP field to 'None'. This configuration tells Kubernetes not to allocate a virtual IP address for the Service. Instead, when a DNS query is made against the headless Service name (in this case 'zk-hs.data.svc.cluster.local'), the DNS server returns A records for each of the ready pods that match the Service selector.

For a StatefulSet with 3 replicas (zk-0, zk-1, zk-2), the DNS query would return 3 A records, each containing the actual pod IP address. This is particularly useful for stateful applications like ZooKeeper where clients need to discover and connect to specific pod instances.

The option suggesting a CNAME record pointing to a StatefulSet controller is incorrect because Kubernetes DNS does not use CNAME records in this manner for headless Services.

The option mentioning cluster-assigned virtual IP addresses is incorrect because headless Services specifically do not have a cluster IP - that's what makes them 'headless'. The whole point is to expose the actual pod IPs rather than a virtual IP.

The option describing a single A record with a load-balanced virtual IP is incorrect because this describes the behavior of a regular ClusterIP Service, not a headless Service. Headless Services do not perform load balancing at the DNS level; they simply return all pod IPs and let the client decide which one to connect to.

Question 3

In Kubernetes, how do Pods within the same cluster communicate with each other by default?

Correct Answer: Each Pod gets its own IP address and can reach other Pods using their IP addresses

The correct answer states that each Pod gets its own IP address and can reach other Pods using their IP addresses.

In Kubernetes, the networking model is designed with a flat network structure where every Pod receives a unique IP address. This is a fundamental principle of Kubernetes networking. Pods can communicate with each other using these IP addresses, regardless of which node they are running on. This is made possible by the Container Network Interface (CNI) plugins that implement this networking model.

The answer suggesting that Pods must use NodePort services for communication is incorrect because NodePort services are used to expose services externally to the cluster. Pod-to-Pod communication within a cluster does not require NodePort services - Pods can reach each other through their assigned IP addresses.

The answer claiming that Pods share the same IP address as the node with port mapping is incorrect. This describes a different networking model. In Kubernetes, Pods have their own IP addresses that are separate from the node's IP address. Port mapping is not the default mechanism for inter-Pod communication.

The answer about a shared network namespace with identical IP addresses for all Pods is also incorrect. While containers within the same Pod share a network namespace, different Pods have their own separate network namespaces with unique IP addresses. Having identical IPs for all Pods would make routing impossible.

More Services & Networking questions
367 questions (total)
Start 100 question test