ClusterIP, NodePort, LoadBalancer and the Rest
Kubernetes has four Service types plus a headless variant, so how do they relate? Three of them stack: ClusterIP is the internal base with a virtual IP, NodePort builds on it by opening the same port on every Node, and LoadBalancer usually builds on NodePort with a balancer from a cloud or an add-on. ExternalName and headless Services get no virtual IP and no Service rules: DNS answers with a CNAME or the Pod IPs, and the client connects by itself.
Play the animation 5 steps, animated, best on a wide screen
ClusterIP, NodePort, LoadBalancer and the Rest, step by step
-
ClusterIP is the base layer. The Service gets a virtual IP that works only inside the cluster, and the Service rules on every Node send traffic for it to a backend Pod. Every other proxy type is built on top of this one.
Play from step 1 -
NodePort adds a layer on top. The Service keeps its ClusterIP and also opens port 31000 on every Node, so a client outside the cluster can reach any Node on that port. The Node port feeds the same Service rules, which pick a backend Pod.
Play from step 2 -
LoadBalancer adds one more layer. A cloud balancer gets the public address 203.0.113.7 and typically forwards to Node port 31000, into the same Service rules. Only a balancer that sends straight to Pods should turn that Node port off.
Play from step 3 -
ExternalName skips the whole stack. It uses no selector and gets no ClusterIP and no proxy. The client looks up the Service name, CoreDNS answers with a CNAME to api.example.com, and the client then connects to that external host by itself.
Play from step 4 -
Headless also skips the stack. With clusterIP set to None there is no virtual IP and no Service rules for it. CoreDNS answers with the Pod IPs themselves, and the client connects straight to one of the same backend Pods.
Play from step 5