Kubernetes Operators
Kubernetes Operators extend the platform's control loop to manage complex, stateful applications automatically. They encode operational knowledge — installation, scaling, backup, upgrades — in custom controllers that reconcile desired state declared in custom resources.
itCloud native tools and technologies | OpenSkills.info
Recommended first:kubernetes-fundamentals
Intro
Kubernetes Operators
An operator is a piece of software that runs inside your cluster and manages an application the way a skilled human operator would — deploying it, backing it up, upgrading it, recovering it — using Kubernetes' own machinery to do so. The name is literal: the pattern captures the knowledge of a human operator who knows how a specific system ought to behave, how to deploy it, and how to react when it misbehaves, and encodes that knowledge as software.
The mental model builds on two ideas you already know from this series. Kubernetes is a set of controllers converging actual state toward desired state, and its API is extensible: you can add your own object types. An operator is exactly the combination — a custom resource that describes your application in domain terms, plus a custom controller that makes the description true. kind: PostgresCluster with replicas: 3, backups: nightly in the spec, and a controller that knows what those words mean operationally.
Why the pattern exists
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
Supports
- Operators as software extensions using custom resources to manage applications, following the control loop principle
- Human-operator motivation — capturing knowledge of deploying and operating a specific service
- Example operator behaviors — deploy, backup, upgrade-by-spec-change, recovery, simulation
- Deploying operators (CRD + controller Deployment); using operators via custom resources
- Writing operators with any API-client tooling when off-the-shelf doesn't fit
- https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
Supports
- CRDs registering new API types without code; custom resources as structured data
- Custom resources gaining kubectl, RBAC, and watch support like built-ins
- Combination of custom resources with custom controllers as declarative API
- When to use (and not use) custom resources
- https://kubernetes.io/docs/concepts/architecture/controller/
Supports
- Control loop principle — watching shared state and converging current toward desired
- Controllers acting via the API server; robustness of state-based reconciliation
- https://kubernetes.io/docs/concepts/extend-kubernetes/
Supports
- The extension-point landscape — where CRDs/controllers sit among webhooks, aggregation, plugins
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
Supports
- CRD schemas, validation, versioning and serving mechanics
- https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/
Supports
- Finalizers blocking deletion until controller cleanup; orphaned finalizers causing stuck deletion
- https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/
Supports
- ownerReferences and garbage collection of dependent objects
- https://kubernetes.io/blog/2016/11/introducing-operators/
Supports
- Origin of the operator concept — application-specific operational knowledge encoded in software (CoreOS, 2016)