In Kubernetes, there are three commonly used Service types: ClusterIP, NodePort, and LoadBalancer. These Services provide different ways to make Pods accessible to other Pods within the cluster, as well as to clients outside of it.

In this blog post, first, we’re going to talk about Kubernetes Services — what they are and what problems they solve. Next, we’ll get into the details of three Service types: ClusterIP, NodePort, and LoadBalancer. And lastly, we’ll point out the main differences among them and discuss when to use which type.

Let’s get started!

What Is a Kubernetes Service?

Kubernetes assigns Pods private IP addresses as soon as they are created in the cluster. However, there is a catch: These IP addresses are not permanent. If you delete or recreate a Pod, it gets a new IP address, different from the one it had before. This is problematic for a client that needs to connect to a Pod. If the IP address keeps changing, which one would the client keep track of and connect to?

Imagine if you had a friend who kept changing their phone number every day. You wouldn't be able to call them or text them because you wouldn't know which number to use.

Try the Kubernetes Services Lab for free

This is where Kubernetes Services come in. A Service helps a client reach one (or more) of the Pods that can fulfill its request. The Service can be reached at the same place, at any point in time. So it serves as a stable destination that the client can use to get access to what it needs. The client doesn’t have to worry about the Pods’ dynamic IP addresses anymore.

Now that we understand the basic purpose of a Kubernetes Service, let's take a closer look at how different types of Services work and what they're used for.

Try the Kubernetes Services Lab for free

ClusterIP

In Kubernetes, the ClusterIP Service is used for Pod-to-Pod communication within the same cluster. This means that a client running outside of the cluster, such as a user accessing an application over the internet, cannot directly access a ClusterIP Service.

When a ClusterIP Service is created, it is assigned a static IP address. This address remains the same for the lifetime of the Service. When a client sends a request to the IP address, the request is automatically routed to one of the Pods behind the Service. If multiple Pods are associated, the ClusterIP Service uses load balancing to distribute traffic equally among them.

In the image above, the green bar titled "back-end" represents a ClusterIP Service. It sits in front of all the Pods labeled "back-end" and redirects incoming traffic to one of them.

Now you know what a Kubernetes ClusterIP Service is and how it works. Next, let's dive into NodePort Service.

NodePort

The NodePort Service is a way to expose your application to external clients. An external client is anyone who is trying to access your application from outside of the Kubernetes cluster.

The NodePort Service does this by opening the port you choose (in the range of 30000 to 32767) on all worker nodes in the cluster. This port is what external clients will use to connect to your app. So, if the nodePort is set to 30020, for example, anyone who wants to use your app can just connect to any worker node’s IP address, on port :30020, and voila! They're in.

Note that a NodePort Service builds on top of the ClusterIP Service type. What this means is that when you create a NodePort Service, Kubernetes automatically creates a ClusterIP Service for it as well. The node receives the request, the NodePort Service picks it up, it sends it to the ClusterIP Service, and this, in turn, sends it to one of the Pods behind it (External Client->Node->NodePort->ClusterIP->Pod). And the extra benefits are that internal clients can still access those Pods, and quicker. They can just skip going through the NodePort and reach the ClusterIP directly to connect to one of the Pods.

One disadvantage of the NodePort Service is that it doesn't do any kind of load balancing across multiple nodes. It simply directs traffic to whichever node the client connected to. This can create a problem: Some nodes can get overwhelmed with requests while others sit idle.

Now that you have a good understanding of the NodePort Service, it’s time to examine the LoadBalancer Service.

LoadBalancer

A LoadBalancer Service is another way you can expose your applications to external clients. However, it only works if you're using Kubernetes on a cloud platform that supports this Service type.

Now, when you create a LoadBalancer Service, Kubernetes detects which cloud computing platform your cluster is running on and creates a load balancer in the infrastructure of the cloud provider. The load balancer will have its own unique, publicly accessible IP address that clients can use to connect to your application.

For example, if you're running a Kubernetes cluster on a cloud platform like Amazon Web Services (AWS), you can create a LoadBalancer Service. When you do this, Kubernetes will create an Elastic Load Balancer in AWS to route traffic to the nodes in your cluster.

Note that the LoadBalancer Service this time builds on top of the NodePort Service, with an added benefit: It adds load balancing functionality to distribute traffic between nodes. This reduces the negative effects of any one node failing or becoming overloaded with requests.

