K8s ClusterIP, Nodeport & Load Balancer in one glance
Why am I writing this blog?
When I was trying to learn about K8s Service object types, I had to go thru multiple blogs/SO answers on the internet to get a clear understanding of what each service is and especially how are they related. Thought I can put all this info in a single picture that talks by itself on dependency & hierarchy of different SERVICE types in Kubernetes. Hence this blog. So, first, our favorite pic followed by a little theory about each of these.
Hope you enjoy reading it.
In Kubernetes, a SERVICE object provides an abstraction to expose k8s pods over a network and does traffic management. It simply defines different ways of allowing traffic into a k8s cluster pods.
Kubernetes assigns a IP address to each pod and a pod-to-pod communication can be established using IP address & port. However, pods are ephemeral and are their IP addresses. A replaced pod isn’t guaranteed to get same IP. This problem can be resolved with the default SERVICE type in K8s — the ClusterIP.
Cluster IP
Cluster IP service provides a cluster-internal IP that can be used by one set of pods to talk to other set of pods but with in a cluster. Say, frontend pods want to communicate with backend pods in the same cluster thru ClusterIP service.
We just define ClusterIP type in yaml with the set of pods(thru k8s labels) that ClusterIP service should send traffic to & port on which these targets pods are reachable and K8s creates a service providing this functionality.
In figure above, this route is shown in pink color. A pod of microservice 2 hits the clusterIP on port 80 which then forwards it to a pod on node 1 on port 8080.
However, this service IP address is hidden from outside world and can be accessed only from with-in cluster. So, how can a client that can ping the host nodes in the cluster but are outside the cluster send requests to pods in a cluster? Here comes NodePort service type.
NodePort
Upon creating a service of type:NodePort, K8s exposes the service on each hostnode on a specific port. This port value can either be defined by the user or K8s picks up random value but it should be between 30000–32767. A client application outside the cluster then can ping the node using <node_ip_address>:<nodeport_service_port> & what happens internally is simple - this node forwards the request to ClusterIP service on a different port & the ClusterIP service then takes its regular route as defined above. ClusterIP service is implicitly spawned as part of NodePort service.
This route is shown in green color. An external client hits node-1 on port 30036 which forwards the request to ClusterIP service on port 80 which in turn forwards it to a pod on node-3 on port 8080.
Note that for security reason, the host nodes should be on private subnets so this service is not accessible to anyone on the internet.
Along with the limitation on port numbers, it is left to the client to deal with node IP address changes & load balancing between different nodes. But not to worry, K8s also provides a 3rd SERVICE type called LoadBalancer to take away these hurdles from client & also to handle the usecase of exposing this service to outside world on internet
LoadBalancer
LoadBalancer service is applied on top of the NodePort service. An L4 LB VM is created(a clusterIP service and a NodePort Service will be implicitly spawned as well) which gets a public IP address and it will load balance and forward traffic to the nodes in the cluster on their private IP addresses and NodePort port.
This route is shown in brown. A client hitting the public DNS of LB on default port 443 that picked node-3. The port is 31147 this time. It then hits node-3 which forwards the request to ClusterIP service on port 80 which in turn forwards it to a pod on node-2 on port 8080.
This automatically takes care of the routing & helps distribute traffic and prevents any single point of failure.
Finally, if you like it, please encourage with a clap.