Before we measure maturity, we need to be clear about what is being measured. Let us build the idea from the ground up.

The problem Kubernetes cannot solve alone

Kubernetes is excellent at running stateless programs, which are programs that keep no important data inside themselves. If a web server pod dies, Kubernetes simply starts another one, and nothing is lost. But some applications are stateful. A database holds your customers’ orders. A message queue holds messages that have not been delivered yet. These programs have strict rules: which copy is the leader, which copies are followers, in what order they must start, and how data is copied between them. Kubernetes, by itself, knows none of this. It sees only containers.

Where the human expert used to fit in

Traditionally, a skilled database administrator or site reliability engineer carried that knowledge in their head. They knew how to create a replica, how to promote a replica when the leader died, how to take a safe backup, and how to upgrade without losing data. Every time something went wrong at three in the morning, a human woke up and ran a careful sequence of commands.

The Operator idea

In 2016, engineers at a company called CoreOS proposed a clever idea: write that human expert’s knowledge as software and run it inside the cluster. They called the result an Operator, because it does the work of a human operator. Their first examples were Operators for etcd and Prometheus. The idea spread quickly, and today there are Operators for databases, message brokers, monitoring systems, storage systems, and even cloud services.

The two ingredients

To understand why some Operators are more capable than others, you need to see the machinery inside every one of them.

Declared state and real state

Kubernetes works on a simple principle. You describe what you want in an object, which is called the desired state. The cluster looks at what actually exists, called the actual state. A program called a controller compares the two and takes actions to close the gap. This continues forever. If something breaks and the actual state drifts away, the controller notices and fixes it. This is the foundation of everything Kubernetes does.

Custom Resource Definitions

Kubernetes comes with built-in object types such as Pod, Service, and Deployment. A Custom Resource Definition, shortened to CRD, lets you teach the cluster a brand-new object type. Once the CRD is installed, users can create objects of that type just like any built-in one, use the same command-line tools, and apply the same access rules. The new object is called a custom resource.

The reconciliation loop

Inside every Operator there is a reconcile loop. Each time something related to a custom resource changes, the loop runs. It reads the desired state, looks at the actual state, decides what to do, does one small step, and reports the result back in the object’s status. Because the loop can run many times, every step must be safe to repeat. Engineers call this property idempotent: doing it twice has the same effect as doing it once.

flowchart TD
  U["User creates or edits a custom resource"] --> API["Kubernetes API server stores the object"]
  API --> W["Controller is notified of the change"]
  W --> R["Reconcile loop starts"]
  R --> C["Compare desired state with actual state"]
  C --> D{"Any difference?"}
  D -- "No" --> S["Update status and wait for the next event"]
  D -- "Yes" --> A["Take one safe action: create, update, or repair"]
  A --> S
  S --> W
    

Why “level-triggered” matters

A well-built controller does not rely on remembering the exact event that woke it up. Instead, it looks at the full current picture every time. Engineers call this level-triggered design, in contrast with edge-triggered design, which reacts only to the change itself. Level-triggered controllers recover gracefully from missed events, restarts, and crashes, because the next run simply re-examines everything. This is one of the main reasons the Kubernetes model is so resilient.

The helper machinery

Walk through any Operator catalog and you will find hundreds of entries, all described with the same friendly words. A maturity model helps you see through the marketing.

The honesty problem

Two Operators may both claim to “manage PostgreSQL”. One may merely generate the starting configuration and then step away. The other may monitor replication, promote a new leader during a failure, take verified backups, restore them on demand, and tune its own memory settings. From the outside, both look like a single custom resource. Without a shared scale, you cannot tell them apart until a crisis arrives.

What the model gives you

Where the model comes from

The five capability levels were introduced by the Operator Framework, an open-source project that also provides the Operator SDK for building Operators and the Operator Lifecycle Manager for installing and updating them. Public catalogs, such as OperatorHub, display a capability level for many listed Operators so that users can see at a glance how far each one goes.

What the model does not measure

The levels describe capability, meaning what the Operator can do. They do not measure code quality, security, performance, community health, or how well the Operator is documented. A Level 5 Operator that is poorly tested can be more dangerous than a well-tested Level 2 one. Throughout this post, we will keep these separate and give you checklists for the other qualities too.

