KCNA — Container Networking
Container Networking
Container networking connects containers to each other and to the outside world. In Kubernetes, networking is handled by CNI plugins and follows the flat network model.
The Kubernetes Network Model Revisited
| Requirement | What It Means |
|---|---|
| Every pod gets its own IP | No NAT between pods |
| All pods can communicate with all other pods | Across any node |
| All nodes can communicate with all pods | And vice versa |
This creates a flat, routable network where any pod can reach any other pod by IP address.
Network Types in Kubernetes
Overlay Networks
An overlay network creates a virtual network on top of the physical network:
Physical Network: 192.168.1.0/24 (Node IPs)
│
Overlay Network: 10.244.0.0/16 (Pod IPs)
│
Node 1 → Pods: 10.244.1.x
Node 2 → Pods: 10.244.2.x
Node 3 → Pods: 10.244.3.x
| Aspect | Details |
|---|---|
| How it works | Encapsulates pod traffic in node-to-node packets (VXLAN, etc.) |
| Pros | Simple to set up; works across any infrastructure |
| Cons | Slight performance overhead from encapsulation |
| Used by | Flannel, Calico (VXLAN mode), Weave Net |
Direct Routing (BGP)
Instead of encapsulating, some CNI plugins use BGP routing to advertise pod IPs:
| Aspect | Details |
|---|---|
| How it works | Advertises pod network routes to the physical network |
| Pros | Better performance — no encapsulation overhead |
| Cons | Requires network infrastructure support |
| Used by | Calico (BGP mode), Cilium (native routing) |
eBPF-Based Networking
Modern approach using extended Berkeley Packet Filter:
| Aspect | Details |
|---|---|
| How it works | Runs networking logic directly in the Linux kernel |
| Pros | High performance; avoids iptables overhead; built-in observability |
| Used by | Cilium (the leading eBPF networking solution, CNCF Graduated) |
CNI Plugins Deep Dive
| Plugin | Approach | Key Feature | Best For |
|---|---|---|---|
| Calico | BGP or VXLAN | Network policy enforcement | Most production clusters |
| Cilium | eBPF | Performance, security, observability | Advanced networking needs |
| Flannel | VXLAN overlay | Simplicity | Simple clusters, learning |
| Weave Net | Overlay with encryption | Built-in encryption | Secure overlay networks |
Exam tip: Know that CNI plugins implement the Kubernetes network model. The exam may ask about what role CNI plays, not how to configure specific plugins.
Network Policies
Network Policies define rules for pod-to-pod traffic:
| Default Behavior | With Network Policy |
|---|---|
| All pods can talk to all pods | Only allowed traffic passes |
Policy Types
| Type | Controls |
|---|---|
| Ingress | Incoming traffic to a pod |
| Egress | Outgoing traffic from a pod |
Example Concept
"Allow traffic TO backend pods ONLY FROM frontend pods"
Ingress rule on backend pods:
- Allow from pods with label: app=frontend
- Deny all other traffic
Important: Network Policies require a CNI plugin that supports them. Flannel does NOT support Network Policies; Calico and Cilium do.
Key Takeaways for the Exam
- Kubernetes uses a flat network model — all pods can communicate with all other pods by default
- CNI plugins implement the networking model (Calico, Cilium, Flannel)
- Overlay networks (VXLAN) encapsulate traffic; BGP routing advertises pod routes directly
- eBPF (used by Cilium) provides high-performance, kernel-level networking
- Network Policies restrict pod-to-pod traffic (ingress and egress)
- Not all CNI plugins support Network Policies — Calico and Cilium do, Flannel does not
- Cilium is the CNCF Graduated eBPF-based CNI plugin
What’s Next?
Let’s explore service mesh — how microservices communicate reliably at scale.
