What’s New in the Redpanda Operator

The Redpanda Operator introduces the Pipeline custom resource, which runs Redpanda Connect pipelines as declaratively managed Kubernetes workloads. You define the pipeline configuration in the resource, and the operator deploys it, lints it before startup, rolls it automatically on configuration and credential changes, and reports health through status conditions. A pipeline can reference a Redpanda resource and a User resource, and the operator injects broker addresses, TLS material, and SASL credentials into the rendered configuration for you.

Pipelines also implement the Kubernetes scale subresource, so you can scale them with kubectl scale, a HorizontalPodAutoscaler, or KEDA, including on consumer group lag and on the metrics Redpanda Connect emits.

The Pipeline resource is in beta and requires an Enterprise Edition license. Enable it with the operator chart’s connectController.enabled=true setting.

The Redpanda Operator introduces Stretch Clusters: a single logical Redpanda cluster distributed across multiple Kubernetes clusters for multi-region high availability. Operators in each Kubernetes cluster coordinate through Raft consensus, and the new StretchCluster and RedpandaBrokerPool custom resources define the cluster and its per-cluster broker groups.

The release also adds the rpk k8s plugin, with rpk k8s multicluster commands to bootstrap TLS certificates and peer configuration (bootstrap), check deployment health (status), and collect diagnostics bundles (bundle).

For deployment steps, see Deploy a Stretch Cluster on Kubernetes.

The Console custom resource and the Redpanda Console Helm chart can expose Redpanda Console through a Kubernetes Gateway API HTTPRoute as an alternative to Ingress. You reference an existing Gateway in gateway.parentRefs, and the operator or chart renders and manages the HTTPRoute for you. You can enable only one of gateway or ingress at a time.

See Expose Redpanda Console with the Gateway API.

In Redpanda Operator v26.2.1 or later, the operator gates each step of a rolling restart with Redpanda’s per-broker restart probes instead of a single cluster-wide health check. Before restarting a broker, the operator confirms that the restart cannot lose data acknowledged with acks=1, make partitions unavailable, or block acks=all produce requests. After each restart, the operator waits until the broker reports that it has fully resynced before restarting the next one, because a Pod can pass its readiness probe while the broker is still replaying partition state.

The probes require Redpanda 25.1 or later. On earlier versions, the operator falls back to the cluster-wide health check.

See How the Redpanda Operator gates each restart.

The new RedpandaBrokerPool custom resource manages broker pools for Stretch Clusters only. The RedpandaBrokerPool CRD is installed only in multicluster mode, and its controller does not reconcile pools for standalone Redpanda resources.

For standalone clusters, the NodePool custom resource (beta) remains the way to manage broker pools. Existing NodePool configurations continue to work.

The Redpanda Operator introduces the NodePool custom resource, which lets you manage groups of Redpanda brokers as independent units within a single cluster. Each NodePool creates its own StatefulSet, giving you fine-grained control over broker placement, resources, and lifecycle.

NodePools enable blue/green node pool migrations: you create a new NodePool on the target Kubernetes node pool, and the operator automatically replicates data and decommissions old brokers with zero downtime. This replaces the manual, broker-by-broker migration process.

The Console custom resource supports a monitoring configuration that deploys a Prometheus ServiceMonitor to automatically discover and scrape Console metrics. See Prometheus ServiceMonitor.

The Redpanda custom resource supports configuring Schema Registry ACLs through the schemaRegistry.authenticationMethod field. This enables fine-grained access control for Schema Registry operations in clusters deployed with Kubernetes.

When you enable Schema Registry authentication, you can control which users and service accounts can register, modify, and read schemas. See Configure Authentication for Redpanda in Kubernetes for configuration details.

The Redpanda custom resource supports Cloud Topics in Kubernetes deployments. You can configure topics to use cloud storage as the primary backing store by setting the appropriate storage mode properties.

Cloud Topics in Kubernetes provide the same cost savings and architectural benefits as self-managed deployments. You configure them declaratively through the Redpanda custom resource. For setup instructions, see Cloud Topics for Kubernetes.

The Redpanda Operator supports group-based access control (GBAC) for Kubernetes deployments with OIDC authentication. You can assign roles and ACLs to OIDC groups, and users automatically inherit permissions from their group memberships.

GBAC simplifies permission management in Kubernetes environments by integrating with your identity provider’s group structure. See Group-based access control for Kubernetes for configuration and usage details.