Here is the whole ladder on one page. The next five chapters visit each step in depth.

flowchart BT
  L1["Level 1: Basic Install - automated setup and configuration"] --> L2["Level 2: Seamless Upgrades - patch and minor version updates"]
  L2 --> L3["Level 3: Full Lifecycle - backup, recovery, failure handling"]
  L3 --> L4["Level 4: Deep Insights - metrics, alerts, logs, analysis"]
  L4 --> L5["Level 5: Auto Pilot - scaling, tuning, self-healing, anomaly detection"]
    

The ladder is cumulative

Each level assumes the abilities of the levels below it. An Operator cannot honestly claim Level 3 if it cannot upgrade safely, because safe upgrades come at Level 2. Similarly, automatic tuning at Level 5 depends on the metrics gathered at Level 4. This is why you should climb in order rather than jump to the exciting top steps first.

A shortcut to remember the levels

The first step is the simplest: turn a short description into a correctly running application. Many Operators begin and sometimes end here.

What Level 1 means

At Level 1, the Operator provisions the application and applies its configuration automatically. You create a custom resource that says, for example, “I want a three-member message cluster with these settings”. The Operator creates the pods, the services, the storage claims, the configuration files, and the secrets, and wires them together so the application starts correctly. It also keeps the configuration in line with what you declared: if someone edits a setting in the custom resource, the Operator applies it.

What it saves you

Without an Operator, installing a clustered application often means filling in dozens of files and running several steps in the correct order. A single forgotten setting can cause a quiet failure that shows up weeks later. Level 1 replaces that pile of steps with one declaration, and, just as importantly, makes the installation repeatable. The same description produces the same result in a test cluster, a staging cluster, and production.

What a Level 1 Operator typically does

What it does not do

Installing is the easy part. The real test of any operational tool is what happens a year later, when the software needs to move to a newer version.

What Level 2 means

At Level 2, the Operator can upgrade the application it manages, including patch releases and minor version changes, with minimal downtime and without losing data. It also supports upgrading itself. You change the version in the custom resource, and the Operator carries out the careful sequence needed to get there.

Why upgrades are hard

Think about a database with one leader and two followers. If you restart them all at once, the service goes down. If you restart the leader first, you may lose recent writes. The safe approach is a rolling upgrade: update one follower, wait until it has caught up, update the next, and only then switch the leader role to an upgraded copy and update the old leader last. Each step must check that the system is healthy before moving on. Different applications have different rules, and some versions require special data migrations that must run exactly once.

sequenceDiagram
  participant U as User
  participant O as Operator
  participant F1 as Follower 1
  participant F2 as Follower 2
  participant L as Leader
  U->>O: Change version in the custom resource
  O->>F1: Upgrade and restart
  F1-->>O: Healthy and caught up
  O->>F2: Upgrade and restart
  F2-->>O: Healthy and caught up
  O->>L: Hand leadership to an upgraded member
  O->>L: Upgrade the old leader
  L-->>O: Healthy
  O-->>U: Status shows upgrade complete
    

The upgrade promises

Upgrading the Operator itself

An Operator is also software with versions. A new Operator version may change how it manages existing applications. A mature Operator must be able to take over applications that an older version created, without recreating them. The Operator Lifecycle Manager helps by describing which Operator versions can replace which, so that the cluster only follows supported upgrade paths.

Level 3 is where an Operator starts to earn the trust of people running important data. It covers everything that happens between birth and retirement of the application, including the unhappy parts.

What Level 3 means

At Level 3, the Operator manages the whole application lifecycle and its storage. That includes taking backups, restoring from them, recovering from failures, and handling data safely when the application is changed or removed. A human no longer has to run special scripts to protect the data.

The four big abilities

Failure handling in detail

Failures come in many sizes. A pod may crash and restart, which Kubernetes handles alone. A whole machine may disappear, taking the pod and its local storage with it. A network split may leave two parts of the cluster each believing the other is dead. The Operator must tell these cases apart and react correctly. Wrongly promoting a second leader during a network split can cause two copies of the data to diverge, a dangerous problem often called split brain. Mature Operators use careful rules, often relying on a trusted coordination mechanism, to make sure only one leader exists at a time.

