Kubernetes Services explained: ClusterIP vs NodePort vs LoadBalancer on a real cluster

Learn why pods need a Kubernetes Service in front of them and when to use ClusterIP, NodePort or LoadBalancer. You deploy a small app, expose it with each Service type in turn and send real traffic through it. Pod IPs change every time a pod is replaced, so clients cannot rely on them. We write a Deployment running three whoami pods and a Service that finds them by label, then look at the difference between port and targetPort. With kubectl we check the Service, its EndpointSlices and what happens to them when a pod is deleted. From a busybox pod inside the cluster we call the Service by name and watch requests spread across all three pods. Then we switch the same Service to NodePort and reach it from a browser, and finally to LoadBalancer on K3s, where the built-in load balancer hands out an external IP. Along the way you see how each type builds on the one before it. 0:00 Why pod IPs change and what a Service fixes 1:12 ClusterIP, NodePort and LoadBalancer at a glance 2:21 Deployment with the whoami app 3:09 Service manifest: selector, port and targetPort 4:56 Applying it and reading EndpointSlices 6:04 Replacing a pod: endpoints update, ClusterIP stays 6:57 Calling the Service by name from a busybox pod 8:25 Switching to NodePort 30080 10:43 LoadBalancer on K3s and the external IP 13:21 Cleanup and recap: which type to choose Practice this hands-on in a real Kubernetes environment on prepare.sh: https://prepare.sh