City application Pods on different worker nodes must communicate using Pod IPs. What connectivity model should administrators expect from a standard CNI setup (absent NetworkPolicy denials)?
Select an answer to reveal the explanation.
Short Explanation
The Kubernetes networking model is basically a flat phone book: Pod A can dial Pod B's IP anywhere in the cluster unless policy says otherwise. You should not need a LoadBalancer just for Pod-to-Pod chat.
Full Explanation
City application Pods on different worker nodes that must communicate using Pod IPs should expect, from a standard CNI setup absent NetworkPolicy denials, that every Pod IP is reachable from every other Pod across nodes on the cluster network. Flat Pod connectivity across nodes is the baseline networking model Kubernetes CNI plugins provide for east-west traffic between municipal application tiers.
Pods do not only reach each other after an administrator adds NAT hairpin rules per NodePort. Cross-node Pod traffic does not always require a LoadBalancer Service as a mandatory hop. Pods on different nodes do not share one IP and rely on host ports for isolation in the standard model.
Exam caveat: NetworkPolicies can deny paths that the CNI otherwise allows; connectivity assumes a working CNI datapath. Operational check: run test Pods on two nodes, ping or curl Pod IPs, and verify CNI health if cross-node fails while same-node works. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.