flowchart TD
  F["Operator detects an unhealthy member"] --> Q{"Is it a pod crash, a lost node, or a network split?"}
  Q -- "Pod crash" --> R1["Let Kubernetes restart it and watch recovery"]
  Q -- "Lost node" --> R2["Create a replacement member and resync data from healthy copies"]
  Q -- "Network split" --> R3["Keep the side with a majority, fence the other side"]
  R1 --> OK["Update status: healthy"]
  R2 --> OK
  R3 --> OK
    

A backup is only real if you can restore it

A famous saying in operations is that nobody has backups; they only have restores. A backup that has never been restored might be empty, corrupted, or missing a key. A strong Level 3 Operator does not stop at creating backups. It also provides a tested restore path, and ideally verifies backups automatically by restoring them into a throwaway copy and checking the result.

Protecting the application is not enough if you cannot see how it behaves. Level 4 is about visibility: turning the Operator into a source of understanding, not just action.

What Level 4 means

At Level 4, the Operator provides rich metrics, alerts, log processing, and workload analysis. It does not merely run the application; it measures it and explains what it sees. The goal is to give humans and, later, automated systems enough information to make good decisions.

The four kinds of insight

Good insight is application-aware

Kubernetes already shows generic numbers like CPU and memory. Those are not enough. A database can have perfectly normal CPU while its replicas silently fall hours behind. Only an Operator that understands the application knows which signals matter. Level 4 Operators export application-specific metrics in a standard format, ship ready-made dashboards and alert rules, and expose the health of each member in the custom resource status.

flowchart LR
  APP["Managed application"] --> EXP["Operator-provided metrics and health checks"]
  EXP --> MON["Monitoring system"]
  MON --> DASH["Dashboards for humans"]
  MON --> ALERT["Alerts to on-call team"]
  EXP --> STAT["Custom resource status and events"]
  STAT --> HUMAN["Engineers using kubectl or consoles"]
    

Insight about the Operator itself

A mature Operator also tells you how it is doing. How many reconcile loops ran, how many failed, how long they took, how many objects are waiting in the queue? Without these numbers, you cannot tell whether a stuck application is the application’s fault or the Operator’s. We return to this in the chapter on observing the Operator.

The top of the ladder is the most exciting and the easiest to get wrong. At Level 5, the Operator does not just show the problem; it acts on it.

What Level 5 means

At Level 5, the Operator performs horizontal and vertical scaling, automatic configuration tuning, abnormality detection, and scheduling tuning. It uses the insights gathered at Level 4 to adjust the application without waiting for a human. The aim is a system that runs itself, with people setting goals and boundaries rather than pushing buttons.

The auto-pilot abilities

The feedback loop

Auto pilot works through a loop with four steps: observe, decide, act, and check the result. The Operator measures the system, compares the measurements with goals such as “keep response time under 50 milliseconds”, decides on an adjustment, applies it carefully, and then measures again to confirm that it helped.

flowchart LR
  O["Observe: metrics and health"] --> D["Decide: compare with goals and limits"]
  D --> A["Act: scale, tune, or heal in small steps"]
  A --> C["Check: did the change help?"]
  C --> O
    

Why Level 5 is dangerous when rushed

An automated system can make mistakes much faster than a human. A badly tuned autoscaler can add machines in a loop and run up a huge bill. An overeager tuning rule can set a memory value that crashes the database. Two automatic systems, such as the Operator and a cluster autoscaler, can fight each other. For these reasons, Level 5 abilities should always come with guard rails: minimum and maximum limits, slow and gradual changes, a way to pause automation, and clear logs of every decision.

The tool you pick to write an Operator quietly decides how high it can climb. Understanding this saves teams from painful rewrites later.

The three classic paths

The Operator SDK, part of the Operator Framework, lets you create an Operator in three main ways. Each trades ease against power.

Why Helm tops out early

A Helm chart is a template that renders Kubernetes objects once. It has no built-in way to watch a running database, decide that a replica fell behind, take a backup, or coordinate a careful sequence. A Helm-based Operator can reapply the chart when settings change, but it cannot reason about the live system. That is why such Operators fit Levels 1 and 2 and rarely go further.

Other tools you will meet

How to choose

The custom resource is the front door of your Operator. Once people start using it, changing it is expensive, so a little careful design here pays off for years.

Spec and status

