TL;DR: First things first: please remember that Kubernetes is a collection of software running on Linux. Basically, everything that happens in Kubernetes is built on top of Linux kernel primitives and TCP/IP networking foundations.

We will describe Kubernetes networking from the smallest to the largest units:

  1. Containers
  2. Pods
  3. Nodes
  4. Clusters

Basic IP Concepts

Do you remember that localhost is the machine’s loopback hostname, associated with the IP address 127.0.0.1?

There are also specific IP ranges designated as Private IP addresses:

  • 10.0.0.0 – 10.255.255.255
  • 172.16.0.0 – 172.31.255.255
  • 192.168.0.0 – 192.168.255.255

The system that maps domain names to IP addresses through name servers is called DNS (Domain Name System).

In standard networks, the service that automatically assigns IP addresses to devices is called DHCP (Dynamic Host Configuration Protocol). (Note: Inside Kubernetes, IP management for Pods is handled directly by CNI plugins rather than traditional DHCP).

Containers in Pods

A Pod has a single network identity and is assigned its own Pod IP address. A Pod contains at least one application container.

Kubernetes uses a special infrastructure container, commonly called the pause container, to establish and hold the Pod’s shared namespaces—specifically its network namespace.

Because all containers within the same Pod share this network namespace, they can communicate with one another using localhost and their respective port numbers.

Pod
┌──────────────────────────────┐
│ Network namespace            │
│                              │
│  Container A :8080           │
│  Container B :9090           │
│                              │
│  localhost                   │
│      │                       │
│      └── shared by containers│
│                              │
│  Pod IP: 10.x.x.x            │
└──────────────────────────────┘

Pods in Nodes

A Node can run multiple Pods.

Pods on the same Node can communicate with each other using their Pod IP addresses. Pods can also communicate with Pods on other Nodes through the flat Kubernetes cluster network.

The actual implementation of this network layer is provided by the cluster’s CNI (Container Network Interface) plugin.

At this level:

  • Nodes running application workloads are called Worker Nodes.
  • Nodes running Kubernetes management components are called Control Plane Nodes.

Nodes in Clusters

A Cluster brings together the Control Plane and Worker Nodes into a single cohesive Kubernetes environment.

For high availability, production clusters commonly run at least three Control Plane Nodes. Three is a common baseline because it allows the cluster to tolerate the loss of one Control Plane node while maintaining quorum for etcd.

While stateless control plane components (like kube-apiserver) run actively across all Control Plane Nodes, other components use leader election so that only one instance actively makes decisions at a time.

Note on Scale: Kubernetes has an official scalability limit of up to 5,000 nodes per cluster. However, this does not mean every cluster should aim for this size. In practice, cluster size depends on workload requirements, networking overhead, and failure-domain design. Most architectures favor running multiple smaller clusters for better fault isolation.

Clusters & External Networking

Up to this point, communication has been internal:

  • Containers talk to other containers in the same Pod via localhost.
  • Pods talk to other Pods via Pod IP addresses.
  • Nodes host these running Pods.

Eventually, traffic needs a way to enter and leave the cluster. Kubernetes provides several resources to expose applications externally:

  1. Service (ClusterIP): Provides a stable virtual IP and internal DNS name for a group of Pods.
  2. NodePort: Exposes a Service on a static port on each Node’s IP address.
  3. LoadBalancer: Requests an external cloud load balancer to route traffic directly into the cluster.
  4. Ingress: Manages HTTP/HTTPS routing rules based on hostnames or URL paths.
  5. Gateway API: An evolution of Ingress providing a more expressive and extensible traffic-routing framework.
Internet
    │
    ▼
Load Balancer / Ingress / Gateway API
    │
    ▼
Service
    │
    ├── Pod
    ├── Pod
    └── Pod

DNS & Services

Pod IPs are ephemeral—when Pods are deleted or recreated, their IP addresses change.

To prevent applications from breaking when Pod IPs change, Kubernetes relies on Services and internal DNS (typically CoreDNS):

  1. A Service provides a permanent entry point and stable IP address.
  2. CoreDNS maps human-readable service names (e.g., my-app-service) to that stable Service IP.
Application
    │
    │ DNS query
    ▼
my-app-service
    │
    ▼
Service IP
    │
    ├── Pod 10.x.x.10
    ├── Pod 10.x.x.11
    └── Pod 10.x.x.12

Even as backend Pods are created or destroyed, the application continues communicating with the unchanging Service name. This is a core rule of Kubernetes networking: Applications should communicate through Services rather than targeting individual Pod IPs directly.

Back to Certified Cloud Native Platform Engineering Associate Preparation