Skip to content

SYSTEM Cited by 1 source

Redpanda Operator

Redpanda Operator is Redpanda's Kubernetes Operator — the production-grade deployment path for Redpanda clusters on Kubernetes, positioned as the default recommendation over the Redpanda Helm chart. The operator manages cluster lifecycle via CRDs and provides five capabilities Helm cannot:

  1. Managed upgrade and rollback — safe rolling upgrades with reconciliation, vs Helm's manual-intervention rollback.
  2. Dynamic configuration — real-time config changes via CRDs, vs Helm's redeploy-to-apply-values flow.
  3. Advanced health checks and metrics — application-specific signals on top of generic Kubernetes probes.
  4. Lifecycle automation — scaling, failover, resource reconciliation, cleanup.
  5. Multi-tenancy management — one declarative CRD instance per cluster, vs separate Helm releases.

Evolution

The operator has gone through three phases ending in a 2025 consolidation:

Phase 1 (pre-2024): Two separate operators

Redpanda historically maintained two Kubernetes operators:

  • An internal Cloud operator managing Redpanda Cloud deployments.
  • A customer-facing operator for Self-Managed deployments.

The two were forked because the internal team and customers had divergent requirements. Over time, duplicated reconciliation logic became a cost.

Phase 2: Customer operator bundled FluxCD

To accelerate the customer operator's development, Redpanda bundled FluxCD — a GitOps controller similar to ArgoCD — and had the operator wrap the Redpanda Helm chart internally via FluxCD. This shipped the operator faster and kept operator-based and Helm-based deployments close.

The bundling turned into a anti-pattern:

  • Made the operator diverge from Kubernetes ecosystem norms.
  • Conflicted with customers already running their own FluxCD.
  • Coupled operator to bundled-FluxCD version and Helm-chart release.
  • Made merging the internal and customer operators harder.

Phase 3 (2025-): Unification + FluxCD removal

Three branches rolled the unification across 2025:

Branch FluxCD Redpanda core dep Notes
v2.3.x optional (spec.chartRef.useFlux) Helm chart Opt-out available
v2.4.x disabled by default (Jan 2025) Helm chart Same toggle
v25.1.x removed removed Version-aligned, beta

The v2.4.x → v25.1.x version jump is deliberate — the operator adopts a version-aligned compatibility scheme where the operator/chart version number matches the Redpanda core version, retiring the prior compatibility matrix. Each operator/chart version is compatible with the Redpanda version immediately above and below it (±1 minor window).

(Source: sources/2025-05-06-redpanda-a-guide-to-redpanda-on-kubernetes)

Deployment-shape limitation

Per the 2025-02-11 stretch-cluster post, "Self-Managed on K8s currently supports only multi-AZ deployments in all the cloud providers" — multi-region stretch clusters are not supported on Kubernetes; they require VMs, bare metal, cloud compute, or Redpanda Cloud Dedicated / BYOC. The 2025-05-06 deployment guide does not revisit this substrate constraint.

Last updated · 470 distilled / 1,213 read