Almost every custom resource has two main sections. The spec is what the user writes: the desired outcome. The status is what the Operator writes: the observed reality. Keeping them separate is a golden rule. Users never edit status, and the Operator never edits spec. This division keeps responsibilities clear and prevents the two sides from overwriting each other.

Describe intent, not steps

A good spec says what the user wants, not how to do it. “Three replicas, version 15, daily backups at two in the morning” is intent. “Run these four commands in this order” is a script. The Operator is the one who knows the steps. A spec that exposes too many internal knobs becomes hard to evolve and easy to misuse.

Status conditions

Instead of a single word, mature Operators report a list of conditions, each describing one aspect of health, such as “Ready”, “BackupHealthy”, or “UpgradeInProgress”. Each condition has a true or false value, a short reason, a human-readable message, and a timestamp of the last change. Tools and dashboards can then show a precise picture, and automation can wait for a particular condition to become true.

Validation

CRDs can carry a schema that checks every incoming object. Simple rules, such as numbers within a range or text matching a pattern, can be enforced by the cluster itself before the Operator even sees the object. More complex checks can be done by a validating webhook, a small service the API server asks before accepting a change. Early, clear validation is far kinder to users than a mysterious failure hours later.

Versioning the API

APIs change. Fields are added, renamed, or removed. Kubernetes lets a CRD serve several versions at once, such as v1alpha1, v1beta1, and v1, and use a conversion webhook to translate objects between them. The names carry meaning: alpha means early and subject to change, beta means mostly stable, and v1 means users can rely on it. Mature Operators promise not to break existing objects when they release new versions.

flowchart LR
  A["v1alpha1: experimental, may break"] --> B["v1beta1: mostly stable, tested widely"]
  B --> C["v1: stable, compatibility promised"]
  C -.-> D["Conversion webhook translates between served versions"]
    

A large part of the difference between a toy Operator and a trustworthy one is how carefully the reconcile loop is written. These habits show up at every level of the maturity model.

Habit one: be idempotent

Every pass of the loop must be safe to run again. Instead of “create a volume”, write “make sure a volume exists”. If it already exists, do nothing. If a previous run stopped halfway, the next run finishes the job. This single habit makes crashes, restarts, and retries harmless.

Habit two: take small steps

Do a little, record progress in the status, and return. Long operations that block the loop for minutes make the Operator slow to react to other objects. Instead, start the operation, return, and come back to check on it. Operators that move one step at a time are easier to debug, easier to pause, and safer during upgrades.

Habit three: own what you create

Set an owner reference on every object the Operator creates, pointing back to the custom resource. When the custom resource is deleted, Kubernetes automatically removes everything it owns. Without owner references, deleted applications leave orphaned storage, services, and settings behind.

Habit four: clean up with finalizers

Some things cannot be cleaned up by Kubernetes alone, such as a cloud disk, a DNS record, or a backup in external storage. A finalizer is a label on the object that tells Kubernetes: “do not fully delete this until I say so”. When a user deletes the custom resource, the Operator sees the deletion request, performs the external cleanup, removes its finalizer, and only then does the object disappear. If the Operator forgets to remove the finalizer, the object hangs in a deleting state forever, so this logic must be well tested.

Habit five: handle conflicts and retries

Several actors may change the same object at once: the user, the Operator, other controllers. Kubernetes protects against lost updates by rejecting a write that is based on an outdated version, called a conflict. A well-written Operator simply re-reads and tries again. Failures should also be retried with growing delays, called exponential backoff, so that a broken dependency is not hammered with requests.

Habit six: report honestly

Write real status after each meaningful step, including failures and their reasons. Emit Kubernetes events for notable actions. An Operator that fails silently looks fine right up until the moment it is not.

An Operator that lives only on its author’s laptop helps nobody. Level 2 maturity applies to the Operator too: it must be installable, upgradable, and removable in a clean way.

The Operator Lifecycle Manager

The Operator Lifecycle Manager, usually called OLM, is a component of the Operator Framework that installs Operators, keeps them updated, and manages their permissions. Think of it as an app store and update service for Operators inside the cluster. It understands which versions can replace which, and it can pause automatic updates when you want to approve them manually.

The key objects

Update channels and approval

