Kubernetes Networking

Kubernetes Networking is the set of principles and mechanisms that allow every Pod in a cluster to communicate with every other Pod, and with the outside world, according to a consistent, predictable model, regardless of which nodes those Pods happen to be running on. Rather than defining a single built-in implementation, Kubernetes specifies a small number of networking requirements and delegates the actual implementation to pluggable network providers, allowing the same workload manifests to function correctly across very different underlying infrastructures.

The Kubernetes Networking Model

Fundamental Requirements

Kubernetes networking is built on a small set of requirements that any conforming implementation must satisfy: every Pod receives its own unique IP address; Pods can communicate with all other Pods on any node without network address translation; agents on a node, such as the kubelet, can communicate with all Pods on that node; and Pods that use the host network see the same view of the world as other processes on that host.

Flat Network, No Required NAT

This "flat network" model is a deliberate simplification: application code inside a Pod addresses another Pod by its actual IP address and expects the connection to succeed directly, without needing to be aware of port mapping or translation layers that are common in traditional container networking setups.

Container Network Interface (CNI)

Role of CNI Plugins

The Container Network Interface (CNI) is the standard through which Kubernetes delegates actual network setup to a pluggable provider. When a Pod is created, the kubelet invokes the configured CNI plugin to allocate an IP address, create the Pod's network namespace, and attach it to the cluster's network fabric.

Common Implementations

CNI implementations vary in how they achieve pod-to-pod connectivity: overlay-based plugins encapsulate Pod traffic inside a virtual network layered over the physical network, requiring no changes to underlying infrastructure; routed plugins program actual routes into the underlying network fabric using each Pod's real IP address; and cloud-native plugins integrate directly with a provider's native VPC networking, assigning Pods addresses from the same address space as the surrounding infrastructure.

# Example CNI plugin configuration reference within a manifest
apiVersion: v1
kind: Pod
metadata:
  name: codartium-net-test
  annotations:
    cni.projectcalico.org/ipv4pools: '["default-ipv4-ippool"]'
spec:
  containers:
    - name: net-test
      image: busybox:1.36
      command: ["sleep", "3600"]

Pod-to-Pod and Pod-to-Service Communication

Direct Pod Communication

Because every Pod has a routable IP address, direct Pod-to-Pod communication requires no special configuration once the CNI plugin is functioning; a process in one Pod can open a connection to another Pod's IP and configured port exactly as it would to any other network endpoint.

Service Virtual IPs

Communication with a Service, rather than a specific Pod, is mediated by kube-proxy, which programs each node with packet-forwarding rules that intercept traffic destined for a Service's virtual IP and redirect it to one of the matching backend Pods, typically using iptables or IPVS depending on cluster configuration.

# Inspecting service-related iptables rules on a node (illustrative)
iptables -t nat -L KUBE-SERVICES -n

kube-proxy Modes

iptables Mode

In iptables mode, kube-proxy translates Service definitions into chains of iptables rules that perform destination NAT, selecting among backend Pods using probabilistic rule matching, a simple and widely compatible approach whose performance degrades as the number of Services grows very large.

IPVS Mode

IPVS mode uses the Linux kernel's IP Virtual Server subsystem, offering more efficient load balancing algorithms and better performance at scale compared to iptables, at the cost of requiring IPVS kernel modules to be available on every node.

External Traffic and Ingress

Exposing Services Externally

NodePort and LoadBalancer Service types extend the internal networking model to accept traffic originating outside the cluster, either by opening a static port on every node or by provisioning an external, provider-managed load balancer that forwards to the Service.

Layer 7 Routing with Ingress

For HTTP and HTTPS traffic requiring host- or path-based routing, TLS termination, or other layer 7 behavior, an Ingress resource, backed by an Ingress controller, sits in front of one or more Services, providing more sophisticated routing than Service objects alone express.

Network Policy

Default Openness

By default, the flat networking model permits any Pod to communicate with any other Pod across the entire cluster, with no implicit isolation between namespaces or applications.

Restricting Traffic

A NetworkPolicy object, enforced by a CNI plugin that supports it, restricts this default openness by defining allowed ingress and egress rules for a selected set of Pods, expressed in terms of Pod and namespace selectors, IP blocks, and ports.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-db-access
  namespace: codartium-team
spec:
  podSelector:
    matchLabels:
      app: codartium-db
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: codartium-api
      ports:
        - protocol: TCP
          port: 5432

DNS as a Networking Layer

Cluster DNS, typically provided by CoreDNS, sits atop the networking model as the primary mechanism by which workloads discover the addresses they need to communicate with, translating stable Service and Pod names into the IP addresses that the underlying network layer actually routes traffic to.