This is a guest post from Redis Labs. Vick Kelkar is a Global Technology Manager on Partnerships team at Redis Labs. In the last few years, he has focused on developing product and partnerships for microservice and platforms like OpenShift, PCF, PKS, Docker, and Kubernetes.

During the last few releases of Kubernetes, the Kubernetes community has managed to optimize the running of stateful applications by releasing new core primitives. For instance, the general availability of StatefulSet allows users to run stateful applications like databases on a Kubernetes and or Red Hat OpenShift cluster. OpenShift, Red Hat’s enterprise distribution of Kubernetes, has also introduced persistent volumes, which allow users to persist data across pod and/or service restarts. The introduction of the new core primitives allows OpenShift users to bring different application workloads onto a single OpenShift cluster. However, running complex use cases and or stateful applications via the built-in Kubernetes primitives continues to be a challenge.

Enter the Operator Framework

This is where the Kubernetes Operators come into the picture. Operators allow users to extend the Kubernetes primitives using custom resources and custom controllers. In May 2018, Red Hat released the Operator SDK as part of the Operator Framework. The Operator Framework essentially focuses on deploying and managing a stateful application by extending the Kubernetes application programming interfaces (APIs). The Operator SDK allows an application developer, such as a database vendor, to embed the domain-specific logic into the operator and extend the Kubernetes API. Red Hat has also included a few custom resources and operators in OpenShift release 3.11.

Why an Operator?

Operators are becoming a standard way of deploying complex stateful applications in Kubernetes. Redis Labs adopted the Operator Framework to enable our users to more efficiently deploy and manage the lifecycle of their Redis Enterprise clusters. The Operator Framework allowed us to introduce a Custom Resource Definition (CRD) called redisenterprisecluster or rec. The custom controller, which is a Redis Enterprise operator written in the Go programming language, allows us to embed application-specific lifecycle management logic into the operator. Using the operator, we are able to validate the state of the Redis Enterprise cluster.

OpenShift Specific Features

We take advantage of the multi-tenancy features offered by projects in the OpenShift platform and use the security context constraint it provides. We have published our sample security context constraint (SCC) deployment files for the OpenShift platform. Additionally, our Redis Enterprise and operator images are in Red Hat’s OpenShift container registry.

Figure 1: Redis Enterprise on the OpenShift container platform

Since adopting the Operator Framework, we continued to work with Red Hat to continually improve and enhance solutions like an ingress controller, which we currently plan to integrate with the OpenShift router.


  • Download the Operator-based deployment files for OpenShift here
  • Learn How to Install Redis Enterprise Clusters Using Operators on OpenShift here
  • Learn More about the Operator Framework here
  • Find more Community Operators here

If you have any further questions, please don’t hesitate to contact one of our Redis experts.

About the author

Red Hatter since 2018, tech historian, founder of, serial non-profiteer.

Read full bio