--- title: A High Available Redis cluster on top of Kubernetes and Habitat description: In the last two months, I’ve worked together with Chef to evaluate Habitat from a cloud native developer perspective. This is the last blog in a series of three where I'll share my experiences. In this post I’m explaining how to run a HA Redis with Habitat on top of Kubernetes. image: http://cdn2.hubspot.net/hubfs/2668666/All-InOne-2016/Image/bg-img.jpg --- Check out our **[Cloud Native Services](https://www.container-solutions.com/services) **and** **book a call with one of our experts today!  [![Container Solutions](https://blog.container-solutions.com/hubfs/CS_blog/logo-main.svg "Container Solutions")](http://container-solutions.com) - share: - [**](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fblog.container-solutions.com%2Fa-high-available-redis-cluster-on-top-of-kubernetes-and-habitat-part-3) - [**](https://www.twitter.com/share?url=https%3A%2F%2Fblog.container-solutions.com%2Fa-high-available-redis-cluster-on-top-of-kubernetes-and-habitat-part-3) - [**](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.container-solutions.com/a-high-available-redis-cluster-on-top-of-kubernetes-and-habitat-part-3) - [**](https://blog.container-solutions.com/a-high-available-redis-cluster-on-top-of-kubernetes-and-habitat-part-3#) [![](http://cdn2.hubspot.net/hubfs/2668666/All-InOne-2016/Image/bg-img.jpg) ](https://blog.container-solutions.com/a-high-available-redis-cluster-on-top-of-kubernetes-and-habitat-part-3) [Miscellaneous](https://blog.container-solutions.com/tag/miscellaneous) # A High Available Redis cluster on top of Kubernetes and Habitat [Maarten Hoogendoorn](https://blog.container-solutions.com/author/maarten-hoogendoorn) ![Maarten Hoogendoorn](https://blog.container-solutions.com/hubfs/CS--Dev__Assets/asset%2011.jpeg) May 17, 2017 5 minutes Read *In the last two months, I've worked together with Chef to evaluate Habitat from a cloud native developer perspective. This is the last blog in a series of three where I'll share my experiences. The *[first blog](http://container-solutions.com/working-with-habitat-as-cloud-native-developer-p1/)* is about the build system. The second blog describes how to run supervisors on top of Kubernetes. In this last post I’m explaining how to run a HA Redis with Habitat on top of Kubernetes.* Before we jump to the part that is about [Habitat](http://habitat.sh/), I’d like to quickly introduce the relevant parts of Kubernetes. Then I’ll discuss some limitations of the build-in concepts of Kubernetes with relation to Self Organisation and show how Habitat compares to that. ### A quick intro to Kubernetes Kubernetes is an orchestration engine to run (micro)services. It makes decisions on where to run which workload. Developers write manifests to declaratively specify how their (micro)services should be deployed, which in turn is interpreted by Kubernetes. The basis in Kubernetes is the `Pod`, the minimal unit that can be deployed. `Pods` do not have any complex behavior on their own; if a `Pod`dies, it’s gone and nothing happens. However, there are higher level objects like `ReplicaSet`s, which has a template for the `Pod`s it should manage and some configuration on how many replica’s of the same `Pod` it should run. It makes sure that the correct number of replica’s is up by starting or killing pods. The `ReplicaSet` knows which `Pod`s it’s responsible for by selecting `Pod`s by label. Every object in Kubernetes can have multiple labels, which are arbitrary key/value pairs (with some constraints on the format of keys). Another example of how labels are used are `Service`s. `Service`s are used to provide service discovery: binding a name to a set of `Pod`s that implement this service. Services add `Pod`s by selecting on labels as well. ### Management of Redis on top of Kubernetes For stateless services, one should use a `Deployment`, which owns a `ReplicaSet`. When you want to deploy a new version of your service, you’d update the `Deployment`, which would create a new `ReplicaSet` and do a rolling update by scaling down the original `ReplicaSet`, and scaling up the `ReplicaSet` of the new version. Distributed services like Redis that manage state are harder. Especially when you’d have heterogeneous nodes. For example, Redis supports having one leader and multiple follower nodes, where the leader only accepts writes, which are then replicated to followers. `ReplicaSet`s can only create *identical* Pods, and therefore using them directly with Redis will not work; we’d either have only followers or leaders. ### The kubernetes way: Centralized Kubernetes’ answer to this problem is `Operator`s. They allow you to create a custom resource (like `Deployment` or `ReplicaSet`), which is backed by a central management container that will take care of your stateful service. It contains all the logic in one central place to create/monitor the `Pod`s in the cluster and make sure that they are set up correctly. ### Self organized with Habitat Habitat attacks this problem from the other side: each `Supervisor` instance gossips with each other to reach consensus about which pod should have which role. Habitat supports several topologies, but for Redis we’ll be using the Leader/Follower topology, which is a perfect fit for this purpose. Selecting this topology makes the Supervisor take care of the actual leader election process. It will trigger hooks and re-generate the configuration of the Redis service if the topology changes. Even better, the Habitat package core/redis which is managed by Chef, actually supports setting up a HA cluster by default! This allows us to simply create a `ReplicaSet`, where the Habitat Supervisors will take care of assigning the leader and follower role to the pod. However, this information should still be exposed to Kubernetes; we want to apply a label `role=follower` or `role=leader` to the `Pod` to make use of the `Service` abstraction in Kubernetes. The idiomatic way to implement this is to create a side-kick container that will run in the same `Pod` as the redis container. This side-kick container inspects which role the Supervisor has chosen and then applies the correct Kubernetes label. During the implementation, I encountered some issues with the provided hook not firing as I would expect it to. Given the constraints on time, I opted to create a simple side-kick container that polls the HTTP API endpoint provided by the supervisor and use that to compute the role of the pod. The code for the side-kick container can be found on [GitHub](https://github.com/ContainerSolutions/habitat-redis-ha-cluster-on-k8s). ### Conclusion During this project I encountered several issues, which Chef is picking up to solve. Habitat is positioning itself to be a an easy way to run stateful services on bare metal, cloud VM’s or orchestrators, as I have demonstrated in this blog post series. We at Container Solutions strongly believe that lowering (operational) knowledge from one central place to the services themselves is a trend that is only getting started. Habitat’s Supervisors, just like the [Autopilot Pattern](http://autopilotpattern.io/) are steps in this direction. [### What is a Cloud Native Strategy? ](https://blog.container-solutions.com/cloud-native-strategy) [![prev-arrow](https://cdn2.hubspot.net/hubfs/3842749/Wow%202019/Images/left-arrow.png) Previous article](https://blog.container-solutions.com/cloud-native-strategy) [ Next article ![next-arrow](https://cdn2.hubspot.net/hubfs/3842749/Wow%202019/Images/right-arrow.png) ](https://blog.container-solutions.com/3-common-cloud-native-goals-kind-company) [ ### The 3 Most Common Cloud Native Goals & What Kind of Comp... ](https://blog.container-solutions.com/3-common-cloud-native-goals-kind-company) Comments Leave your Comment ![cs-logo-white](https://blog.container-solutions.com/hs-fs/hubfs/cs-logo-white.png?width=150&height=61&name=cs-logo-white.png "cs-logo-white") #### **Talk to sales** [info@container-solutions.com](mailto:info@container-Solutions.com) #### Stay In Touch - [**](https://www.linkedin.com/company/container-solutions/) - [**](https://twitter.com/containersoluti) © 2024 Container Solutions