Skip to content

Getting started with Operators in OpenShift

An Operator extends Kubernetes to automate the management of the entire life cycle of a particular application. Operators serve as a packaging mechanism for distributing applications on Kubernetes, and they monitor, maintain, recover, and upgrade the software they deploy.

For context:

  • Manifests work great to manage stateless applications.
  • Operators make it easy to manage complex stateful applications on top of Kubernetes.

What are Operators?

Operators are Kubernetes applications. There are lots of ways to extend Kubernetes. In this tutorial, you will learn about Operators and custom resources.

Operators make it easy to manage complex stateful applications on top of Kubernetes.

Operators allow you to write code to automate a task, beyond the basic automation features provided in Kubernetes. For teams following a DevOps or site reliability engineering (SRE) approach, operators were developed to put SRE practices into Kubernetes.

IBM Cloud Paks are collections of Operators that you install. Links at the end of the document gets you started in deploying Cloud Pak for Integration using Operators.

Definitions

All Operators use the controller pattern, but not all controllers are Operators.

It's only an Operator if it's got:

controller pattern + API extension + single-app focus.

A Kubernetes operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and manage instances of complex applications on behalf of a Kubernetes user.

It builds upon the basic Kubernetes resource and controller concepts, but includes domain or application-specific knowledge to automate the entire life cycle of the software it manages.

A custom resource is the API extension mechanism in Kubernetes. A custom resource definition (CRD) defines a CR and lists out all of the configuration available to users of the operator.

Operator is a customized controller implemented with a CRD. It follows the same pattern as built-in controllers (i.e. watch, diff, action).

How Does a Kubernetes Operator Work?

Operators use controllers that monitor Kubernetes objects. These controllers are slightly different from regular Kubernetes controllers, because they track custom objects, known as custom resource definitions (CRDs). A CRD is an extension of the Kubernetes API that provides a place to store and retrieve structured data (the desired application state).

Operators track cluster events related to specific types of custom resources. These custom resources can track three types of events:

  • Add
  • Update
  • Delete

When the operator receives the information, it takes action to bring the Kubernetes cluster or external system to the desired state as part of the custom controller scaling cycle.

To summarize a Kubernetes operator’s workflow:

  1. User makes changes to a CRD
  2. The operator tracks the CRD and identifies change events
  3. The operator reconciles the CRD state with the desired state
  4. The operator adjusts cluster state to the desired state

The following illustration shows the steps Kubernetes uses in the Operator's workflow.

kubernetes operators

Create a CRD

The manifest below shows an example CRD crd.yaml:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: appconfigs.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: appconfigs
    singular: appconfig
    kind: AppConfig
    shortNames:
    - ac
Run kubectl create -f crd.yaml to create the CRD.

To use the CRD, create a manifest using the kind we created with the CRD. For example my-kind.yaml:

apiVersion: "stable.example.com/v1"
kind: AppConfig
metadata:
  name: demo-appconfig
spec:
  uri: "some uri"
  Command: "some command"
  image: my-image

To use the AppConfig, run kubectl create -f my-kind.yaml.

When you want to create your own custom resource resource definition, you will want to start with [Operator SDK].

Operator Framework

The Operator Framework includes:

  • Operator SDK: Enables developers to build operators based on their expertise without requiring knowledge of Kubernetes API complexities.
  • Operator Lifecycle Management: Oversees installation, updates, and management of the lifecycle of all of the operators running across a Kubernetes cluster.
  • Operator Metering: Enables usage reporting for operators that provide specialized services.

Operator.io

OperatorHub.io is a new home for the Kubernetes community to share Operators.

OperatorHub.io

RedHat OperatorHub

Red Hat has its own Operator Hub within OpenShift that are groups into categories:

  • Red Hat Operators, supported by Red Hat
  • Certified Operators, from ISVs
  • Red Hat Marketplace, can be purchsed
  • Community Operators with no official support
  • Custom Operators, roll your own

The following illustration shows how to find the OpoeratorHub in the OpenShift portal.

red hat operator hub

Operator lifecycle manager

Operators on OperatorHub are packaged to run on Operator Lifecycle Manager (OLM).

The level of sophistication of the management logic encapsulated within an Operator can vary. This logic is also in general highly dependent on the type of the service represented by the Operator.

operator maturity

Prerequisites

You will need either:

Kubernetes 1.17-1.21 OpenShift 3.11, 4.3-4.7

Log in to OpenShift.

Install the Jenkins Operator using the UI

Jenkins Operator is a Kubernetes native operator which fully manages Jenkins on Openshift. It was built with immutability and declarative configuration as code in mind. It is meant to replace the Jenkins on Openshift Template as the primary source of deploying Jenkins on Openshift while also easing the Operational work necessary to manage the Jenkins Instance(s) on an Openshift Cluster.

Out of the box it provides:

  • Integration with Kubernetes
  • Pipelines as code
  • Extensibility via groovy scripts or configuration as code plugin
  • Security and hardening
  • Backup and restore

After you log in, use:

oc new-project test-jenkins

Go to OperatorHub and select Jenkins Operator. Fill in using the test-jenkins namespace.

Click Installed Operators. Click Pods.

To get the route to Jenkins

oc get svc

In the UI, in RedHat OpenShift Container Platform UI under Administrator, view the Deployments, Pods, Secrets (filter on jenkins).

Follow the example docs here

You now have Jenkins installed as an Operator with the Automatic strategy using the Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.

Getting started to build a custom Operator with HELM

You can build your own custom operator. You would begin with the Operator SDK.

cd into your directory and then use the following:

mkdir nginx-operator
cd nginx-operator
operator-sdk init --domain example.com --plugins helm

The code initializes a new project including vendor/ directory and Go package directories.

Writes the following files:

  • Boilerplate license file
  • PROJECT file with the domain and repo
  • Makefile to build the project
  • go.mod with project dependencies
  • Kustomization.yaml for customizating manifests
  • Patch file for customizing image for manager manifests
  • Patch file for enabling prometheus metrics
  • main.go to run

Create a simple nginx API using Helm’s built-in chart boilerplate (from helm create):

operator-sdk create api --group demo --version v1alpha1 --kind Nginx

Use tree to see what it created

tree

Open the crd base file for your new example:

nano config/crd/bases/demo.example.com_nginxes.yaml

For more information, see Quickstart for Helm-based Operators

Next step to create your custom Operator

See Operator Reconciliation: "You can't always get what you want... or can you?". See Operator Framework tutorial in IBM documents.

News

Cassandra to Operator

Next steps

Try Install, Configure and Expose MongoDB on IBM Cloud Pak for Data (ICP4D)

Try Express installation of Cloud Pak for Integration

References