Skip to main content
Helm-based operators solve a common operational question: what if your application is already packaged as a Helm chart, but you want a Kubernetes-native API (CRDs) to manage it instead of running Helm commands manually?
The image is a slide that discusses already having an "Application Helm Chart" but expressing a need for an API. It includes a document icon labeled "HELM" with a Helm logo.
Conceptually, a chart stays useful: the operator simply runs a control loop that renders and applies the chart on behalf of Kubernetes users. Think of a Helm chart as a recipe book. With plain Helm, a human or CI pipeline runs the recipe:
A Helm-based operator instead puts that recipe behind a Kubernetes API. A user creates a custom resource (CR), and the operator continuously reconciles that CR into the corresponding Helm release:
Plain Helm requires someone or some pipeline to run install/upgrade/uninstall at the right time. A Helm-based operator watches the cluster and reacts automatically: when a CR is created, updated, or deleted, the operator performs the corresponding Helm workflow.
The image compares "Plain Helm" and "Helm-Based Operator," highlighting that Plain Helm involves manual command execution by a person or pipeline, while Helm-Based Operator continuously watches the cluster and reacts through Helm workflows when changes occur.
This pattern is especially valuable for teams that already trust a chart: the chart remains the canonical source of manifests while the operator exposes a Kubernetes-native API for create/update/delete operations.
The image explains the benefits of wrapping a chart, highlighting that it is useful for teams that already trust a chart and that the chart remains the source of Kubernetes manifests.
The key technical bridge is the mapping between the custom resource spec and the chart values. A chart typically exposes settings like image, replica count, service type, and port. In a Helm-based operator, these chart values become fields on the custom resource spec:
When a field changes, the next reconcile renders the chart with updated values and applies the resulting manifests to the cluster.
The image depicts a workflow diagram showing a user interacting with a Kubernetes API, specifically with Helm actions. It describes the process of a user creating, updating, or deleting a custom resource that is managed by an operator.
Operator SDK includes a Helm plugin that scaffolds this style of project. Instead of writing a custom Go reconcile loop, the project contains chart content and a watches configuration to link a Kubernetes group/version/kind to a specific Helm chart. Initialize a Helm-based operator with Operator SDK:
Then map the custom resource to the chart in watches.yaml:
In plain language: when the controller sees objects of kind MyApp in group example.com, manage the helm-charts/myapp chart for them. Under the hood, the operator is still a controller: it runs a manager, watches Kubernetes events, and reconciles desired state against actual state. The difference is where reconciliation logic comes from. A Go-based operator runs custom code you author; a Helm-based operator uses a generic Helm reconciler that converts CR values into a Helm release. That trade-off drives the decision to choose one approach over the other. A Helm-based operator is a good fit when the workload primarily concerns install/upgrade/delete of Kubernetes objects already expressed by the chart—typical examples include web applications, internal services, and other packaged workloads where the chart is the source of truth.
The image is a flowchart illustrating the use of Helm for managing Kubernetes objects to install, upgrade, or delete web applications and internal services.
However, a Helm-based operator is not a good fit when the controller must implement application-specific judgment. For example, if you must call external APIs, coordinate backups, wait for database migrations, compute detailed status from live application behavior, or run multi-step recovery workflows, the generic Helm reconciler lacks the necessary flexibility.
The image lists scenarios where something is "Not a Good Fit" and needs custom logic, such as calling an external API, coordinating a backup, waiting for a database migration, computing detailed status from live application behavior, and running a multi-step recovery workflow.
In those cases, prefer a Go-based operator so you have a place to write application-specific reconciliation logic. Treat a Helm-based operator as an on-ramp—not a universal shortcut. It brings an existing chart into the operator ecosystem and exposes install/upgrade/delete via Kubernetes resources, but it does not replace custom controller development when your lifecycle requires real application reasoning.
Use a Helm-based operator when your chart already encodes most deployment semantics and you want a Kubernetes-native API. Choose a Go-based operator when you need custom lifecycle logic or deep runtime reasoning.
Operator SDK scaffolds a Helm-based operator with this layout on disk: a Helm chart, a watches.yaml mapping a CRD type to that chart, and a control loop that delegates reconciliation to the Helm reconciler. This pattern makes it fast to expose existing Helm charts through Kubernetes APIs while keeping the chart as the source of manifest truth. Links and references

Watch Video