Where Operators Come From
Where Operators Come From
OperatorHub.io catalogs OLM-packaged operators; ArtifactHub aggregates those alongside Helm charts, OPA policies, and more. Each entry shows supported distributions, channels (stable, fast, edge), and maturity — the Operator Maturity model grades capabilities from install/upgrade through failover and auto-tuning.
OLM (Operator Lifecycle Manager), standard on OpenShift and installable elsewhere, manages the lifecycle: it installs ClusterServiceVersion (CSV) objects describing the operator's permissions, deploy modes (AllNamespaces vs OwnNamespace), webhooks, and upgrade rules. Operators not distributed through OLM are usually plain Helm charts — check ArtifactHub for both.
Installing and Managing
Installing and Managing
With OLM, subscribe to a package:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata: { name: etcd-operator, namespace: operators }
spec:
name: etcd-operator
source: community-operators
channel: stable
installPlanApproval: Automatic
Then inspect: kubectl get csv -n operators, kubectl get subscriptions -n operators, kubectl get installplan -n operators. With Manual approval, upgrades create an InstallPlan you must approve explicitly — a deliberate production gate. Without OLM, install via Helm (helm install postgresql bitnami/postgresql); for air-gapped fleets, build an index with opm and serve a local catalog source.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Maturity mismatch. An operator graded only at "install" will not upgrade your data safely — for stateful workloads demand upgrade/failover levels or be prepared to run the upgrade yourself.
Cluster-wide RBAC. Many operators request AllNamespaces and ClusterRoles spanning many groups. Read the CSV/Role before install; OwnNamespace or SingleNamespace modes exist for a reason.
Conflicting owners. Two operators managing the same CRD or webhook fight over finalizers and conversions — check which CSV owns each CRD.
Channel blindness. installPlanApproval: Automatic on stable can apply an upgrade the moment it appears; pin versions or switch to Manual for critical operators.
Interview angle: explain the OLM object chain (Subscription → InstallPlan → CSV → deployment) and how you evaluate an operator before it touches production.
Quiz
1. What does a ClusterServiceVersion describe?
2. How do you gate operator upgrades until reviewed?
3. What is a key risk of installing an operator with AllNamespaces scope?
Flashcards
Question
OperatorHub vs ArtifactHub
Click to reveal answer
Answer
OperatorHub catalogs OLM operators; ArtifactHub aggregates OLM, Helm, and other CNCF packages.
Question
CSV
Click to reveal answer
Answer
ClusterServiceVersion — OLM's operator install manifest: RBAC, deploy mode, owned CRDs, webhooks.
Question
Subscription → InstallPlan → CSV
Click to reveal answer
Answer
Subscription selects package/channel; InstallPlan executes install/upgrade steps; CSV represents the running operator version.
Question
Operator maturity levels
Click to reveal answer
Answer
Install, upgrade, failover/backup, auto-tune — gradations of day-2 capability to check before adoption.
Revision Notes
Key Takeaways
- 1. Discovery happens on OperatorHub/ArtifactHub; maturity and channels decide production fitness
- 2. OLM manages lifecycle through Subscription, InstallPlan, and CSV objects with approval gates
- 3. Audit RBAC scope and CRD ownership before any operator joins the cluster
Interview Tips
- • Describe the OLM object chain end-to-end, including where manual approval inserts
- • Give your adoption checklist: maturity, RBAC, channels, CRD ownership, upgrade rehearsal
Cheat Sheet
Find on OperatorHub/ArtifactHub. OLM chain: Subscription → InstallPlan → CSV; Manual approval gates upgrades. Check maturity, channels, RBAC scope (AllNamespaces risk), CRD ownership conflicts.