Kubernetes Operator Management

Kubernetes Operator Management is the practice of installing, upgrading, monitoring, and removing an Operator itself as a piece of cluster software, distinct from managing the custom resource instances it reconciles, covering packaging formats, installation tooling such as the Operator Lifecycle Manager, upgrade channel strategy, and the health monitoring specific to the Operator's own deployment.

Packaging an Operator for Distribution

Bundle Format

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-operator-metadata
data:
  clusterServiceVersion.yaml: |
    apiVersion: operators.coreos.com/v1alpha1
    kind: ClusterServiceVersion
    metadata:
      name: postgres-operator.v1.4.0
    spec:
      version: 1.4.0
      installModes:
        - type: AllNamespaces
          supported: true
        - type: SingleNamespace
          supported: true

An Operator bundle packages its CRDs, RBAC manifests, Deployment definition, and a ClusterServiceVersion describing its capabilities, supported install modes, and version metadata into a single distributable unit, consumable by installation tooling without requiring the cluster administrator to individually apply each underlying manifest.

Install Modes

The installModes field declares whether the Operator supports watching a single namespace, an explicit set of namespaces, its own namespace only, or every namespace cluster-wide, directly constraining the scope choices discussed under Operator extensibility scope to what the Operator author has actually built and tested.

Installing via the Operator Lifecycle Manager

Subscriptions and Channels

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: postgres-operator-subscription
  namespace: databases-system
spec:
  channel: stable
  name: postgres-operator
  source: operatorhubio-catalog
  sourceNamespace: olm
  installPlanApproval: Automatic

The Operator Lifecycle Manager (OLM) tracks a Subscription to a named channel (stable, alpha, fast) within a catalog source, and automatically installs or upgrades the Operator to the latest version published on that channel, decoupling the cluster administrator's upgrade cadence choice from manually tracking individual release announcements.

Manual Installation Without OLM

kubectl apply -f https://example.com/postgres-operator/v1.4.0/install.yaml

Not every cluster runs OLM; many Operators are alternatively distributed as a single aggregated manifest or a Helm chart, applied directly, which shifts the responsibility for tracking available versions and applying upgrades onto the cluster administrator or their own GitOps pipeline rather than an OLM subscription.

Upgrade Strategy

Automatic vs. Manual Approval

spec:
  installPlanApproval: Manual

Setting installPlanApproval: Manual requires an administrator to explicitly approve each generated InstallPlan before an upgrade proceeds, trading the convenience of automatic upgrades for a deliberate review gate, which is the more common choice in production clusters where an Operator upgrade could involve a CRD schema migration affecting every existing custom resource instance it manages.

Rolling Upgrade of the Operator Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-operator
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

Because leader election ensures only one Operator replica actively reconciles at a time, a RollingUpdate strategy with maxUnavailable: 0 guarantees a standby replica is always available to take over leadership the instant the previous leader terminates, minimizing any gap in reconciliation coverage during the upgrade itself.

Monitoring the Operator's Own Health

Operator-Level Metrics Separate from Managed-Resource Metrics

up{job="postgres-operator"}
rate(controller_runtime_reconcile_errors_total{job="postgres-operator"}[5m])

Distinct from the health of the databases it manages, an Operator's own operational health, whether its pod is running, whether its reconcile loop is erroring, whether its leader election lease is being renewed, requires its own dashboard and alerting, since an Operator silently crash-looping leaves every custom resource it manages unreconciled without any of those resources themselves reporting an obvious symptom.

Uninstalling an Operator

Order of Removal and CRD Retention Risk

kubectl delete subscription postgres-operator-subscription -n databases-system
kubectl delete csv postgres-operator.v1.4.0 -n databases-system

Removing the Operator's Subscription and ClusterServiceVersion stops the reconciling controller but, deliberately, does not remove the CRDs or existing custom resource instances by default, since deleting a CRD cascades to delete every instance across the cluster; uninstalling an Operator therefore requires a separate, explicit decision about whether existing managed resources (and the infrastructure they represent, such as running database StatefulSets) should be torn down or left in place, unmanaged, until a replacement Operator is installed.

Relationship to Operator Scope and CRD Management

Operator management is the deployment and lifecycle layer wrapped around the RBAC and reconciliation concerns covered under Operator extensibility scope and the schema evolution concerns covered under CRD management: it determines when and how a new version of the Operator's code, RBAC, and CRD schema actually reaches a running cluster, making it the practical gate through which every other Operator-related capability is rolled out, upgraded, or withdrawn.