Linux Foundation KCNA: Kubernetes Pod Networking
Kubernetes assumes that each Pod receives its own cluster-reachable IP address and that Pods can communicate across nodes according to the cluster network model unless policy intentionally restricts the traffic. Kubernetes defines the model and APIs, while a network implementation—commonly through CNI—provides the data plane that makes those addresses and routes real.
Within cloud-native infrastructure, Pod networking is the layer that connects scheduling to application communication. The current KCNA competencies include networking under container orchestration, and Kubernetes documentation separates Pod networking from Service proxying, NetworkPolicy, and external ingress.
Troubleshooting improves when engineers ask whether a failure is name resolution, Service selection, Pod routing, policy enforcement, host networking, or application listening. “The network is broken” is rarely precise enough.
Start with the Kubernetes network model
A Pod receives a network namespace shared by its containers. Containers in the same Pod use localhost to communicate with each other, while Pod-to-Pod communication uses the cluster network. The design avoids requiring application-level port mapping between Pods as a basic connectivity mechanism.
Container runtimes cooperate with the networking layer during Pod sandbox creation, which is why CNI or runtime errors can prevent a Pod from becoming ready even when the application image is valid.
Understand the role of CNI
Kubernetes delegates Pod network implementation to external components. On Linux, many runtimes use Container Network Interface plugins to attach the Pod namespace to the cluster network, allocate or configure addresses, establish routes, and sometimes enforce network policy.
Different CNI implementations can realize the model with overlays, native routing, eBPF, cloud networking, or other approaches. Troubleshooting should therefore begin with the Kubernetes invariant and then inspect the implementation-specific path.
Trace a packet from source Pod to destination Pod
Identify the source Pod IP, destination Pod IP, source node, destination node, CNI interface, routing decision, and policy controls. If same-node traffic works but cross-node traffic fails, the problem space narrows dramatically toward inter-node routing, encapsulation, security groups, or underlay reachability.
Linux networking remains relevant because the Kubernetes network is ultimately implemented through interfaces, routes, sockets, filters, and kernel behavior on real nodes.
Keep Services separate from Pod addresses
A Service provides a stable virtual identity for a changing set of Pod backends. It does not replace the Pod network; traffic still has to reach an EndpointSlice-selected backend. When a Service fails, verify selectors and endpoints before debugging CNI routing.
Service discovery adds DNS names and stable Service addressing on top of this changing Pod population.
Treat NetworkPolicy as an implementation-dependent control
Kubernetes exposes the NetworkPolicy API, but enforcement depends on the network implementation. A policy object can exist while having no effect if the CNI does not implement it. Audits and troubleshooting therefore need to verify both policy configuration and actual data-plane enforcement.
Default-deny designs are safer when teams know which DNS, monitoring, control-plane, identity, and egress paths workloads genuinely require. Otherwise policies are quickly weakened with broad exceptions.
Account for host networking and node paths
Pods using host networking behave differently because they share the node network namespace. Node-local agents, ingress components, storage plugins, and monitoring systems may also use privileged or host-network paths that bypass assumptions made for ordinary workloads.
Document these exceptions because they often explain why a control appears inconsistent across workloads.
Check cloud and underlay boundaries
In managed clusters, cloud routes, virtual networks, firewall rules, security groups, load balancers, and private endpoints can influence Pod connectivity. A valid Kubernetes configuration cannot overcome an underlay path that blocks node or Pod traffic.
EKS networking is an example of how cloud-native networking combines Kubernetes concepts with provider-specific address and routing behavior.
Use events and node evidence before packet captures
Pod events can reveal sandbox and CNI setup failures before a packet is ever sent. Node logs can show plugin errors, address exhaustion, or route-programming problems. Start with those control-plane clues and move to packet captures only when the problem requires data-plane proof.
Kubernetes events help establish whether the issue began at scheduling, startup, networking, storage, or readiness.
Design address space for growth
Clusters need enough Pod and Service address capacity for expected scale, upgrades, node pools, and failure recovery. Address exhaustion can look like intermittent scheduling or CNI failure because older workloads continue to run while new Pods cannot obtain usable network identity.
Plan cluster CIDRs and integration with enterprise networks early. Renumbering a production cluster is far more disruptive than reserving sufficient space during platform design.
Use connectivity tests that isolate layers
Test local process listening, Pod IP reachability, same-node and cross-node paths, Service virtual IP, DNS resolution, and external egress separately. One broad “curl failed” observation cannot tell which layer is broken.
The Linux Foundation cloud-native curriculum treats networking as a foundational orchestration competency. The practical skill is being able to reason through the path from a Pod process to the destination instead of guessing from symptoms.
Use NetworkPolicy with explicit dependency maps
NetworkPolicy becomes difficult when teams do not know which flows the application actually needs. Document namespace, label, port, protocol, DNS, telemetry, identity, database, and external-service dependencies before moving to default-deny. Otherwise broad exceptions accumulate until the policy exists only on paper.
Test policy from representative Pods because control-plane configuration alone does not prove enforcement. Verify allowed flows still work and denied flows actually fail. Include egress as well as ingress where the threat model requires it.
Policies should use stable labels tied to workload identity rather than ephemeral Pod IPs. That keeps enforcement aligned with controllers as Pods are recreated.
Watch MTU and encapsulation symptoms
Overlay networking, VPNs, cloud underlays, and encryption can reduce the usable maximum transmission unit. Small requests may work while larger packets fragment, stall, or fail, producing confusing application symptoms. If cross-node or cross-network traffic fails only for larger payloads, MTU belongs in the investigation.
Measure rather than guess. Compare interface MTUs, CNI configuration, tunnel overhead, and path behavior. Adjusting application buffers or random timeouts rarely fixes a packet-size problem.
MTU issues are a good example of why Kubernetes networking must be connected to the physical or virtual underlay. Cluster objects can be correct while the path beneath them still breaks traffic.
Design troubleshooting around repeatable probes
Maintain a small set of known-good diagnostic images and commands that can test DNS, TCP reachability, HTTP, routes, interfaces, and policy from within the cluster. This reduces time spent installing tools during an incident and produces comparable results across namespaces and nodes.
Do not leave privileged troubleshooting Pods running permanently. Launch them with the minimum rights and remove them after use, especially if they contain packet-capture or network-administration capabilities.
Record the probe path and result in incident notes. A sequence such as “DNS succeeds, Service IP succeeds, direct Pod IP fails cross-node” communicates far more than “network issue suspected.”
Dual-stack clusters add another dimension because Pods and Services can have IPv4 and IPv6 addresses and applications may prefer one family depending on resolver and library behavior. If the platform supports both, test the actual family used by the workload instead of assuming success over IPv4 proves the IPv6 path or vice versa.
Network observability should expose more than packet counts. Flow logs, policy verdicts, connection failures, DNS latency, dropped packets, and node-level errors can help teams distinguish application refusal from routing or policy loss. The exact telemetry depends on the CNI and cloud environment, but the diagnostic questions remain stable.
Service meshes and sidecars can add another hop between an application socket and the network. When a mesh is present, document which traffic is intercepted, how identity and policy are applied, and how to bypass or test the proxy safely during troubleshooting. Otherwise engineers can spend hours debugging Kubernetes networking for a failure created in the service proxy layer.
Finally, treat connectivity as a dependency with owners. Platform teams may own CNI and cluster routes, security teams may own policy, cloud teams may own virtual networks, and application teams own listening ports and readiness. Incident playbooks should show those boundaries so evidence reaches the right owner quickly.
Topology-aware routing and multi-zone clusters add performance and resilience considerations. Keeping traffic near local backends can reduce latency and cross-zone cost, but failover still needs enough reachable capacity elsewhere. Network design should not optimize locality so aggressively that a zone failure removes the only usable path.
In incident review, capture the precise network layer that failed and the evidence that proved it. This creates reusable knowledge for platform teams and helps prevent future troubleshooting from repeating the same broad sequence of guesses.
Capacity planning belongs in networking as well. Pod density, address allocation, conntrack limits, NAT gateways, load balancers, and policy engines can all become scale constraints before CPU is exhausted. Monitor these shared network resources and include them in growth testing so a cluster does not appear healthy until the day new Pods can no longer obtain reliable connectivity.
Capacity evidence should be captured before and during major releases so network exhaustion is identified as a predictable limit rather than an unexplained outage.
Document it.