Kubernetes Networking

Kubernetes networking answers four questions that every distributed application eventually asks: how do containers in the same Pod talk to each other, how do Pods talk to Pods, how does traffic reach a changing set of Pods reliably, and how does the outside world get in. The platform answers them with a deliberately simple model and a small set of APIs — Services, DNS, Ingress/Gateway, and NetworkPolicy — that hide an enormous amount of moving machinery.

The mental model: every Pod is a small host with its own IP on one flat network. From there, everything else is naming and routing on top — stable virtual names for unstable Pod sets, and controlled doors between the cluster and the world.

The network model

The Kubernetes network model is built from a few rules. Every Pod gets its own cluster-wide IP address, and containers within a Pod share that network namespace — they reach each other over localhost and must coordinate port usage. The pod network (cluster network) ensures all Pods can communicate with all other Pods, whether on the same node or different nodes, directly and without NAT. Agents on a node (like the kubelet) can reach all Pods on that node.

This flat model is a design statement: Kubernetes imposes no per-node port brokering, no mandatory proxies between Pods, and applications can treat Pod-to-Pod traffic like ordinary host-to-host networking. The model is implemented by a network plugin (commonly called a CNI plugin — Cilium, Calico, and friends); Kubernetes defines the contract, the plugin delivers it, and plugin choice is one of the most consequential decisions a cluster operator makes.

Services: stable names for unstable sets

Pods come and go; their IPs come and go with them. A Service provides a stable, long-lived virtual IP (and DNS name) for a set of backend Pods selected by labels. Kubernetes automatically maintains EndpointSlice objects tracking which Pods currently back each Service, and a service proxy on each node (classically kube-proxy) programs the data plane so traffic to the Service address is routed to a healthy backend.

Services come in types that build on each other: ClusterIP (the default — reachable only inside the cluster), NodePort (exposes the Service on a static port of every node), LoadBalancer (provisions an external load balancer through the cloud provider), and ExternalName (a DNS alias to something outside the cluster). A headless Service (clusterIP: None) skips the virtual IP entirely and returns the individual Pod addresses — the mechanism StatefulSets use for per-Pod identity.

Cluster DNS (CoreDNS in practice) makes all of this discoverable: every Service gets a predictable name like web.shop.svc.cluster.local, so applications find each other by name and namespace rather than configuration files full of IPs.

North-south: Ingress and Gateway API

Getting HTTP traffic into the cluster is a separate concern. Ingress is the long-standing API for it: host- and path-based routing rules plus TLS termination, implemented by an ingress controller you must install (the API object does nothing on its own). Ingress is deliberately minimal — and officially frozen: new features go into the Gateway API, its expressive, role-oriented successor, which splits responsibilities across GatewayClass (infrastructure), Gateway (the listening endpoint) and Routes (application routing), and is designed to be portable across implementations and protocols. New designs should look at Gateway API first; existing Ingress setups remain supported and widespread.

NetworkPolicy: taking flatness back

"All Pods can talk to all Pods" is wonderful for simplicity and terrible as a security posture. NetworkPolicy is the API for intentional segmentation: select Pods with labels and declare what ingress and egress traffic they accept, by Pod selector, namespace selector, or IP block. Two facts matter enormously in practice: policies are enforced by the network plugin — a cluster whose plugin doesn't support them will silently ignore them — and Pods are non-isolated until some policy selects them, after which everything not explicitly allowed (in the policy's direction) is denied.

Who needs this, and when

Every Kubernetes user touches Services and DNS from day one — they are how anything finds anything. Ingress or Gateway enters the picture as soon as external users exist. NetworkPolicy becomes non-optional the moment a cluster hosts multiple teams, tenants, or trust levels. Deep plugin internals (routing modes, eBPF data planes, IPAM) belong to cluster operators, but knowing the model keeps application engineers from designing against physics.

Limits and honest caveats

The Service abstraction covers L3/L4 connectivity; it does not give you retries, mutual TLS, traffic splitting, or per-request telemetry — that's the territory of service meshes and L7 proxies layered on top. NetworkPolicy is allow-list segmentation, not a firewall product: no logging of denials, no L7 rules in the core API. And because the network model is a contract implemented by plugins, behavior at the edges (policy support, externalTrafficPolicy behavior, IPv6/dual-stack) varies by implementation — the model is portable, the details are not always.