The traffic coming from external clients goes through a path like this: External client -> Loadbalancer -> Worker node IP -> NodePort -> ClusterIP Service -> Pod.

ClusterIP vs NodePort vs LoadBalancer: Key Differences & Use Cases

Now, let’s discuss the key difference among ClusterIP, NodePort, and LoadBalancer Service types and when to use which type.

Key difference

ClusterIP is used for Pod-to-Pod communication within the same Kubernetes cluster. In contrast, NodePort and LoadBalancer Services are used for communication between applications within the cluster and external clients outside the cluster.

When NodePort is used, the client connects directly to a certain node (client->node). When LoadBalancer is used, the client connects to the cloud platform's load balancer instead (client->load balancer->node). Then the load balancer picks a node and connects the client to it.

So it sits in the middle, so to speak. Clients don't connect directly to nodes anymore when this is used. And the LoadBalancer can do its job and actually load balance traffic. This ensures nodes are somewhat evenly used, and no single node is hammered with all the requests.

Another thing worth mentioning: The LoadBalancer Service can only be used when the Kubernetes cluster is provisioned on a cloud platform that supports this Service type.

Now that you understand the key differences among ClusterIP, NodePort, and LoadBalancer Service types, let's discuss when to use which type.

Use cases

The choice of which Kubernetes Service type to use depends on the specific requirements of your application and the environment where it is running. Having said that, here is a brief overview of when to use which Service type:

ClusterIP:

Use this Service type when you want to expose an application within the cluster and allow other Pods within the cluster to access it.

NodePort:

Use this Service type when you want to expose your application on a specific port on each worker node in the cluster, making it accessible to external connections (coming from outside the cluster). NodePort Services are often used for development and testing purposes.

LoadBalancer:

Use this Service type when you want to expose your application to external clients. Sounds like the same thing mentioned for NodePort. But, there's the added benefit. You take advantage of a cloud provider's load balancing capabilities. And all client requests can be smoothly load balanced to multiple nodes in your cluster.

LoadBalancer Services are typically used in production environments. Why? One big reason is the increased reliability. When clients connect to one node specifically (through NodePort), if that node fails, the clients will be left hanging. Their requests will remain unfulfilled as the node is unreachable.

But, with a LoadBalancer, if one node fails, the LoadBalancer doesn't rely on a single node (it sends traffic to all). So only a few requests hitting the problematic node will fail, not all.

And with proper health checks in place, the LoadBalancer can stop sending traffic to the failed node. So future client requests can all land on healthy nodes.

FAQ

Does ClusterIP do load balancing?

Yes, the ClusterIP Service does load balancing, but for the Pods (not nodes). When a client sends a request to the ClusterIP Service, Kubernetes uses a round-robin algorithm to distribute traffic evenly among the available Pods behind the Service.

Does NodePort create ClusterIP?

Yes, when you create a NodePort Service, Kubernetes automatically creates a ClusterIP Service. Otherwise, NodePort would have a hard time figuring out where to send the traffic received on that node. What group of Pods should it reach? ClusterIP helps NodePort send traffic to the correct Pod. It also allows other Pods in the cluster to reach one of the Pods in that group using the virtual IP address provided by the ClusterIP Service.

Does NodePort have external IP?

A NodePort Service does not have a single IP address associated with it. Instead, it opens a port in the range of 30000 and 32767 on all of its worker nodes. Each worker node has a different IP address, and a client can connect to any of those IP addresses to access the Service.

So, in that sense, we can say that a NodePort Service has many IP addresses associated with it, assuming that there are multiple worker nodes running in the cluster. This is different from a LoadBalancer Service, which typically has a single external IP address associated with it, provided by the cloud provider's load balancer Service.

Conclusion

We hope that this post has given you a good understanding of the three primary Kubernetes Service types and has clarified the key differences among them.

In addition to the three Service types we've covered in this post, Kubernetes also provides another Service type called ExternalName Service. To learn more about it, check out our post, Kubernetes Services: Definitions & Examples (2023).

It's also important to be familiar with the concept of Headless Service in Kubernetes. This allows clients to connect to the Pod(s) directly, without the Service routing the request like a regular Service does. To learn more about Headless Services and how they work, read our blog post, What Is Kubernetes Headless Service (With Examples)?

If you're interested in learning more about Kubernetes, check out the Kubernetes courses offered by KodeKloud:

• Kubernetes for the Absolute Beginner.
• Certified Kubernetes Administrator (CKA)
• Certified Kubernetes Application Developer (CKAD)