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
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 35 min
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 |
This guide includes
Use this when a workload has to be reachable and you are choosing how far out to expose it. This matters because the three Service types stack rather than compete - each is the previous one plus something extra - and only the last needs help from outside the cluster.
- creating a ClusterIP and finding an address that nothing actually owns
- adding NodePort, which is a ClusterIP plus the same port opened on every node
- creating a LoadBalancer and seeing exactly why it stays Pending with no cloud provider
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