Deploy Redpanda on Kubernetes with Helm Operator (2026)

Redpanda on Kubernetes with Helm Operator is less about deploying an application and more about controlling a declarative system of stateful services using Kubernetes’ own API.

Let’s see this in action. Imagine you have a Kubernetes cluster and you want to deploy Redpanda. Instead of manually creating Deployments, StatefulSets, Services, and all the other YAML for Redpanda, you use the Helm Operator.

First, you need to install the Helm Operator itself into your cluster. This is typically done by applying a manifest:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: redpanda
  namespace: default
spec:
  chart:
    spec:
      chart: redpanda
      version: ">= 0.1.0" # Use a specific version for reproducibility
      sourceRef:
        kind: HelmRepository
        name: redpanda
        namespace: fluxcd # Assuming fluxcd namespace for Helm repositories
  interval: 5m
  install:
    createNamespace: true # Create namespace if it doesn't exist
  releaseName: redpanda
  targetNamespace: default # Namespace where Redpanda will be deployed

With this HelmRelease resource, you’re telling the Helm Operator: "Go find the redpanda chart in the redpanda Helm repository, and deploy it with these specific configurations into the default namespace. Make sure it’s updated every 5 minutes."

The Helm Operator then takes over. It interacts with the Kubernetes API to:

1. Fetch the Chart: It downloads the redpanda chart from the specified Helm repository.
2. Render the Manifests: It uses the values.yaml (either default or overridden) to render all the Kubernetes resources (StatefulSets, Services, ConfigMaps, etc.) that constitute a Redpanda deployment.
3. Apply to Kubernetes: It applies these rendered manifests to your Kubernetes cluster. If a HelmRelease is created for the first time, it performs an helm install. If the HelmRelease is updated (e.g., you change a value in spec.values), it performs an helm upgrade.
4. Monitor: It continuously monitors the deployed resources and compares them against the desired state defined in the HelmRelease. If drift is detected or the desired state changes, it reconciles.

This HelmRelease object is your single source of truth. You don’t touch individual Kubernetes manifests for Redpanda anymore. All your Redpanda configuration, from the number of brokers to TLS settings, lives within the spec.values block of this HelmRelease.

For example, to configure Redpanda to use 3 replicas and enable TLS, you’d modify the HelmRelease:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: redpanda
  namespace: default
spec:
  chart:
    spec:
      chart: redpanda
      version: ">= 0.1.0"
      sourceRef:
        kind: HelmRepository
        name: redpanda
        namespace: fluxcd
  interval: 5m
  install:
    createNamespace: true
  releaseName: redpanda
  targetNamespace: default
  values:
    replicas: 3
    tls:
      enabled: true
      # ... other TLS specific configurations

The Helm Operator will see this change and orchestrate the necessary updates to the underlying Redpanda StatefulSet and related resources to achieve 3 replicas and enable TLS.

The problem this solves is the operational complexity of managing stateful applications like Redpanda on Kubernetes. Without an operator, you’d be dealing with manual scaling, configuration updates, and ensuring all the pieces (brokers, ZooKeeper/alternatives, clients) are correctly deployed and interconnected. The Helm Operator, by leveraging Helm charts, abstracts this complexity. It allows you to manage Redpanda as a declarative Kubernetes resource.

The one thing most people don’t know is that the Helm Operator doesn’t just "run Helm commands." It actively manages the lifecycle of the Helm release as a Kubernetes resource. When you update the HelmRelease object, the operator doesn’t just re-run helm upgrade; it compares the rendered Kubernetes manifests from the previous state to the new state and applies the differences atomically, leveraging Kubernetes’ own reconciliation loops. This means it can handle complex upgrades and rollbacks more gracefully than a simple helm upgrade command executed manually.

The next concept you’ll run into is managing persistent storage for Redpanda, which involves understanding Kubernetes PersistentVolumes and how Redpanda’s chart configures them.