Services & Networking

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.

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.

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.