If you’ve ever tried to set up a Redis cluster in Kubernetes, you’ve probably stumbled upon two types of services: the ClusterIP service and the Headless service. At first glance, they might seem like two sides of the same coin, but trust me, they’re not.
What’s a Redis Cluster?
Before we get into the services, let’s quickly recap what a Redis cluster is. Redis cluster is a distributed version of Redis that allows you to shard your data across multiple nodes automatically. It’s like having a team of Redis instances working together, each handling a portion of the data. This setup gives you high availability, fault tolerance, and the ability to scale horizontally. For more info on the Redis cluster, see Redis documentation.
In my local K8s cluster, I’ve deployed a Bitnami Redis cluster. When I do a kubectl get pods -n redis, it shows me 6 pods because I have configured the cluster to have 3 master nodes and one slave node each.
Now, let’s check what are the services created for the Redis cluster with kubectl get svc -n redis:
It lists three services: redis-cluster (also known as the Cluster IP service), redis-cluster-headless, and redis-cluster-metrics. As the name suggests, the metrics service is used to expose Redis cluster metrics for monitoring.
In this blog, we’ll focus on the headless service and the cluster IP service.
The Cluster IP Service
The cluster IP service, or in my example, the redis-cluster service is a standard Kubernetes service that provides a single, stable IP address for accessing a set of pods. It load-balances traffic across the pods, making it easy to use for basic operations. When a client connects to this service, Kubernetes load-balances requests across the Redis nodes making it a straightforward method for simple use cases.
While the cluster IP service is easy to use, it has some limitations when it comes to a Redis cluster.
Redis cluster uses MOVED and ASK redirections to make sure the commands are routed to the correct node. In a cluster setup, each node is responsible for a specific range of hash slots. The hash slot for a given key is determined using the CRC16 algorithm, with the total number of hash slots being fixed.
For example, in my Bitnami Redis cluster, let’s assume that the master nodes handle the following ranges:
- Node 1: 0–5460
- Node 2: 5461–10922
- Node 3: 10923–16383
If a key falls into hash slot 1234, it belongs to Node 1. However, when a client sends a command to store this key, it cannot directly connect to Node 1. The cluster IP service load balances the request and forwards it to a random pod. If the selected pod doesn’t serve the required hash slot, it responds with MOVED or ASK, instructing the client to reach the correct node.
When the client retries to connect to the correct node, it again connects via the cluster IP service, but since the service is load-balanced, the request is sent to another random pod. This cycle continues, preventing a direct connection to the intended node.
Click here for the full quality image.
The Headless Service
Unlike the cluster IP service, the headless service is designed to expose the individual IPs of your Redis pods, allowing clients to connect directly to the Redis nodes as needed.
If you look at the earlier image showing the list of services, you’ll notice that the headless service doesn’t have an assigned IP. Instead, when a client queries its DNS name (e.g.: redis-headless.namespace.svc.cluster.local), it gets back the IP addresses of all Redis pods in the cluster. The client can then connect to one of these nodes and use the CLUSTER NODES or CLUSTER SLOTS command to retrieve the full cluster topology. This provides key details like node roles (master or slave) and hash slot assignments, allowing the client to map out the cluster.
With this information, when a client needs to store a key, it can determine which node is responsible for that key and connect directly using the headless service—ensuring efficient and accurate routing of requests.
Which service should I use?
If you’ve tried setting up a service that connects to a Redis cluster using a Redis client, you might have run into connection issues when using the cluster IP service. That’s because most Redis clients (if not all) are designed to understand the cluster topology and send commands directly to the right node, avoiding redirections.
So, if you’re connecting to a Redis cluster from a client, you need to use the headless service.
However, if you’re just running simple operations and performance isn’t a concern—like testing the Redis cluster from the CLI—the cluster IP service will work just fine.
That’s it for this post! If you have any questions, drop them in the comments. Thanks for reading!