Understanding Kubernetes: Networking basics

Understanding Kubernetes: Networking basics

In the last article we looked at how Kubernetes builds workloads using controllers: Deployments create ReplicaSets, ReplicaSets manage Pods, and everything is driven by reconciliation.

Now we move one layer lower in the stack: networking. Let’s get started.

The core networking assumption

Kubernetes networking is built on a surprisingly strict assumption: Every Pod gets its own IP address and can communicate directly with every other Pod in the cluster. No NAT between Pods. No port forwarding. No node-level address translation. Just flat, routable connectivity between workloads.

This sounds simple, but it is actually one of the key design decisions behind Kubernetes. Applications do not need to care where a Pod is running. As long as the Pod exists, it should be reachable.

Pods and network namespaces

Under the hood, each Pod gets its own Linux network namespace, containing:

  • its own network interfaces
  • its own IP address
  • its own routing table
  • its own loopback interface

All containers inside a Pod share this namespace, which is why they can talk to each other via localhost.

So the model is:

  • inside a Pod → localhost
  • between Pods → cluster network

There is one important exception, though: If hostNetwork: true is set, the Pod does not get its own network namespace and instead shares the node’s network stack. This is rarely used for application workloads, but common in system components.

Kubernetes does not implement networking

One of the most important architectural points: Kubernetes defines the networking model, but does not implement it. The actual networking is handled by a CNI plugin (Container Network Interface).

The CNI is responsible for:

  • assigning Pod IPs
  • attaching network interfaces to Pods
  • configuring routes between nodes
  • ensuring Pod-to-Pod connectivity works

Popular implementations include Calico, Flannel, and Cilium. While all of them provide the networking behavior Kubernetes expects, they implement it differently. Some use overlay networks (VXLAN, IP-in-IP), others use native routing (BGP or cloud routes), and modern systems like Cilium move large parts of this into the Linux kernel itself.

Networking layers in Kubernetes

In practice, Kubernetes networking is usually discussed in three layers:

Pod networking

  • Every Pod gets an IP address
  • CNIs provide connectivity between Pods
  • Workloads communicate directly

Service networking

  • Services provide stable addresses for groups of Pods
  • DNS enables service discovery
  • Traffic is load-balanced across matching Pods

External access

  • NodePorts expose Services on cluster nodes
  • LoadBalancers integrate with external load balancers
  • Ingress and Gateway API provide HTTP routing and traffic management

Summing up

Kubernetes networking may look complicated at first, but the core model is surprisingly simple: Pods receive their own IP addresses and are expected to communicate directly across the cluster. Kubernetes itself defines this model, while CNI plugins provide the actual implementation. Everything else in Kubernetes networking builds on top of these foundations.

In the next article we’ll look at Services, DNS and Service Discovery: how stable addresses are created on top of ephemeral Pods, how Kubernetes resolves service names, and what actually happens when an application connects to http://backend.

header image created by buddy ChatGPT