Kubernetes Operators Patterns and Best Practices

Using operators to manage the lifecycle of multi-cloud, Kubernetes-based applications

Reasons to use Kubernetes Operators

Operators should be an integral part of the development of enterprise applications so that they can be used to automate potentially complex error-prone human tasks during installation, maintenance, or monitoring.

  • Hubs and Marketplaces
  • Internal and external multi-tenancy applications
  • Ecosystem, tools, and offerings
  • Kubernetes is an industry standards

Sample application deployable as operators

To help you understand the benefits of using Kubernetes operators, the Kubernetes Operator Patterns and Best Practices project provides a reference that includes a sample application that is deployed and managed by sample operators. The project demonstrates how to use an operator to create Kubernetes resources for a sample two-tier application. The project is available via open source in this public GitHub repo. In addition, the project demonstrates uses cases which represent the entire range of resources lifecycle management capabilities.

Sample application architecture

Here is an architecture diagram of our sample application:

Sample operator capabilities

The sample operators demonstrate the following capabilities:

  • Day 1 deployment — The operators define custom resource definitions, defining new resources and APIs on the cluster. This capability makes it easy for administrators to create abstracted resources which represent an entire application, without the need to create many individual Kubernetes resources. The operators demonstrate how to code a Kubernetes controller which uses the Kubernetes API from Go to automate the creation and configuration of many common resources such as deployments, statefulSets, secrets, and services.
  • Day 2 Auto Backup — This common Day 2 activity often requires manual activities. The sample operators define a custom resource which allows the administrator to define an automated backup strategy. The operator reconciles this by creating a scheduled CronJob resource which launches a stand-alone application to query the database and backup the data to a storage repository.
  • Day 2 Auto Scaling — This common Day 2 activity can require human operators to study metrics and alerts. Although existing Kubernetes technologies like Horizontal Pod Autoscaler are available, the sample operators take a different approach by creating a CronJob resource which launches a stand-alone application to make scaling decisions. This provides complete flexibility, as the application can consider multiple cluster metrics or even external systems to make a scaling decision.

Deploying the sample operators

To set up and build your own environment, you can review the prerequisites, required CLIs, environment configuration in the documentation in the project overview.

Summary and next steps

The operator sample application provides a step-by-step guide to build and deploy a set of operators, testing either locally or deploying to a cluster using Operator Lifecycle Manager (OLM). You can use the guidance provided to gain hands-on experience with developing and deploying operators.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store