KCNA — Cluster Networking Overview

4 minute read

Cluster Networking Overview

Networking is one of the most important concepts in Kubernetes. Every pod needs to communicate with other pods, services, and external clients. Kubernetes has a specific networking model that makes this work.

The Kubernetes Networking Model

Kubernetes requires that any networking implementation satisfies these rules:

Rule What It Means
Every pod gets its own IP address No need for NAT between pods
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 kubelet, kube-proxy can reach pods

This is known as the flat network model — all pods exist in one flat network space.

Four Types of Kubernetes Networking

1. Container-to-Container (within a Pod)

Containers in the same pod share the same network namespace:

┌──────── Pod ────────┐
│  Container A (:8080) │
│  Container B (:9090) │
│                      │
│  Shared IP: 10.1.1.5 │
│  localhost works!    │
└──────────────────────┘
  • Same IP address for all containers in the pod
  • Communicate via localhost
  • Different port numbers (ports can’t conflict within a pod)

2. Pod-to-Pod (same node)

Pods on the same node communicate through a virtual bridge:

┌──── Node 1 ─────┐
│                  │
│  Pod A           │
│  10.1.1.5 ──┐   │
│              ├──► Virtual Bridge (cbr0)
│  Pod B       │   │
│  10.1.1.6 ──┘   │
│                  │
└──────────────────┘

3. Pod-to-Pod (different nodes)

Pods on different nodes communicate via the overlay network set up by the CNI plugin:

┌──── Node 1 ──────┐        ┌──── Node 2 ──────┐
│  Pod A: 10.1.1.5  │◄──────►│  Pod C: 10.1.2.3  │
│                   │ Network │                   │
└───────────────────┘        └───────────────────┘

The CNI plugin ensures that pod IPs are routable across nodes — pods don’t need to know which node other pods are on.

4. Pod-to-Service

Services provide a stable endpoint for accessing pods:

Client → Service (ClusterIP: 10.96.0.1)
              │
              ├── Pod A (10.1.1.5)
              ├── Pod B (10.1.1.6)
              └── Pod C (10.1.2.3)

kube-proxy on each node maintains rules that route Service traffic to the correct pods.

CNI — Container Network Interface

The CNI (Container Network Interface) is a standard for configuring network interfaces in Linux containers. Kubernetes uses CNI plugins to implement its networking model.

Aspect Details
What it is A CNCF project that standardizes container networking
What it does Provides a plugin-based system to configure pod networking
Who implements it Third-party plugins (Calico, Cilium, Flannel, Weave Net)
Key point Kubernetes does NOT include a built-in network solution — you must install a CNI plugin
Plugin Key Feature CNCF Status
Calico Network policy enforcement, BGP routing Not a CNCF project
Cilium eBPF-based networking, security, observability CNCF Graduated
Flannel Simple overlay networking Not a CNCF project
Weave Net Encrypted overlay network Not a CNCF project

Exam tip: You don’t need to know how to install or configure CNI plugins. Know what CNI is, that it’s required, and be able to name a few popular plugins.

Kubernetes DNS (CoreDNS)

Every Kubernetes cluster runs a DNS service (CoreDNS) that provides name resolution:

DNS Name Pattern Resolves To
my-service.my-namespace.svc.cluster.local ClusterIP of the service
my-pod-ip.my-namespace.pod.cluster.local IP of a specific pod

How it works in practice:

Pod A wants to reach "my-service":
  1. Pod A sends DNS query for "my-service"
  2. CoreDNS resolves it to the Service's ClusterIP
  3. kube-proxy routes the request to one of the Service's backend pods
Component Role
CoreDNS Resolves service names to ClusterIP addresses
kube-proxy Routes traffic from ClusterIP to actual pods
CNI plugin Provides pod-to-pod network connectivity

Service Types and External Access

Service Type Access Level Use Case
ClusterIP Internal only Pod-to-pod communication within the cluster
NodePort External (via node IP:port) Development, simple external access
LoadBalancer External (via cloud LB) Production external access on cloud providers
ExternalName DNS alias Mapping to external services

More detail on Services is covered in Chapter 3 (Kubernetes Resources).

Network Policies

Network Policies control traffic flow between pods — think of them as firewalls for pods.

Aspect Details
Default behavior All pods can communicate with all other pods (no restrictions)
With Network Policy You can restrict which pods can talk to each other
Implemented by CNI plugin (not all plugins support Network Policies)
Types Ingress (incoming traffic), Egress (outgoing traffic)

Example: “Only allow pods with label app: frontend to communicate with pods labeled app: backend.”

Key Takeaways for the Exam

  • Kubernetes uses a flat network model — every pod gets its own IP, and all pods can reach all other pods
  • Containers in the same pod communicate via localhost
  • Pods on different nodes communicate via CNI plugins (Calico, Cilium, Flannel)
  • CNI is required — Kubernetes doesn’t include a built-in network solution
  • CoreDNS provides service discovery — pods find services by name
  • kube-proxy routes Service traffic to pods (using iptables or IPVS)
  • Network Policies act as pod-level firewalls — default is “allow all”
  • Cilium is a CNCF Graduated project for eBPF-based networking

What’s Next?

Let’s explore the Container Runtime Interface — how Kubernetes interacts with container runtimes.

Container Runtime Interface →

Updated:

You may also enjoy