Redpanda Operator v26.2 introduces Stretch Clusters (GA), enabling a single logical Redpanda cluster to span multiple Kubernetes clusters across regions or clouds. This delivers RPO=0 and RTO=0 for Kafka workloads via synchronous Raft-based replication, with automatic failover and no manual cutover required. The release also adds: a Pipeline CRD (beta) for managing Redpanda Connect pipelines as native Kubernetes resources with automatic credential injection; per-broker pre/post-restart probes that gate rolling restarts on actual replication state rather than cluster-wide health; and Gateway API support with TLSRoute for Kafka (beta) and HTTPRoute for Redpanda Console (GA). Stretch Clusters and Connect pipelines are Enterprise features; restart probes and Gateway API support are available to all users.
Table of contents
Stretch Clusters are GA: RPO = 0, RTO = 0, across regions and clouds #Redpanda Connect support (beta): manage pipelines as Kubernetes resources #Safer rolling restarts: per-broker pre/post-restart probes #Gateway API support: TLSRoute for Kafka, HTTPRoute for Console #Release summary and next steps #Questions this post answers
What is RPO and RTO for a Redpanda Stretch Cluster across multiple regions?
A Redpanda Stretch Cluster achieves RPO=0 and RTO=0 across regions. Every acknowledged write is durably held by a Raft quorum spanning multiple failure domains, so losing a region loses zero acknowledged data. There is no failover step: surviving regions already hold a majority, leadership re-elects automatically, and the cluster keeps serving without manual promotion or restore. Teams designing multi-region Kafka architectures track replication trade-offs like these on daily.dev.
How do per-broker restart probes work in Redpanda Operator 26.2?
Redpanda Operator 26.2 adds two HTTP probes sourced from Redpanda Core. The pre-restart probe (/v1/broker/pre_restart_probe) checks whether a specific broker is safe to restart by evaluating partition leadership, acks=1 data-loss risk, leaderless partitions, and quorum loss. The post-restart probe (/v1/broker/post_restart_probe) waits until the broker has reclaimed its in-sync replicas before rolling the next pod; recovery threshold is tunable via --post-restart-caught-up-percent. Engineers running Redpanda upgrades in production follow operator safety improvements like this on daily.dev.
How do I expose Redpanda Console via Kubernetes Gateway API instead of Ingress?
Declare a gateway stanza on the Console custom resource referencing your existing Gateway via parentRefs, hostnames, and path. The operator renders and reconciles the HTTPRoute automatically. The same configuration is available in the Console Helm chart for non-operator installs. Gateway API CRDs must be pre-installed; gateway and ingress listeners are mutually exclusive and enabling both fails immediately. Platform teams standardizing on Gateway API for Kafka infrastructure find relevant operator updates on daily.dev.