Redpanda in Kubernetes

Kubernetes is a container orchestration tool that helps you manage Redpanda deployments using declarative configuration files called manifests. Kubernetes provides a standardized way of achieving the following:

  • High availability

  • Disaster recovery

  • Scalability

Deployment tools

To deploy Redpanda in Kubernetes, you can choose to use Helm for its simplicity or the Redpanda Operator to leverage custom resource definitions (CRDs) for a more GitOps-friendly deployment process. The Redpanda Operator is the recommended option for production deployments.

Feature Helm Redpanda Operator

Version management

Supported through Helm, enabling updates and rollbacks.

Managed through Redpanda custom resources, with optional integration with Flux for GitOps workflows.

Multi-tenant Kubernetes clusters

Supported. Helm allows deployment of multiple independent Redpanda clusters by defining different Helm release names.

Supported. The Redpanda Operator provides a declarative approach for managing multi-tenant clusters using the RedpandaList custom resource.

Dependency and configuration management

Managed through the Redpanda Helm chart.

Configurations are defined in custom resources.
If you are already using the Redpanda Helm chart and want to migrate to the latest Redpanda Operator for better lifecycle management, see Migrate from the Redpanda Helm chart.

Helm

Helm is a package manager for Kubernetes that simplifies defining, installing, and upgrading Kubernetes applications. Helm uses charts, a collection of files describing Kubernetes resources, to deploy applications in a Kubernetes cluster.

The Redpanda Helm chart provides all the manifest files required to deploy Redpanda in Kubernetes, including:

  • A StatefulSet to manage Redpanda brokers

  • A Headless ClusterIP Service for internal communication with the Redpanda cluster

  • A NodePort Service for external communication with the Redpanda cluster

Redpanda Operator

The Redpanda Operator provides two deployment modes controlled by the useFlux flag. The modes differ in how reconciliation is handled.

The useFlux: false configuration is in beta. It is not supported for production deployments. Beta features are available for users to test and provide feedback.

  • Flux-managed mode (useFlux: true): When useFlux is set to true (default), the Redpanda Operator delegates reconciliation to Flux controllers. The workflow is as follows:

    1. The Redpanda Operator defines the necessary CRDs for Redpanda. A Redpanda resource represents a Redpanda cluster, configured through the Redpanda Helm chart values.

    2. When the Redpanda Operator detects changes to Redpanda resources, it triggers Flux to reconcile the corresponding HelmRelease resource.

    3. Flux uses the HelmRelease resource to manage the lifecycle of the Redpanda Helm chart, applying updates as needed.

  • Redpanda-managed mode (useFlux: false): When useFlux is set to false, the Redpanda Operator manages and reconciles Redpanda resources directly, without involving Flux. This mode works as follows:

    1. The Redpanda Operator creates both HelmRelease and HelmRepository resources but suspends them, keeping Flux inactive.

      Although these resources are created in a suspended state, the operator still requires the Flux CRDs to be installed.

    2. The operator directly reconciles Redpanda resources, performing tasks such as installations, updates, and cleanup, normally handled by Flux.

    3. If useFlux is later re-enabled, the operator unsuspends the Flux resources, and Flux resumes lifecycle management.

Example configuration to specify the deployment mode in Redpanda’s custom resource:

apiVersion: cluster.redpanda.com/v1alpha2
kind: Redpanda
metadata:
  name: redpanda
spec:
  chartRef:
    useFlux: true  # or false, depending on your desired deployment mode
CRDs for the Redpanda Operator include Flux CRDs. Flux manages the Redpanda Helm chart through the HelmRelease resource.

Kubernetes deployment environments

You can run Redpanda on managed Kubernetes services as well as in bare-metal environments. Managed Kubernetes services offer simpler deployment and maintenance, while bare-metal environments provide complete control and cost efficiencies.

Managed Kubernetes

Managed Kubernetes services, such as Google Kubernetes Engine (GKE) and Amazon Elastic Kubernetes Service (EKS), handle core components of a Kubernetes cluster, offering benefits such as:

  • Ease of deployment: Pre-configured instances join your Kubernetes cluster automatically.

  • Control plane maintenance: The provider maintains the control plane, ensuring security and reliability.

  • Health monitoring and repairs: The provider monitors master nodes and repairs them as needed.

You remain responsible for deploying and maintaining Redpanda instances on worker nodes.

Bare-metal Kubernetes environments

Bare-metal Kubernetes environments give you complete control over both the control plane and the worker nodes, which can be advantageous when you want the following:

  • Complete control: Bare-metal Kubernetes offers control over every aspect of deployment, suited for highly customized environments.

  • Custom configurations: You have granular control to fine-tune the Kubernetes setup.

  • Cost efficiency: Owning and operating your hardware may be more economical over time.

Documentation conventions

This documentation follows conventions to help users easily identify Kubernetes resource types and Helm values:

  • Resource names: Kubernetes resource names, such as Service or PersistentVolume, are capitalized and in Pascal case to match the manifest files.

  • Helm values: Helm values, like storage.persistentVolume.enabled, are displayed in monospace font.

Next steps

Whether you’re deploying locally or in the cloud, choose one of the following guides to get started:

Or, explore our production workflow to learn about requirements and best practices.

Suggested reading

Suggested labs

Search all labs