Why Operators are essential for Kubernetes

Red Hat OpenShift has 30 Operators out of the box

Cluster operators allow Red Hat to automate installations of Red Hat OpenShift in public or private cloud environments and provide core Day 2 functionality from the outset, including an automated, in-place upgrade process. 

OpenShift features 30 Operators, which run each major part of the platform such as version control, ingress, cluster autoscaling and many others. These are fundamental components to have a stable, more secure, and scalable platform to work on. Out of the box, Red Hat includes Operators that make using and operating OpenShift in supported deployment environments the same.

So far, we’ve mainly concentrated on discussing the cluster Operators that Red Hat provides as part of Red Hat OpenShift, allowing you to install and manage a platform going forward. But what about those services that you want to install on your existing clusters to provide operational, development and other services? These can be written in-house or by third-party vendors which require Kubernetes to understand specific domain knowledge about an application (for example, MongoDB, KongEE, Istio, serverless, security or others). 

Red Hat’s resources for Operator best practices

In creating and managing a large number of Operators in OpenShift, Red Hat realized there was a need for some best practices for managing app installs and updates on Kubernetes. So the Operator Framework was created, and we use this to certify vendor Operators that Red Hat OpenShift supports.

The framework includes a set of tools to aid in the development of Operators using technologies and language frameworks such as Ansible, Helm, GO or Java and their management, including cluster-admin control on access and installs and upgrade paths. These tools are called the Operator SDK and the Operator Lifecycle Manager (OLM), respectively. The OLM is installed on Red Hat OpenShift out of the box.

To do this on Kubernetes, you need the proper foundations to start. Installing some key Operators on top of any Kubernetes distribution without understanding how they work through updates and different environments is only going to make the adoption in your organization harder. As is going to the effort to build and use an Operator from scratch without a framework to support it. 

The OLM fundamentally takes the pain out of writing, developing and managing Operators across multi-tenant Kubernetes clusters. These are tried and tested approaches, and doing it from scratch is really for those people who enjoy doing Kubernetes the hard way.

Kubernetes without Operators? No, thanks.

Without the OLM and the domain knowledge of every layer of the platform, managing Operators and thus the cluster(s) stability becomes really hard to maintain through updates and scale. You do not want to be left debugging Operators on clusters. And without Operators - well, Kubernetes becomes real hard work as you manually do the things an Operator would do to keep service(s) healthy.