Operators publish versions into channels, such as a stable channel for tested releases and a fast channel for newer ones. A subscription chooses a channel and an approval mode: automatic, where OLM applies updates as they appear, or manual, where an administrator reviews each install plan first. Production clusters often choose manual approval for critical Operators so that upgrades happen at planned times.

flowchart LR
  CAT["Catalog of Operator versions"] --> SUB["Subscription: chosen channel and approval mode"]
  SUB --> PLAN["Install plan: steps OLM will take"]
  PLAN --> APPR{"Manual approval needed?"}
  APPR -- "Yes" --> ADMIN["Administrator reviews and approves"]
  APPR -- "No" --> RUN["OLM installs or upgrades the Operator"]
  ADMIN --> RUN
    

Other packaging routes

OLM is not the only way. Many Operators are also installed with Helm charts or plain manifests, which is simple and works on any cluster. Some managed platforms provide their own catalogs of add-ons. Whichever route you pick, the same questions apply: how are CRDs upgraded, how are permissions reviewed, how do you roll back, and how do you remove the Operator without destroying the applications it manages?

Removing an Operator safely

Deleting an Operator should not accidentally delete your data. If the custom resources are removed along with the CRD, the Operator’s finalizers and owner references may cascade into deleting databases and storage. Mature Operators and good runbooks make the safe order clear: first decide what happens to the managed applications, then remove the Operator, and only at the very end consider removing the CRDs.

An Operator can create pods, read secrets, and delete storage. That power is exactly why it must be built and installed with care.

Why Operators are attractive targets

Operators often run with broad permissions, sometimes across the entire cluster, so they can manage applications in many namespaces. If an attacker compromises an Operator, they may gain the ability to read secrets, start pods, or modify any application it manages. The Operator’s identity is therefore a high-value asset.

Principles for safe Operators

Protect what the Operator creates

An Operator also decides the security settings of the pods it builds. A careless Operator may create pods that run as root, mount sensitive paths, or expose open network ports. A mature Operator applies safe defaults, supports network policies, uses encryption between members where the application allows, and keeps generated passwords in secrets with tight access.

The higher an Operator climbs the maturity ladder, the more it can damage when it is wrong. Testing is what lets you climb safely.

Why Operators are hard to test

An Operator interacts with a live cluster, with real storage, and often with a stateful application that has its own quirks. Failures are timing-dependent: a bug may only appear if a node dies during an upgrade. Simple tests that check one function at a time are not enough. A good test strategy uses several layers, each catching a different kind of mistake.

The testing pyramid for Operators

Test the level you claim

A very practical idea is to write tests that match the level you advertise. If you claim Level 2, you need automated upgrade tests across every supported path. If you claim Level 3, you need tests that take a backup, destroy the application, and restore it, checking that the data matches. Level 4 needs tests proving that metrics and alerts really fire. Level 5 needs tests showing that scaling and tuning stay within their guard rails under changing load.

Level 4 is usually described in terms of the application. But the Operator is a running program too, and it deserves the same visibility.

Why the Operator needs its own monitoring

When an application is unhealthy, the cause might be the application, the cluster, or the Operator itself. If the Operator is stuck, crash-looping, or silently failing to reconcile, nothing gets repaired, and no alarm rings because the application’s own metrics may still look normal for a while. Watching the Operator closes this blind spot.

The signals that matter

Logs that tell a story

Operator logs should be structured, so that tools can filter them by object name and namespace. Each reconcile pass should log which object it handled and what decision it made, without printing secrets. When something goes wrong at night, the on-call engineer should be able to search the logs for a single application name and read a clear, ordered story of what the Operator did to it.

Events for humans

Kubernetes events attached to the custom resource are the friendliest form of insight. “Created backup job”, “Promoting replica two to leader”, and “Upgrade paused: member not healthy” show up when users describe the object. They turn the Operator from a black box into a narrator.

flowchart TD
  OP["Operator pod"] --> M["Metrics: reconcile counts, durations, queue depth"]
  OP --> L["Structured logs per object"]
  OP --> E["Events on each custom resource"]
  OP --> S["Status conditions on each custom resource"]
  M --> DASH["Operator health dashboard"]
  M --> AL["Alerts for stuck or failing reconciles"]
  L --> SEARCH["Searchable log platform"]
  E --> USERS["Users running describe commands"]
  S --> TOOLS["Dashboards and automation waiting on conditions"]
    

