Last week, I was working with a client today to deploy several of his kubernetes clusters in the Cloud using AWS EKS. During the course of my work, a conversation ensued between the both of us on kuberntes networking and service types. It then dawned on me how difficult it can be to differentiate between the three main service types that kubernetes offers - ClusterIp, NodePort and LoadBalancer.
To understand these service types, it is necessary to first understand what a service is in kubernetes .
A service resource is simply a way to logically match pods with policies to access them. Remember that pods are ephemeral resources and no pod is ever recreated once it is deleted. Services therefore provide a way to provide connection to these pods regardless of their IP addresses.
This is achieved through the use of selectors. Usually, in the manifest for a deployment, labels are provided in the pod template which serves as a way to identify and group the pod according to our needs. selectors are then defined in the service resource manifest which match the labels defined in the deployment or pod manifest. For each pod that matches the selector, an endpoint object is created for that pod.
Okay, let's get back to service types. These are the main differences between them.
ClusterIP: This is the default. What it does is that it exposes the service on a cluster-internal IP. This essentially means that we are only able to access our service from within the cluster. This is mostly suitable for developing, debugging and testing purposes. When you use the kubectl get services command while using this service type, the address you get is the IP address assigned to this service from within your cluster.
NodePort: What a NodePort service type does is that it uses a static IP to expose the service on each node's IP. Thus, providing external access to the service. What happens is that when traffic arrives on the open port, it will be redirected to the specific port on the ClusterIP for that service. Suffice it to say, NodePort service type builds upon the ClusterIP type.
This is useful when we have an external load balancer that we wish to connect to the service. It is however not very great for production environments. The reason for this is because for a port, you can only have one service running on it. The second is that we would need to track which nodes have which exposed ports - this can be a great hassle.
LoadBalancer: This is the most preferred way of exposing our services within production environments, especially when dealing with Cloud services. Here we are using the external load balancer and IP address provided by our cloud service (e.g AWS EKS, Azure AKS, GKE etc ). This gives us the liberty of using multiple protocols and multiple ports per service.
When a LoadBalancer ServiceType is created, NodePort and ClusterIp are also created. The service can then be accessed through the IP address provided by the Cloud Service load balancer, which will route the request to a NodePort and from there forwarded to a ClusterIp. So, LoadBalancer builds upon NodePort and ClusterIp. the major downside to using this service type is that it can get costly real quick.
Okay friends, that is it for today. I'd be glad to take comments or discussions about this topic or any other Kubernetes topic.
Top comments (0)