19.6 Kubernetes Networking

Overview

Kubernetes networking is about how containers, pods, and services talk to each other and to the outside world, inside a Kubernetes cluster and beyond. It looks simple from an application point of view, but under the hood it combines familiar concepts such as IP routing, NAT, overlays, and load balancing into a specific model.

In this chapter, you focus on what makes Kubernetes networking special, how it differs from traditional host networking, and what you need to understand to run applications reliably in a cluster.

The Kubernetes Networking Model

Kubernetes defines a set of rules for networking that every conforming implementation must satisfy, regardless of the underlying hardware or cloud. These rules are about how pods see each other and how traffic is routed.

At a high level, each pod gets its own IP address, and these pod IPs are expected to be directly reachable within the cluster, without NAT between pods. This model allows containers inside pods to behave as if they are regular processes on a shared network, which simplifies application configuration.

These rules do not prescribe how to implement the network. Different Container Network Interface (CNI) plugins provide different implementations, using routing, overlays, or other mechanisms.

Pod Networking

From a networking perspective, the pod is the basic unit in Kubernetes. A pod can hold one or more containers, but all containers in the pod share one network stack.

Each pod has a single IP address. All containers in the pod see the same IP, the same network interfaces, and the same port space. If one container listens on port 80, other containers in the pod cannot also use port 80, because they share the same namespace.

This design replaces the need for explicit port mapping between containers on the same node. Instead, containers in different pods connect to each other by pod IP and port, just like processes on different servers.

Inside the cluster, pod networking implementations commonly use one of two main approaches. Some use routing, where each node knows the pod CIDR ranges of other nodes and sends traffic directly. Others use overlays, where pod traffic is encapsulated inside another protocol such as VXLAN or IP-in-IP, and moves across the physical network as encapsulated packets.

Regardless of the approach, the key result is that from the application point of view, a pod IP is just an IP that can be reached from any other pod.

Node to Pod Communication

A Kubernetes cluster consists of multiple nodes, each running pods. The node that hosts a pod must be able to send and receive traffic from that pod. The other nodes must also be able to reach that pod.

Typically, each node gets assigned a block of IP addresses for its pods. The CNI plugin then sets up routes or tunnel endpoints so that traffic between nodes and pods matches the Kubernetes model.

On the node itself, pods usually connect to a virtual bridge or virtual interface. The node’s routing table contains routes that point pod CIDR blocks toward appropriate interfaces. When a packet from outside the node is destined for a pod IP, the node routes it to the right virtual interface, then into the pod’s network namespace.

From the node’s perspective, a pod looks like a host with an IP that is attached to a virtual network device. From the pod’s perspective, the node is simply another IP next hop.

Cluster IP Services

Pod IPs are unstable. When pods are recreated, they receive new IPs. This is a problem for clients that want to connect to an application that might move between pods and nodes.

Kubernetes Services solve this with a stable virtual IP for a logical group of pods, defined by labels. The most common service type is ClusterIP. It acts as a virtual load balancer within the cluster and has an internal IP that does not change often.

Clients inside the cluster connect to the service IP and port. The Kubernetes networking implementation then forwards traffic from the service IP to one of the backend pod IPs. The mapping from service to pods is tracked by endpoints or endpoint slices.

Implementation details differ. On many clusters, iptables or eBPF programs on each node capture traffic destined for service IPs and rewrite or redirect it to pod IPs. The client sees a single IP, but the kernel and CNI plugin handle the fan‑out to multiple backends.

Service Discovery and DNS

To avoid hardcoding service IPs, Kubernetes includes built-in DNS-based service discovery. Each Service gets one or more DNS names, based on its name and namespace. Applications usually connect using these names instead of IPs.

For example, a Service named web in the namespace production might be reachable as web.production.svc.cluster.local, and often also by the shorter web form when the client runs in the same namespace.

Inside the pods, DNS configuration points to a cluster DNS server that understands the Kubernetes API and dynamically answers queries for Service and pod names. When an application resolves a Service name, the DNS server responds with the Service IP, which then gets load balanced to pods.

This tight integration of Services with DNS means that as pods scale up or down, or move to other nodes, clients can keep using the same name while the underlying endpoints change.

Service Types: ClusterIP, NodePort, and LoadBalancer

While ClusterIP is internal, many applications also need to be reachable from outside the cluster. Kubernetes supports several Service types for different exposure patterns.

ClusterIP, the default, exposes a Service inside the cluster only. It is enough when all consumers are other pods.

NodePort exposes a Service on a fixed port on every node. The Service remains a ClusterIP internally, but the node listens on a specified port, often in a high port range, and forwards incoming traffic on that port to the Service. External clients can reach the Service by targeting any node’s IP and the NodePort, for example node_ip:node_port.

LoadBalancer is usually available in cloud environments. It integrates with the cloud provider’s load balancer service to provision an external IP address. Traffic that arrives at this external IP is then forwarded to the Service, which in turn load balances traffic to pods. To the application, the Service still looks the same. The difference is that the Kubernetes control plane and the cloud provider collaborate to map an external IP to the Service.

