Hands-on Lab·Certified Kubernetes Administrator
Services: ClusterIP, NodePort and LoadBalancer
Three Service types that stack on top of each other, one address that nothing owns and that ping cannot reach, and a LoadBalancer that stays Pending forever on bare metal. Each behaviour is shown rather than described.
Services and Networking Guide 47 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- CNICalico v3.32.1
- Runtimecontainerd 2.2.6
- TimeAbout 35 min
- Reviewed21 August 2026
Written against the versions above. The Pending LoadBalancer is the correct result on a cluster with no cloud controller, not a broken lab.
| 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 |
Before you start
- The network model guide, for the difference between the Pod CIDR and the Service CIDR.
- A running Pod to expose, and a shell Pod to test from. The network model guide creates both.
- The labels and selectors guide: a Service finds its Pods by label, and that is the only link between them.
-
ClusterIP, and an address that nothing owns
-
NodePort: the same Service, plus a port on every node
-
LoadBalancer, and why it never gets an address here