Certified Operator Build Guide
Search…
Certified Operator Build Guide
Introduction
What is an Operator?
Pre-Requisites
Helm Operators
Building a Helm Operator
Ansible Operators
Building an Ansible Operator
Golang Operator Gotcha's
Writing to the Status Subresource
OpenShift Deployment
Operator Metadata
Installing an OpenShift Environment
Deploying onto OpenShift
Troubleshooting and Resources
Creating an Ansible Role From a Helm Chart
Security Context Constraints
Connect Metadata Test Results
Red Hat Marketplace Requirements
Appendix
What if I've already published a Community Operator?
Community Operators
AWS OpenShift 4 Cluster Quick Start Guide
Using Third Party Network Operators with OpenShift
Bundle Maintenance After Migration
Frequently Asked Questions (FAQ)
Multi-Arch Operator Certification
Powered By GitBook
What is an Operator?

An Operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl/oc tooling. You can think of Operators as the runtime that manages this type of application on Kubernetes.
Operators fall into a few different categories, based on the type of applications they run:
  1. 1.
    Service Operators (MongoDB, Spark, Nginx)
  2. 2.
    Platform Operators (aggregated logging, security scanning, namespace management)
  3. 3.
    Resource Operators (CNI operators, Hardware management operators, Telco/Cellular radios)
  4. 4.
    Full Solution (combination of above operators)
Conceptually, an Operator takes human operational knowledge and encodes it into software that is more easily packaged and shared with consumers. Think of an Operator as an extension of the software vendor’s engineering team that watches over a Kubernetes environment and uses its current state to make decisions in milliseconds. Advanced Operators are designed to handle upgrades seamlessly, react to failures automatically, and not take shortcuts, like skipping a software backup process to save time.

  • Pod startup ordering: Kubernetes does not provide guarantees of container- or pod-startup ordering without sophisticated use of concepts like init containers.
  • Familiar experience on any infrastructure: Your customers have the same deployment and day 2 experience regardless of infrastructure provider - anywhere Kubernetes runs, your Operator should run.
  • Provider maintained: De-couple your OSR from the release cadence of Kubernetes/OpenShift itself, and deliver features, bug- and security-fixes to your customers as they become available.
  • Ease of installation: We have heard from vendors providing out-of-tree kernel modules that installations (DKMS or manual rpmbuild / similar) end up in a poor experience (even for sophisticated customers). Operators provide a one-click method for installation and operations of your hardware and software stack.
  • Standardized operational model and reduce support burden: Operators provide a way for you to standardize deployments, upgrades and configuration to only what you support. This avoids “snowflake” deployments and ensures smooth upgrades.
  • Upgrades: Operators allow you to encode best-practices (e.g. straight from your documentation), reducing configuration drift in customer deployments, increasing deployment success ratio and thereby reducing support costs.
  • Network adapter integrations “White list” of supported SR-IOV card/driver combinations for the device and CNI Multus plugins
Previous
Introduction
Next
Pre-Requisites
Last modified 3yr ago
Copy link
On this page
What is an Operator?
Advantages of Operators