Hands-on Lab·Certified Kubernetes Administrator
The Kubernetes Network Model
Three separate address ranges are in play and confusing them causes most Kubernetes networking problems. Prove pods talk across nodes without NAT by reading the receiving container's own access log, then find out why the pod IPs are not in the range the node was allocated.
Services and Networking Guide 46 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 30 min
The CIDRs are this lab's choices. The rule that pod-to-pod traffic is not translated is part of the model.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a networking problem stops making sense and you suspect two address ranges are being confused. This matters because three separate ranges are always in play - node, Pod and Service - and mixing them up causes most Kubernetes network confusion.
- reading the Pod and Service CIDRs off the control plane components' own flags
- pinning two Pods to two named nodes with
nodeSelectoron the hostname label - proving the no-NAT rule from the receiving end rather than the sending end
Before you start
- A multi-node cluster with a CNI installed. The installation guides cover both.
- The control plane guide, for where
--cluster-cidrand--service-cluster-ip-rangecome from. - The labels and nodeSelector guide, since the two Pods below are pinned to specific nodes.
-
Three ranges, and keeping them straight
-
Two pods, two nodes, two real addresses
-
The no-NAT rule, proven from the receiving end