Skip to main content
Let’s explore the Operator Framework and how it simplifies packaging and operating applications on Kubernetes. Previously we discussed creating a CustomResourceDefinition (CRD) and a custom controller that implements the reconciliation logic for that CRD. Those are two separate artifacts: you manually create the CRD and CR resources, and you deploy the controller as a Pod/Deployment. The Operator Framework bundles these pieces together so the CRD(s) and their controllers can be packaged, deployed, and managed as a single logical unit — an operator. What an operator typically contains:
  • One or more CRDs that define the custom resources.
  • Controllers that implement reconciliation and business logic for those resources.
  • Optional auxiliary controllers or components for tasks such as backup/restore, monitoring, migration, or other operational workflows.
Common operator capabilities:
  • Install and configure application components.
  • Manage lifecycle actions such as scale, upgrade, backup, restore, and recovery.
  • Automate routine operational tasks and respond to failures.
Below is an example CRD for a fictional FlightTicket resource, followed by illustrative controller snippets.
Controller snippets (Go) — these illustrate the package structure and main reconciliation entrypoints:
You can package the CRD and controller together as an operator manifest and deploy it like this:
One widely used operator is the etcd operator. It provides an etcdCluster CRD and a controller that watches EtcdCluster resources and deploys and manages etcd clusters inside Kubernetes. Beyond creation and scaling, operators often implement higher-level operational tasks — for example automatic backups, scheduled restores, or cluster repairs — usually implemented as separate controllers/modules inside the operator (for example: backup and restore operators).
A diagram of an Operator Framework showing Custom Resource Definitions — EtcdCluster, EtcdBackup, and EtcdRestore — on the left and corresponding Custom Controllers — ETCD Controller, Backup Operator, and Restore Operator — on the right. The diagram is labeled "Operator Framework."
Operators automate many tasks a human operator would otherwise perform for an application: installation, maintenance, backups and restores, failure response, and routine operational workflows. Many popular applications have community or vendor operators available, including etcd, MySQL, Prometheus, Grafana, Argo CD (GitOps), and Istio Service Mesh. A central catalog of operators is available at OperatorHub. Useful links and references: Key resources in an operator (summary table) Installing operators — typical workflows
  1. Ensure your cluster has OLM (Operator Lifecycle Manager). OLM helps install and manage operators and their dependencies.
  2. Install an operator via OLM/OperatorHub or by applying the operator manifest directly.
Example commands (adjust versions and namespaces for your environment):
Best practices and operational notes:
  • Review the operator bundle and RBAC scopes before deploying to production.
  • Test operators in staging clusters to validate behavior (backups, restores, upgrades).
  • Prefer operators listed on OperatorHub or maintained by trusted vendors or the community.
  • Use OLM to manage operator upgrades and lifecycle where possible.
Operators are powerful: they package CRDs and the operational logic for an application. Installing an operator often automates many manual operational tasks, but always review operator manifests and RBAC scopes before deploying them in production.
This lesson focused on CRDs and how custom resources work within operators. Authoring and advanced operator patterns (multi-controller architectures, operator SDKs, advanced lifecycle hooks) are rich topics that deserve dedicated lessons or a full course. Thank you for reading this lesson.

Watch Video