A quick tour of Redpanda on Kubernetes

Redpanda on Kubernetes (K8s) combines the powerful capabilities of a modern, high-performance data streaming engine with the orchestration advantages of Kubernetes. You can easily deploy Redpanda on Kubernetes in minutes, either locally or in your cloud of choice (Amazon, Google, Azure). 

Self-Managed users deploying Redpanda clusters in Kubernetes have two flexible options when installing and managing their deployments: Helm chart or Redpanda Operator. 

In a nutshell, Helm is an easy way to install and upgrade Redpanda, but it’s limited when managing complex, stateful workloads at scale. The Redpanda Operator, on the other hand, is designed for production-grade deployments and enables enhanced upgrade management, dynamic configuration, and lifecycle automation. Currently, we have two Redpanda Operators: one for us and one for customers — but it's about to get a whole lot simpler.

In this post, we walk you through the evolution of Redpanda on Kubernetes, the status of our new unified Redpanda Operator, how to choose the right deployment option, and then wrap up with a few tips and resources on how to get started.

Rewind: Redpanda on Kubernetes

Redpanda wasn’t always the complete multi-modal system available wherever and however you deploy your data-intensive apps. A few years ago, Redpanda was simply the single binary that replaced Apache Kafka^® — nothing about our cloud offerings, Redpanda Connect, Redpanda Console, Kubernetes deployment options, or any other cool features we have today. 

Our first offering around Redpanda on Kubernetes was an early version of our Helm chart. But we needed more than just a Helm chart to manage such a large deployment of Redpanda clusters for all our customers. That’s when we developed our own Kubernetes operator called Redpanda Operator. 

Initially, this operator was built to fit the exact needs of our team while managing Redpanda Cloud. Eventually, we also needed an operator for customers to use, and since the needs for our cloud team differed from what our customers wanted in an operator, we decided on the following:

1. Create a new customer-focused Redpanda Operator, separate from the internal Cloud operator.
2. Merge the two, adopting a single operator across Redpanda for both Cloud and customers

Here’s a bit more detail on each implementation. 

From custom to customer-focused: bundling FluxCD

The customer-focused operator uses our existing Helm chart internally to manage Redpanda deployments. This was possible thanks to a tool called FluxCD, which is primarily a GitOps tool (similar to ArgoCD). Bundling FluxCD in the operator sped up development of the new unified Redpanda Operator and guaranteed similarity (and an easy migration path) between Helm and operator deployments for our customers.

Tip: If you’re 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.

While bundling FluxCD made initial development easy, we found that customers were confused — bundling made our initial version of the customer-facing operator quite different from others in the Kubernetes ecosystem. Additionally, some customers were already using FluxCD, which conflicted with our bundled version. Lastly, having FluxCD and the Helm chart as dependencies made it challenging to combine both operators so our cloud team could easily manage our cloud deployments.

In the end, we decided we should follow our company motto and simplify. So, we began merging the customer and internal versions of Redpanda Operator to create a single, powerful Kubernetes operator that everyone can use.

A new unified Redpanda Operator

To begin the merge, we removed FluxCD from the dependencies and no longer wrap our Helm chart. This paved the way for a unified operator across our Cloud and our Self-Managed customers while simplifying the codebase tremendously, which also makes it easier to add new features down the road.

Unifying the operators is still a work in progress, and is being split across multiple operator versions. The table below provides more details on each version.

Note that each of the operator branches above will get the same patch updates throughout 2025. At some point, the 2.3.x and 2.4.x branches will be deprecated, but there’s no date for this yet.

We’re excited about moving to a single operator for Cloud and Self-Managed clusters, removing the old dependencies, and making these changes available to everyone! If you want to test out the latest beta branch, you can find more details in our docs.

Say hello to simplified versioning 

You might notice a jump in version numbers between the latest branch (v25.1.x) and the previous branch (v2.4.x). Before this change, users commonly asked which operator or Helm chart version was compatible with a specific Redpanda version. This compatibility was important in some situations, as certain features required changes on both sides. Back then, we relied on a compatibility matrix in our docs to help users.

So, we decided to simplify how to determine this compatibility by releasing Redpanda Operator and Helm chart versions that match a specific Redpanda version. This means you can now determine compatibility at a glance without checking a compatibility chart. And, each operator and Helm chart version will also be compatible with the Redpanda version above and below it, as shown in the following example:

You can learn more about it in our docs.

When to choose Redpanda Operator or Helm chart

Redpanda Operator has become the default recommendation over our Helm chart for Kubernetes deployments as we added new features and received expanded test coverage.

However, our Helm chart still serves an important purpose for many customers, and we will continue to support and add features to it. The Helm chart provides an efficient way to configure and deploy Redpanda clusters for those looking for a quick and simple deployment. Helm’s templating capabilities also make it easy to adjust configurations.

Keep in mind that there are limitations to how much control a Helm chart alone can have over a deployment. The Redpanda Operator offers advanced management capabilities, such as automating scaling, updates, and recovery tasks. This deployment option is ideal for teams that prefer a “set and forget” approach to cluster operations, and don’t mind having custom resources deployed in their Kubernetes environment.

To make things easier, below is a comparison table of a deployment using Helm or Redpanda Operator.

You can read more about it in our docs.

Getting started with Redpanda on Kubernetes

With Kubernetes’ orchestration power and Redpanda’s data streaming performance, you can create a flexible, resilient, and scalable infrastructure that’s ideal for various streaming use cases.

To get started, browse our docs to familiarize yourself with the process of deploying Redpanda into Kubernetes. The Kubernetes overview page is a great starting point, then check out the Kubernetes cluster requirements to prepare your environment and select the right tools.

For end-to-end guides on secure deployments of Redpanda on managed Kubernetes services, see:

• Azure Kubernetes Service (AKS)
• Elastic Kubernetes Service (EKS)
• Google Kubernetes Engine (GKE)
• Local (kind or minikube)

Before moving to production, we recommend creating a test environment first to get acquainted with Redpanda’s deployment mechanics within Kubernetes. The Production Deployment Workflow page has everything you need in the exact order you’ll need it. Lastly, keep an eye on Redpanda University for our upcoming free course on deploying Redpanda in Kubernetes!

In the meantime, if you have any questions or feedback, just drop us a note on Slack.