Redis Enterprise Operator for Kubernetes

Earlier this year, we introduced a Helm Chart for the Redis Enterprise Kubernetes release. The Redis Enterprise release deploys and maintains resources needed to run a Redis Enterprise cluster within a Kubernetes cluster. In the earlier release, we wrote our own service manager that publishes Redis database endpoints in the Kubernetes service catalog. Initially, we thought that having a service manager, readiness probes and Kubernetes secrets was sufficient to manage the lifecycle of the Redis Enterprise cluster. However, we soon realized that there is a better and kube-native way of managing the lifecycle of our data service in Kubernetes.

Why Operator?

Let's start by answering the question: "Why do you need an Operator?" Since 2016, CoreOS (now a part of Red Hat) has been advocating a need for a controller in Kubernetes that understands the lifecycle of an application. Although Kubernetes is good at scheduling resources and recovering containers gracefully from a failure, it does not have primitives that understand the internal lifecycle of a data service. As such, adopting the Operator paradigm for Redis Enterprise is a natural progression of our Kubernetes work. Operator not only offers the benefits of a typical controller but also allows you to describe failure recovery using domain and/or application knowledge.

So What Does the Redis Enterprise Operator Actually Provide?

The Operator framework takes advantage of Custom Resource Definitions (CRDs) to manage and maintain domain-specific objects in Kubernetes. By capturing domain or application-specific lifecycle management logic inside the Operator, the Operator aims to reduce deployment and maintenance complexity. Thus, by making it easier to expose the Operators to specific namespaces and/or track instances across namespaces, the Operator will lower the operational burden for our customers. The following are our design goals for the initial release of Redis Enterprise Operator:

• Create a Redis Enterprise cluster in a user-defined namespace.
• Rejoin existing cluster nodes after a pod failure.
• Ability to evacuate databases on a pod gracefully before termination.
• Protect against invalid deployments.
• Provide a Redis Enterprise cluster state that allows for better lifecycle management (such as controlling the cluster version update process).

Redis Enterprise Operator-Based Cluster in Kubernetes

The following steps are required to deploy the cluster using the Operator framework:

1. Deploy the Redis Enterprise Operator into a user-specified namespace:

kubectl apply -f redis-enterprise-operator.yml

2. Create a Custom Resource Defininition (CRD) for redis-enterprise in the Kubernetes cluster:

kubectl apply -f redis-enterprise-crd.yml

3. Use the Operator and CRD to deploy a Custom Resource (CR) in the user specified for redis-enterprise

kubectl apply -f redis-enterprise-cr.yml

Conclusion

An Operator makes it easy to package, deploy and manage a Kubernetes application. With Redis Enterprise Operators we simplify managing the cluster operation lifecycle with automation and efficiency. By protecting and/or warning against invalid deployment, Redis Enterprise reduces operational burden and complexity. The Operator framework approach allows us to codify the domain logic of the Redis Enterprise cluster, reduce deployment time and increase maintainability.

What's next?

If you would like to start experimenting with our Redis Enterprise release based on Operator framework, please contact expert@redislabs.com so that we can help you with your Redis needs.