Certified Operator Build Guide
  • Introduction
  • What is an Operator?
  • Pre-Requisites
  • Helm Operators
    • Building a Helm Operator
      • Using a Single Image Variable (Red Hat Marketplace)
      • Dockerfile Requirements
      • Update the Controller Manager
      • Building and Pushing Image
  • Ansible Operators
    • Building an Ansible Operator
      • Using a Single Image Variable (Red Hat Marketplace)
      • Dockerfile Requirements
      • Update the Controller Manager
      • Building and Pushing Image
  • Golang Operator Gotcha's
    • Writing to the Status Subresource
  • OpenShift Deployment
    • Operator Metadata
      • Update CRDs from v1beta1
      • Creating the Metadata Bundle
      • Adjusting the ClusterServiceVersion
      • Reviewing your Metadata Bundle
      • Metadata Bundle Image
        • Managing OpenShift Versions
    • 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?
      • Consuming Applications from RHCC
      • Applying Security Context Constraints
      • Choosing a Unique Package Name
      • Assembling the Metadata Bundle
    • Community Operators
    • AWS OpenShift 4 Cluster Quick Start Guide
    • Using Third Party Network Operators with OpenShift
      • Appendix A - CNI Operator Manifests
      • Appendix B - Cluster Network Status
      • Appendix C - Operator Group Manifest
      • Appendix D - Subscription Manifest
    • Bundle Maintenance After Migration
    • Frequently Asked Questions (FAQ)
    • Multi-Arch Operator Certification
      • Glossary of Terms
      • Requirements and Limitations
      • Building a Multi-Arch Operator Image
      • Scanning and Publishing
      • Updating the Bundle Image
Powered by GitBook
On this page
  • What is an Operator?
  • Advantages of Operators

What is an Operator?

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. Service Operators (MongoDB, Spark, Nginx)

  2. Platform Operators (aggregated logging, security scanning, namespace management)

  3. Resource Operators (CNI operators, Hardware management operators, Telco/Cellular radios)

  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.

Advantages of Operators

  • 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

PreviousIntroductionNextPre-Requisites

Last updated 5 years ago