In the context of the Certified Kubernetes Administrator (CKA) exam, understanding Pod connectivity is anchored in the 'IP-per-Pod' model. Unlike legacy container networking which relied on port mapping, Kubernetes mandates a flat network structure where every Pod receives a unique IP address that …In the context of the Certified Kubernetes Administrator (CKA) exam, understanding Pod connectivity is anchored in the 'IP-per-Pod' model. Unlike legacy container networking which relied on port mapping, Kubernetes mandates a flat network structure where every Pod receives a unique IP address that is routable within the cluster.
The fundamental requirements for this network model, implemented by CNI (Container Network Interface) plugins like Calico, Flannel, or Cilium, are:
1. Pod-to-Pod: All Pods can communicate with all other Pods without Network Address Translation (NAT), regardless of which node they reside on.
2. Node-to-Pod: Agents on a node (e.g., system daemons, Kubelet) can communicate with all Pods on that node.
3. Host Network: Pods in the host network of a node can communicate with all Pods on all nodes without NAT.
Mechanically, inside a single node, connectivity is often handled via a virtual ethernet bridge and veth pairs connecting the Pod's network namespace to the root namespace. Across nodes, the CNI plugin manages routing via overlay networks (encapsulation like VXLAN) or direct routing protocols (like BGP) to ensure packets reach the destination node.
Crucially for the CKA, you must remember that this connectivity is open by default; any Pod can reach any other Pod. To restrict this, you must implement Network Policies, which serve as an in-cluster firewall. A Network Policy selects groups of Pods using labels and defines specific allow-list rules for Ingress (incoming) and Egress (outgoing) traffic. Mastery of this topic involves not just ensuring connectivity works (debugging via `ping` or `curl` from ephemeral containers), but also securing it explicitly.
Guide: Understanding Connectivity Between Pods (CKA)
Introduction In the Certified Kubernetes Administrator (CKA) curriculum, under the Services & Networking domain, understanding how Pods communicate with one another is fundamental. Kubernetes imposes a specific set of network requirements regarding Pod connectivity, often referred to as the "flat network" model.
Why is it Important? Microservices architecture relies on distinct components (running in Pods) communicating over the network. If Pod A (frontend) cannot reach Pod B (backend), the application fails. Unlike Docker default networking which relies heavily on NAT (Network Address Translation) and port mapping per host, Kubernetes requires a seamless communication layer where IP addresses remain consistent regardless of which node a Pod is on.
What is it? The Kubernetes Networking Model Kubernetes mandates three fundamental rules for Pod connectivity: 1. All Pods can communicate with all other Pods without using NAT. 2. All Nodes can communicate with all Pods (and vice-versa) without using NAT. 3. The IP that a Pod sees itself as is the same IP that others see it as.
To achieve this, Kubernetes relies on CNI (Container Network Interface) plugins (like Calico, Flannel, Weave Net, or Cilium). These plugins configure the underlying network namespace, bridges, and routing tables on the Linux nodes to ensure packets flow correctly.
How it Works Intra-Node Communication (Same Node): When two Pods are on the same node, they communicate via a Linux Bridge (often named cni0 or similar). Packet flow: Pod A -> veth pair -> Bridge -> veth pair -> Pod B.
Inter-Node Communication (Different Nodes): When Pods are on different nodes, the CNI plugin handles the routing. This is often done via: - Overlay Networks (Encapsulation): Wrapping packets (e.g., VXLAN) to send them across the underlying node network. - Direct Routing (BGP/L3): Configuring the physical network routers to know where Pod IPs exist (common in on-prem or advanced cloud setups).
How to Answer Questions on Pod Connectivity In the CKA exam, you will likely face scenarios where connectivity is broken, or you need to test it. Follow this troubleshooting workflow:
1. Identify the IPs: Use kubectl get pods -o wide to find the IP addresses of the source and destination Pods and which Nodes they are running on. 2. Test Basic Connectivity: Exec into the source Pod and use standard Linux tools. kubectl exec -it pod-name -- ping destination-ip kubectl exec -it pod-name -- curl destination-ip:port kubectl exec -it pod-name -- nslookup service-name (to rule out DNS issues) 3. Check Network Policies: This is the most common "logical" blocker in the CKA exam. By default, all traffic is allowed. If a NetworkPolicy exists, it isolates the Pods, blocking traffic unless explicitly whitelisted. 4. Check CNI State: If Pods are stuck in Pending or simply cannot ping anywhere, check if the CNI pods (usually in kube-system) are running (e.g., kubectl get pods -n kube-system).
Exam Tips: Answering Questions on Understand connectivity between Pods
Tip 1: Isolate the Layer Determine if it is a DNS issue or an IP issue. If ping 10.244.1.5 works but ping my-service fails, it is CoreDNS, not Pod connectivity. If IP ping fails, it is Networking or Network Policies.
Tip 2: The NetworkPolicy Trap If a question asks why Pod A cannot connect to Pod B, immediately check: kubectl get networkpolicy --all-namespaces. If you see a policy selecting the destination Pods, read the Ingress rules carefully.
Tip 3: Multi-Container Pods Sometimes the exam environment provides Pods without ping or curl. You might need to edit the Pod manifest to use an image containing these tools (like busybox or nginx:alpine) or create a temporary debug Pod: kubectl run debug --image=busybox --restart=Never -- sleep 3600.
Tip 4: CNI Logs If the question involves a cluster where Pods won't start, check the CNI logs. For example: kubectl logs -l k8s-app=calico-node -n kube-system. This typically indicates a misconfiguration in the CNI installation.