Hands-on Lab·Certified Kubernetes Application Developer
Service Types End to End
The three Service types on one workload, each proved from the place it is supposed to be reachable from - and an honest look at what a LoadBalancer does on a cluster that has a controller for it and on one that does not.
Services and Networking Guide 35 of 44 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 16 min
This cluster runs MetalLB, so EXTERNAL-IP is really allocated. Without a load-balancer controller that column stays Pending, which the last two steps cover.
| 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 exposed and proved from the right place. This matters because the three Service types are cumulative - each keeps what the previous one had - so the test for each is a different test.
- exposing a Deployment and getting the ClusterIP that every task starts from
- proving it three ways from inside the cluster - by name, by cluster IP, and from another Pod
- patching the same Service up to NodePort rather than creating a new object
- patching it again to LoadBalancer and getting a genuinely allocated address
- confirming exactly what each type kept from the one before it
Before you start
- guide 65 - the two port numbers, before this changes what surrounds them.
-
A workload, and the Service every task starts with
-
Prove it from inside the cluster
-
The same Service, as a NodePort
-
And as a LoadBalancer
-
What each type kept