Each type builds on the simpler ones. ClusterIP is the core concept. NodePort adds node-level exposure to a ClusterIP. LoadBalancer wraps NodePort and ClusterIP and gives the Service an external presence through a cloud or external load balancer.

Ingress and HTTP Routing

For web applications, mapping individual Services directly to external IPs is inefficient. Many HTTP or HTTPS applications should share a single entrypoint and route based on hostnames or paths.

Ingress provides a higher-level abstraction for this. An Ingress is a set of routing rules that map incoming HTTP or HTTPS requests to backend Services. Common match criteria include the requested host name and URL path.

An Ingress Controller is a component that watches these rules and configures an actual data plane, such as NGINX, Envoy, HAProxy, a cloud load balancer, or another proxy. The Ingress Controller receives external traffic, examines headers and paths, and forwards requests to the matching Service inside the cluster.

In practice, Ingress centralizes external access to many Services. It also becomes the point to handle TLS termination, HTTP redirects, and some security policies. The networking underneath still uses pod IPs and Services, but Ingress provides a friendly way to manage HTTP/S routes.

Network Policies and Pod Isolation

By default, in many Kubernetes setups, all pods can talk to all other pods. This is simple for initial development, but not acceptable in many environments where you need isolation between applications, namespaces, or tiers.

NetworkPolicies provide a way to express which traffic is allowed between pods and between pods and external endpoints. A NetworkPolicy selects groups of pods using labels and then defines which inbound and outbound connections are permitted, based on other labels, namespaces, and ports.

For example, you can define that a db pod only accepts connections from backend pods and blocks all other sources. Or you can allow only HTTP traffic into a particular frontend from the internet via a known ingress path.

NetworkPolicy is only a declarative API. The actual enforcement depends on the CNI plugin. Some plugins fully support it and apply rules at the node level using iptables, eBPF, or other mechanisms. Others ignore it. In a compliant environment, once you apply a NetworkPolicy that selects some pods, those pods switch to a default deny model for the specified traffic directions, unless you explicitly allow traffic.

This turns Kubernetes networking from a flat, fully open mesh into a controllable and segmented environment, more similar to traditional network security zones.

CNI Plugins and Implementations

The Container Network Interface, or CNI, is a standard way for Kubernetes to delegate pod networking to external plugins. When a pod starts, the kubelet on the node calls the installed CNI plugin. The plugin allocates an IP, configures virtual interfaces, and sets up the necessary routing, overlay tunnels, or policy enforcement.

Different CNI plugins take different approaches. Some aim for simple routed topologies within a flat L3 network. Others use overlay networks to avoid depending heavily on the underlying infrastructure. Some are optimized for large scale or minimal overhead, or for rich NetworkPolicy features.

While the details vary, all compliant implementations satisfy the Kubernetes networking rules for pod connectivity. As a user, you mostly see the resulting pod IPs, service IPs, and policies, not the exact details of encapsulation or routing. However, when troubleshooting performance or connectivity, understanding which style your CNI plugin uses can be crucial.

Service Mesh and Advanced Traffic Control

On top of basic Kubernetes networking, many environments add a service mesh. A service mesh introduces sidecar proxies next to each pod, and controls traffic centrally for features such as mutual TLS, retries, timeouts, detailed metrics, and advanced routing like canary releases.

In a typical service mesh, the network path between two pods becomes: application to local sidecar proxy, across the network to another pod’s sidecar proxy, then into the destination application. The mesh control plane programs routing rules into these proxies. Underneath, Kubernetes networking still handles pod IP routing and Services, but the mesh overlays additional logic for managing traffic.

This approach separates transport concerns from application code. It is not required for Kubernetes networking itself, but it is a common extension once clusters grow more complex.

Multi-Cluster and External Connectivity

As organizations expand, they often run multiple Kubernetes clusters in different data centers or clouds. Kubernetes networking by itself operates within a single cluster scope. Connecting clusters together or integrating with external networks introduces additional patterns.

Some solutions extend pod networking across clusters, so that pod IPs in different clusters are reachable as if they were in one large cluster. Others keep each cluster isolated and expose Services between clusters using gateways and load balancers. In both cases, you must pay attention to IP ranges, overlap, and how DNS and Service discovery work across boundaries.

For external systems, Kubernetes typically exposes Services using LoadBalancer, Ingress, or dedicated gateways. From the external network’s point of view, these components look like any other IP or HTTP load balancer, while internally they fan traffic into pods.

Putting It All Together

Kubernetes networking combines several layers of abstraction. Pods have their own IPs. Services provide stable virtual IPs and names, with built-in load balancing. DNS exposes Services through predictable hostnames. Ingress and similar components connect HTTP traffic from the outside world into these Services. NetworkPolicies control which pods can talk to which, which transforms a default open mesh into a more secure topology.

All of this relies on CNI plugins that implement the pod network and, optionally, policy enforcement. On larger or more advanced setups, a service mesh and multi-cluster networking add further capabilities above the core model.

For absolute beginners, the key is to see Kubernetes networking as a logical network that sits above your physical or cloud network, with clear rules about pod IP reachability, stable Service endpoints, and DNS-driven discovery. Once you recognize these building blocks, it becomes easier to design, secure, and troubleshoot applications that run on Kubernetes.