When to build an Operator vs a Helm chart
tool selection judgment.
charts handle install-time templating; operators add continuous day-two logic like failover, backups, and scaling for stateful apps.
building an operator for a stateless app a chart would handle.
WHAT THIS TESTS Whether you can weigh operational complexity against tooling and avoid over-engineering, choosing operators only when ongoing automated logic is genuinely required.
A GOOD ANSWER COVERS Helm charts and plain manifests are fundamentally about install-time and upgrade-time templating: render parameterized YAML and apply it. They are ideal when an application is straightforward to deploy and run, especially stateless services, where once the resources exist Kubernetes' built-in controllers handle the rest. You reach for an operator when the application needs continuous, domain-specific operational logic that cannot be expressed as static manifests. Signs include complex stateful systems that require automated failover, leader election, backup and restore, point-in-time recovery, ordered and version-aware upgrades, schema or data migrations, scaling that involves data rebalancing or resharding, and reacting to runtime conditions over time. An operator encodes the knowledge a human SRE would apply for day-two operations and runs it continuously via reconciliation. The cost is real: building and maintaining a controller is far more effort than a chart, so use the simplest tool that meets the need, and many teams even ship an operator installed via a Helm chart.
COMMON WRONG ANSWERS Building an operator for a simple stateless app that a chart covers, claiming operators replace Helm entirely, or thinking charts can perform ongoing runtime automation like failover.
LIKELY FOLLOW-UPS Can you use both together? What day-two tasks justify an operator? What is the maintenance cost of an operator?
ONE CONCRETE EXAMPLE A stateless REST API deploys perfectly with a Helm chart: templated Deployment, Service, and HPA, nothing more needed. A highly available PostgreSQL cluster, however, needs automated primary failover, streaming replica setup, scheduled backups, and careful major-version upgrades; that ongoing logic is exactly what a Postgres operator provides and what a static chart cannot.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.