The more an Operator can do, the more carefully it must be fenced in. Understanding common failure modes helps you demand the right safety features.

The classic ways Operators fail

Safety features worth demanding

Budgets for disruption

Kubernetes provides an object called a PodDisruptionBudget that limits how many members of an application may be unavailable at the same time during voluntary actions such as node maintenance. A mature Operator creates and maintains one for each application it manages, so that routine cluster operations cannot take down too many members together.

To make the levels concrete, let us follow one imaginary Operator for a replicated database as it grows from a simple installer into an auto-pilot system. The details are illustrative, but the pattern is realistic.

Version one: Level 1

The team writes a custom resource called a “DatabaseCluster”. The user states the version, the number of replicas, and the storage size. The Operator creates the pods, the storage claims, a service for clients, and a configuration file. It marks the first replica as primary and the rest as followers. It works, and installs now take minutes instead of a day. But when the primary pod’s machine dies, the cluster stays without a primary until a human acts.

Version two: Level 2

The team adds careful upgrade logic. The Operator updates followers first, waits for each to catch up, switches the primary role to an upgraded follower, and updates the old primary last. It refuses to upgrade across unsupported versions and pauses if any member is unhealthy. Upgrade night becomes a calm event: the engineer changes one field and watches the status.

Version three: Level 3

Next comes protection. The Operator takes scheduled backups to object storage, records them, and offers a restore field that creates a new cluster from a chosen backup or a point in time. Failure handling arrives: if the primary is lost, the Operator checks that a safe majority is healthy, promotes the most up-to-date follower, and creates a replacement member. The team runs a drill by deleting the primary pod, then the whole node, and finally restoring to a fresh cluster, and measures how long each takes.

Version four: Level 4

The team adds visibility. A small exporter reports replication lag, connection counts, disk growth, and backup age. The Operator ships dashboards and alert rules, writes conditions like “ReplicaLagging” into the status, and emits events for every promotion and backup. Now on-call engineers see trouble coming, such as a disk predicted to fill in three days, instead of only reacting to outages.

Version five: Level 5

Finally, the team uses the data. The Operator can add read replicas when connection load stays high, expand storage before it fills, and adjust memory settings within safe bounds. Every automatic change obeys minimum and maximum limits, is rate limited, and is logged with its reason. A pause annotation lets humans freeze automation during sensitive events.

flowchart LR
  V1["v1: install and configure"] --> V2["v2: rolling upgrades"]
  V2 --> V3["v3: backups, restore, failover"]
  V3 --> V4["v4: metrics, alerts, dashboards"]
  V4 --> V5["v5: guarded scaling and tuning"]
    

The best way to feel the maturity model is to look at real Operators. The table below describes well-known examples at a general level. Treat the capability notes as approximate, because projects add features over time and declare their own levels.

What the examples teach

How to evaluate a candidate Operator

The five levels measure one Operator. But a company adopting Operators goes through its own growth, and that journey has stages too. Understanding both keeps expectations realistic.

Why organizational maturity matters

A Level 5 Operator in the hands of a team that has never run a stateful application on Kubernetes can still cause trouble. The team may not know how to read its status, rehearse its restores, or tell when automation is misbehaving. Platform maturity is the ability of people and processes to use the tool well. The best results come when Operator capability and team capability grow together.

Four stages of adoption

Matching levels to stages

The most important decision about Operators is sometimes whether to use one. Writing your own is a long-term commitment, and the best Operator is often the one you did not have to build.

Three honest options

A decision flow

flowchart TD
  S["You need to run a stateful application"] --> M{"Is a managed cloud service acceptable for cost, control, and compliance?"}
  M -- "Yes" --> USEM["Use the managed service and avoid operating it yourself"]
  M -- "No" --> E{"Does a well-maintained Operator at a suitable level already exist?"}
  E -- "Yes" --> ADOPT["Adopt it, test it, and contribute fixes if needed"]
  E -- "No" --> B{"Is the application important enough and your team strong enough to maintain an Operator?"}
  B -- "Yes" --> BUILD["Build an Operator, planning tests and safety from day one"]
  B -- "No" --> SIMPLE["Use simpler tooling such as charts and runbooks"]
    

When writing your own makes sense

Operators for your own platform

