Trace the traffic paths: pod-to-pod, pod-to-Service, and internet-to-cluster.
Quick Answer
Pod-to-pod: direct routing over the CNI's flat network, no NAT. Pod-to-Service: the client hits a stable ClusterIP that kube-proxy (or eBPF) load-balances to a backend pod IP. Internet-to-cluster: external LB → Ingress controller → Service → pod.
Detailed Answer
Pod-to-pod: the Kubernetes model guarantees every pod has a unique, routable IP and can reach any other pod without NAT; the CNI plugin implements this via overlay or L3 routing, so it's essentially direct. Pod-to-Service: a Service is a virtual IP with no process behind it — the client connects to the ClusterIP, and kube-proxy's iptables/IPVS rules (or a CNI's eBPF) DNAT the connection to one of the healthy backend pod IPs from the Service's Endpoints, load-balancing across them. Internet-to-cluster (north-south): external traffic hits a cloud load balancer, which forwards to the Ingress controller pods (via a NodePort/LoadBalancer Service), the Ingress controller terminates TLS and routes by host/path to the target Service, which fans out to pods. Knowing these three paths explains most connectivity debugging: DNS resolves the name, Endpoints list the backends, and kube-proxy/CNI carry the packets.
Code Example
kubectl get endpoints my-svc # the pod IPs behind the Service VIP kubectl get ingress # host/path -> Service (north-south) # east-west: pod -> ClusterIP -> (kube-proxy DNAT) -> pod IP
Interview Tip
Structure the answer as three named paths (east-west pod↔pod, pod↔Service via kube-proxy DNAT, north-south via Ingress). Tying debugging to DNS→Endpoints→kube-proxy shows you can actually troubleshoot connectivity.