How Kubernetes Networking Works

Kubernetes networking is more complex than traditional server networking because containers and pods are ephemeral: they get new IP addresses when they are created and destroyed. Kubernetes provides a networking model that handles this dynamism while enabling reliable communication.

The Kubernetes Networking Model

Kubernetes requires that: - Every pod gets its own IP address - Pods on any node can communicate with pods on any other node without NAT - Agents on a node can communicate with all pods on that node

This flat network model simplifies application networking: your application does not need to worry about which node it is running on.

Pod-to-Pod Communication

Each pod gets an IP address from the cluster's pod network (CIDR range). Pods on the same node communicate through a virtual bridge. Pods on different nodes communicate through the node network, with routing handled by the CNI (Container Network Interface) plugin.

Common CNI plugins: - Calico: supports network policies and BGP routing - Cilium: eBPF-based networking with advanced security features - Flannel: simple overlay network - Weave: mesh networking with encryption support

Services

A Kubernetes Service provides a stable IP and DNS name that load-balances traffic to a set of pods. The Service uses label selectors to identify which pods to route to.

Service types: - ClusterIP: internal-only IP, accessible within the cluster - NodePort: exposes the service on a port on every node - LoadBalancer: provisions an external load balancer - ExternalName: maps a Service name to an external DNS name

DNS

Kubernetes runs a cluster DNS service (usually CoreDNS) that provides DNS-based service discovery. Every Service gets a DNS entry:

service-name.namespace.svc.cluster.local

Pods in the same namespace can use just service-name. Pods in different namespaces must use service-name.namespace.

Ingress

An Ingress manages external HTTP and HTTPS access to Services. It provides: - URL-based routing (path routing) - Host-based routing - TLS termination - Load balancing

An Ingress Controller (like Nginx Ingress or Traefik) implements the Ingress rules.

Network Policies

Network Policies control traffic flow between pods. By default, all pods can communicate with all other pods. Network Policies allow you to restrict this: - Allow traffic only from specific pods or namespaces - Allow traffic only on specific ports - Deny all ingress by default and whitelist allowed connections

Network Policies are enforced by the CNI plugin. Not all CNI plugins support Network Policies (Calico and Ccilium do; Flannel does not).

Practical Considerations

• Always use DNS names (Service names) rather than IP addresses for service-to-service communication
• Implement Network Policies for production workloads to limit the blast radius of a compromise
• Use Ingress for HTTP traffic rather than exposing each service with a LoadBalancer
• Monitor network traffic between services for debugging and security analysis

Understanding Kubernetes networking helps you design secure, reliable applications that take full advantage of the platform's capabilities.

Key Takeaways

• Every pod gets its own IP address, and pods across nodes communicate without NAT — this flat network model is foundational to Kubernetes networking
• Services provide stable IPs and DNS names for pod sets, with ClusterIP for internal traffic and LoadBalancer for external access
• Ingress controllers handle HTTP/HTTPS routing, TLS termination, and path-based traffic distribution to Services
• Network Policies restrict pod-to-pod traffic and should be enabled in production to limit the blast radius of a compromised pod
• Choose a CNI plugin (Calico, Cilium, Flannel) based on whether you need network policy enforcement, encryption, or eBPF-based features