Not every Operator manages someone else’s software. Many companies write Operators for their own internal concepts: a “Team” object that creates namespaces, quotas, and access rules; a “Service” object that sets up deployments, monitoring, and alerts together. These are often simple Level 1 or 2 Operators, and they can be wonderfully valuable. They turn the company’s standards into a few lines of declared intent and make the right way the easy way.

Many readers run Kubernetes on Amazon EKS. This chapter links the maturity ideas to what you will meet on AWS.

Controllers for AWS services

The Operator pattern is not limited to software running inside the cluster. AWS Controllers for Kubernetes, often called ACK, lets you manage AWS services such as storage buckets, queues, and databases through custom resources. You create a Kubernetes object, and a controller creates and maintains the matching cloud resource. Other projects, such as Crossplane, take a similar approach with a wider range of providers. In maturity terms, these tools often focus on the first levels: declarative creation, configuration, and drift correction, while the cloud service itself handles backups and scaling.

Karpenter as an auto-pilot example

Karpenter, an open-source node provisioning project started by AWS, watches for pods that cannot be scheduled and decides which machines to launch, then removes machines that are no longer needed. It is a good everyday illustration of a Level 5-style loop: it observes demand, decides, acts, and checks. It also shows why guard rails such as limits on total capacity are essential.

Choosing between self-run Operators and managed services

Practical AWS tips for Operators

Here is a simple checklist you can use to judge any Operator, yours or someone else’s. It turns the five levels into questions you can answer with evidence instead of impressions.

How to use the checklist

For each level, answer every question with yes or no, and ask to see it work rather than reading a claim. An Operator earns a level only when all the questions for that level and the ones below it are answered yes.

Beyond the five levels: the extra score

Because the model ignores quality, add a second, simple scorecard for the things it leaves out. Give each a rating from weak to strong.

flowchart LR
  A["Capability level: what it can do"] --> Z["Overall confidence"]
  B["Quality and testing: how well it does it"] --> Z
  C["Security: how safely it does it"] --> Z
  D["Community: how long it will keep doing it"] --> Z
    

If you are building an Operator, the path upward is long. This roadmap suggests an order of work that keeps risk under control at every step.

Habits that keep the roadmap healthy

Newcomers often ask whether Operators replace the tools they already use. They do not. Each tool answers a different question, and the best platforms combine them.

Four tools, four different jobs

How they work together

A very common and healthy design uses several of these at once. The infrastructure tool creates the cluster and its cloud resources. A GitOps tool keeps the Operator itself installed and up to date, usually by deploying a Helm chart or a set of manifests from Git. Developers then commit small custom resources, such as a database request, to Git. The GitOps tool applies them, and the Operator takes over and does the real operational work. Git remains the source of truth for intent, while the Operator holds the source of expertise.

flowchart TD
  TF["Infrastructure tool creates cluster and cloud resources"] --> K["Kubernetes cluster"]
  GIT["Git repository holds Operator install and custom resources"] --> GO["GitOps tool syncs Git to the cluster"]
  GO --> K
  K --> OP["Operator reads each custom resource"]
  OP --> APP["Running application: install, upgrade, backup, heal"]
  APP -.-> OBS["Metrics and status flow back to dashboards"]
    

A common point of friction

One practical problem appears when a GitOps tool and an Operator both want to control the same field. For example, the Operator may update the status or a generated field, while the GitOps tool sees the difference from Git and tries to revert it. The result is a tug of war. The usual solution is to configure the GitOps tool to ignore fields that the Operator owns, and to keep only the user-facing spec in Git. Clear ownership of each field removes the conflict.

Operators versus plain scripts and scheduled jobs

Another comparison is with ordinary scripts run on a schedule. A scheduled job can take a nightly backup, and for a small system that may be entirely enough. What a script lacks is continuous awareness. It does not notice a failure at two in the afternoon, does not coordinate with an upgrade in progress, and does not report its progress in a form the rest of the platform can read. An Operator turns the same knowledge into a long-lived, cluster-native, observable process. If your needs are small and rare, a script may be the wiser and cheaper choice. As the number of applications and the cost of mistakes grow, the Operator starts to pay for itself.

The same errors appear again and again in Operator projects and in teams adopting them. Knowing them in advance can save months.

These are the questions people most often ask when they first meet the maturity model.