--- title: Multi-region high availability for Kafka workloads with... description: Redpanda Operator v26.2 introduces Stretch Clusters (GA), enabling a single logical Redpanda cluster to span multiple Kubernetes clusters across regions or... canonical: https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Multi-region high availability for Kafka workloads with a single Stretch Cluster | daily.dev og:description: Redpanda Operator v26.2 introduces Stretch Clusters (GA), enabling a single logical Redpanda cluster to span multiple Kubernetes clusters across regions or... og:url: https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g og:image: https://api.daily.dev/og/posts/MCtkzxA0g.png og:image:alt: Multi-region high availability for Kafka workloads with a single Stretch Cluster og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Multi-region high availability for Kafka workloads with a single Stretch Cluster **[Redpanda](https://daily.dev/sources/redpanda)** · 11 min read · 6 upvotes · 0 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What does a Redpanda Stretch Cluster provide for multi-region Kafka high availability? A Stretch Cluster is a single logical Redpanda cluster whose brokers span multiple Kubernetes clusters, typically one per availability zone, region, or cloud provider. Because Redpanda replicates partitions with Raft, requiring a majority of replicas to acknowledge a write, it delivers RPO=0 (no acknowledged data lost on region failure) and RTO=0 (no failover step, since surviving regions already hold a majority and leadership re-elects automatically). Existing Kafka clients work unchanged via Redpanda's Kafka-compatible API. _daily.dev surfaces releases like this for teams weighing synchronous multi-region replication for Kafka workloads._ ### How are Stretch Clusters configured in Redpanda Operator 26.2? Two custom resources in the cluster.redpanda.com/v1alpha2 API group model it: a single StretchCluster resource holds shared cluster-wide defaults (image, storage, resources, cluster config, cross-cluster networking mode), and one RedpandaBrokerPool per member Kubernetes cluster carries region-specific overrides such as replica count, external access, TLS, scheduling, and storage. Each pool references the parent StretchCluster via clusterRef, and the operator stitches the pools into one cluster with a consistent broker list. _engineers designing Kubernetes-native Kafka deployments track operator config changes like this via daily.dev._ ### How do the new per-broker restart probes in Redpanda Operator 26.2 prevent data loss during rolling restarts? A pre-restart probe (/v1/broker/pre_restart_probe) checks a specific broker's actual partition leadership and replication state before restarting it, catching acks=1 data-loss risk, leaderless-partition unavailability, and acks=-1 quorum loss; RF=1 partitions are treated as acceptable since they have no redundancy by design. A post-restart probe waits until the broker reclaims its in-sync replicas (100% by default, tunable via --post-restart-caught-up-percent) before the operator proceeds to the next pod, falling back to the old cluster-wide health check on unsupported Redpanda versions. _platform teams tuning safe rolling restarts for stateful clusters follow changes like this on daily.dev._ ## Similar posts on daily.dev - [Push-button migration from Confluent to Redpanda with Shadowing](https://daily.dev/posts/push-button-migration-from-confluent-to-redpanda-with-shadowing-c3k7yvttl) · Redpanda · 1 upvotes · 0 comments - [Build vs Buy Streaming for Real-Time RAG: 2026 Guide](https://daily.dev/posts/build-vs-buy-streaming-for-real-time-rag-2026-guide-jhmh1s3d7) · Confluent Blog · 1 upvotes · 0 comments - [Under the hood: Redpanda Cloud Topics architecture](https://daily.dev/posts/under-the-hood-redpanda-cloud-topics-architecture-xnopd4gkh) · Redpanda · 1 upvotes · 0 comments - [Kafka for High Availability in Practice: Patterns with Red Hat Streams for Apache Kafka](https://daily.dev/posts/kafka-for-high-availability-in-practice-patterns-with-red-hat-streams-for-apache-kafka-t1n6wl4xv) · Medium · 0 upvotes · 0 comments - [Redpanda Terraform supports managing Redpanda Connect pipelines, private network](https://daily.dev/posts/redpanda-terraform-supports-managing-redpanda-connect-pipelines-private-network-len9slef1) · Redpanda · 2 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#distributed-systems](https://daily.dev/tags/distributed-systems), [#kafka](https://daily.dev/tags/kafka), [#redpanda](https://daily.dev/tags/redpanda) [View this post on daily.dev](https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Multi-region high availability for Kafka workloads with a single Stretch Cluster","url":"https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g"},"datePublished":"2026-08-12T04:52:14.690Z","dateModified":"2026-09-13T21:58:19.200Z","description":"Redpanda Operator v26.2 introduces Stretch Clusters (GA), enabling a single logical Redpanda cluster to span multiple Kubernetes clusters across regions or...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0b0db508f8c64e7a45308585414cb3ff?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0b0db508f8c64e7a45308585414cb3ff?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Redpanda","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Redpanda","logo":"https://media.daily.dev/image/upload/s--1R2EIDcb--/f_auto,q_auto/v1769934743/logos/redpanda","url":"https://daily.dev/sources/redpanda"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,distributed-systems,kafka,redpanda","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Redpanda","item":"https://daily.dev/sources/redpanda"},{"@type":"ListItem","position":3,"name":"Multi-region high availability for Kafka workloads with a single Stretch Cluster"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster-mctkzxa0g#faq","mainEntity":[{"@type":"Question","name":"What does a Redpanda Stretch Cluster provide for multi-region Kafka high availability?","acceptedAnswer":{"@type":"Answer","text":"A Stretch Cluster is a single logical Redpanda cluster whose brokers span multiple Kubernetes clusters, typically one per availability zone, region, or cloud provider. Because Redpanda replicates partitions with Raft, requiring a majority of replicas to acknowledge a write, it delivers RPO=0 (no acknowledged data lost on region failure) and RTO=0 (no failover step, since surviving regions already hold a majority and leadership re-elects automatically). Existing Kafka clients work unchanged via Redpanda's Kafka-compatible API. daily.dev surfaces releases like this for teams weighing synchronous multi-region replication for Kafka workloads."}},{"@type":"Question","name":"How are Stretch Clusters configured in Redpanda Operator 26.2?","acceptedAnswer":{"@type":"Answer","text":"Two custom resources in the cluster.redpanda.com/v1alpha2 API group model it: a single StretchCluster resource holds shared cluster-wide defaults (image, storage, resources, cluster config, cross-cluster networking mode), and one RedpandaBrokerPool per member Kubernetes cluster carries region-specific overrides such as replica count, external access, TLS, scheduling, and storage. Each pool references the parent StretchCluster via clusterRef, and the operator stitches the pools into one cluster with a consistent broker list. engineers designing Kubernetes-native Kafka deployments track operator config changes like this via daily.dev."}},{"@type":"Question","name":"How do the new per-broker restart probes in Redpanda Operator 26.2 prevent data loss during rolling restarts?","acceptedAnswer":{"@type":"Answer","text":"A pre-restart probe (/v1/broker/pre_restart_probe) checks a specific broker's actual partition leadership and replication state before restarting it, catching acks=1 data-loss risk, leaderless-partition unavailability, and acks=-1 quorum loss; RF=1 partitions are treated as acceptable since they have no redundancy by design. A post-restart probe waits until the broker reclaims its in-sync replicas (100% by default, tunable via --post-restart-caught-up-percent) before the operator proceeds to the next pod, falling back to the old cluster-wide health check on unsupported Redpanda versions. platform teams tuning safe rolling restarts for stateful clusters follow changes like this on daily.dev."}}]} ```