Add Stretch Cluster deployment guide for Kubernetes (26.2)

antora.yml

@@ -34,7 +34,7 @@ asciidoc:
     # We try to fetch the latest versions from GitHub at build time
     # --
     full-version: 26.2.1
-    latest-redpanda-tag: 'v26.1.9'
+    latest-redpanda-tag: 'v26.1.12'
     latest-console-tag: 'v3.3.1'
     latest-release-commit: 'ebee215fdb2b8004735c6f800e532564cdcc05e1'
     latest-operator-version: 'v2.3.8-24.3.6'
@@ -52,6 +52,9 @@ asciidoc:
     supported-rhel-recommended: '9+'
     supported-ubuntu-required: '20.04 LTS'
     supported-ubuntu-recommended: '22.04+'
+    # Linux package repository migration (dl.redpanda.com -> linux.pkg.redpanda.com)
+    legacy-repo-shutdown-date: 'September 28, 2026'
+    repo-dual-publish-start: 'June 1, 2026'
     badge-deprecated: 'image:https://img.shields.io/badge/-Deprecated-red.svg[xref=upgrade:deprecated/index.adoc]'
     removals-without-aliases:
       - page: reference/rpk/rpk-cloud/

modules/ROOT/nav.adoc

@@ -78,9 +78,11 @@
 **** xref:deploy:redpanda/kubernetes/k-production-workflow.adoc[Deployment Workflow]
 **** xref:deploy:redpanda/kubernetes/k-requirements.adoc[Requirements and Recommendations]
 **** xref:deploy:redpanda/kubernetes/k-tune-workers.adoc[Tune Worker Nodes]
-**** xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[Deploy Redpanda]
-**** xref:deploy:redpanda/kubernetes/k-production-readiness.adoc[]
+**** xref:deploy:redpanda/kubernetes/k-choose-deployment.adoc[Choose Your Deployment]
+***** xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[Deploy Redpanda]
+***** xref:deploy:redpanda/kubernetes/k-stretch-clusters.adoc[Deploy a Stretch Cluster]
 **** xref:deploy:redpanda/kubernetes/k-high-availability.adoc[High Availability]
+**** xref:deploy:redpanda/kubernetes/k-production-readiness.adoc[]
 *** xref:deploy:redpanda/manual/index.adoc[Linux]
 **** xref:deploy:redpanda/manual/production/requirements.adoc[Hardware and Software Requirements]
 **** xref:deploy:redpanda/manual/production/index.adoc[Deployment Options]
@@ -419,6 +421,15 @@
 **** xref:reference:rpk/rpk-group/rpk-group-seek.adoc[]
 *** xref:reference:rpk/rpk-help.adoc[]
 *** xref:reference:rpk/rpk-iotune.adoc[]
+*** xref:reference:rpk/rpk-k8s/rpk-k8s.adoc[]
+**** xref:reference:rpk/rpk-k8s/rpk-k8s-install.adoc[]
+**** xref:reference:rpk/rpk-k8s/rpk-k8s-multicluster.adoc[]
+***** xref:reference:rpk/rpk-k8s/rpk-k8s-multicluster-bootstrap.adoc[]
+***** xref:reference:rpk/rpk-k8s/rpk-k8s-multicluster-bundle.adoc[]
+***** xref:reference:rpk/rpk-k8s/rpk-k8s-multicluster-status.adoc[]
+**** xref:reference:rpk/rpk-k8s/rpk-k8s-uninstall.adoc[]
+**** xref:reference:rpk/rpk-k8s/rpk-k8s-upgrade.adoc[]
+**** xref:reference:rpk/rpk-k8s/rpk-k8s-version.adoc[]
 *** xref:reference:rpk/rpk-plugin/rpk-plugin.adoc[]
 **** xref:reference:rpk/rpk-plugin/rpk-plugin-list.adoc[]
 **** xref:reference:rpk/rpk-plugin/rpk-plugin-uninstall.adoc[]

modules/deploy/pages/redpanda/kubernetes/k-choose-deployment.adoc

@@ -0,0 +1,90 @@
+= Choose Your Deployment
+:description: Compare Redpanda deployment topologies for Kubernetes and choose the one that matches the failures you must survive and your recovery objectives.
+:env-kubernetes: true
+:page-categories: Deployment, High Availability
+:page-topic-type: concept
+:personas: platform_operator, platform_engineer
+:learning-objective-1: Compare Redpanda deployment topologies by failure domain, recovery objectives, and operational cost
+:learning-objective-2: Choose the deployment guide that matches your availability requirements
+
+Before you deploy Redpanda for production, choose the cluster topology that matches the failures you must survive and your recovery objectives: how much data you can afford to lose (recovery point objective, or RPO) and how quickly you must recover (recovery time objective, or RTO). Each topology mitigates a different class of failure, from the loss of a single broker to the loss of an entire region, and makes different trade-offs in latency, license requirements, and operational complexity. This page compares the available topologies along those dimensions and routes you to the right deployment guide.
+
+After reading this page, you will be able to:
+
+* [ ] {learning-objective-1}
+* [ ] {learning-objective-2}
+
+== What you're protecting against
+
+Use this table to identify the failures you must plan for and the mechanisms that mitigate them:
+
+include::deploy:partial$high-availability.adoc[tag=failure-mitigation]
+
+== Decision dimensions
+
+Weigh the options against these dimensions:
+
+* *Failure domain*: The largest unit whose loss you must survive: a broker, a rack, an availability zone (AZ), a region, or an entire Kubernetes cluster.
+* *RPO*: Synchronous Raft replication within one cluster means zero data loss. Asynchronous replication between clusters means near-real-time copies with some replication lag.
+* *Failover*: A single cluster fails over automatically through Raft leader election. Independent clusters require a runbook-driven failover, including redirecting clients.
+* *Latency*: Synchronous replication across distant locations adds produce latency and requires tuning. Asynchronous replication has no distance ceiling.
+* *Client semantics*: A single cluster keeps one set of offsets. Shadowing preserves offsets on an independent cluster, so consumers can resume after failover.
+* *License and complexity*: Some topologies require an Enterprise license and more operational investment.
+
+== Compare topologies
+
+[cols="1h,2,2,2"]
+|===
+| | Single cluster, multi-AZ | Stretch Cluster (one cluster across Kubernetes clusters) | Independent clusters with asynchronous replication (Shadowing)
+
+| Survives
+| Loss of one AZ (with three or more AZs)
+| Loss of one region, data center, or Kubernetes cluster (with three or more)
+| Loss of an entire region or cluster; also isolates the replica from many data-corruption events
+
+| Replication and RPO
+| Synchronous (Raft), zero data loss
+| Synchronous (Raft), zero data loss, one set of offsets
+| Asynchronous, near real time, offset-preserving; RPO greater than zero
+
+| Failover
+| Automatic
+| Automatic
+| Runbook-driven: fail over shadow topics, then redirect clients
+
+| Latency requirement
+| Low inter-AZ latency
+| Low inter-cluster latency (under 50 ms recommended); requires WAN tuning
+| None; any distance
+
+| License
+| Community
+| Enterprise
+| Enterprise
+
+| Deployment guide
+| xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[] with xref:manage:kubernetes/k-rack-awareness.adoc[rack awareness]
+| xref:deploy:redpanda/kubernetes/k-stretch-clusters.adoc[]
+| xref:manage:disaster-recovery/shadowing/overview.adoc[]
+|===
+
+For read-only offloading rather than disaster recovery, see xref:manage:kubernetes/k-remote-read-replicas.adoc[Remote Read Replicas].
+
+== Quick picks
+
+* *You need zonal resilience with the lowest latency and cost*: Deploy a single cluster across three or more AZs with rack awareness.
+* *You need zero data loss across regions and you run Kubernetes*: Deploy a xref:deploy:redpanda/kubernetes/k-stretch-clusters.adoc[Stretch Cluster].
+* *You need disaster recovery across any distance, or an isolated recovery copy*: Keep clusters independent and replicate with xref:manage:disaster-recovery/shadowing/overview.adoc[Shadowing].
+* *You need to serve remote consumers without a second writable cluster*: Use xref:manage:kubernetes/k-remote-read-replicas.adoc[Remote Read Replicas].
+
+== Stretch Clusters and Shadowing
+
+Stretch Clusters and Shadowing solve different problems and can complement each other. A Stretch Cluster is one logical cluster with synchronous replication and a single set of offsets; Shadowing asynchronously replicates data and metadata between two independent clusters for disaster recovery, protecting against events that affect a whole cluster, including some it cannot survive synchronously.
+
+A Stretch Cluster can act as the shadow (target) cluster of a shadow link. Using a Stretch Cluster as the source cluster of a shadow link is not supported.
+
+== Next steps
+
+* xref:deploy:redpanda/kubernetes/k-high-availability.adoc[High Availability in Kubernetes] for the concepts behind these topologies, including replica placement and failure modes.
+* xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[Deploy Redpanda] or xref:deploy:redpanda/kubernetes/k-stretch-clusters.adoc[Deploy a Stretch Cluster] to get started.
+* xref:deploy:redpanda/kubernetes/k-production-readiness.adoc[] to validate your deployment, whichever topology you choose.

modules/deploy/pages/redpanda/kubernetes/k-production-deployment.adoc

@@ -6,7 +6,7 @@
 :env-kubernetes: true
 :page-categories: Deployment, GitOps
 
-This topic describes how to configure and deploy one or more Redpanda clusters and Redpanda Console in Kubernetes.
+This topic describes how to configure and deploy one or more Redpanda clusters and Redpanda Console in Kubernetes. Each Redpanda cluster runs within a single Kubernetes cluster. For multi-region topologies and other deployment shapes, see xref:deploy:redpanda/kubernetes/k-choose-deployment.adoc[].
 
 == Prerequisites
 
@@ -715,7 +715,7 @@ statefulset:
 
 WARNING: Disabling `podAntiAffinity` rules is not recommended for production environments as it allows multiple brokers to be scheduled on the same node, increasing the risk of data loss if a node fails.
 
-See also: xref:./k-high-availability.adoc[]
+See also: xref:deploy:redpanda/kubernetes/k-high-availability.adoc[]
 
 === Graceful shutdown
 
@@ -785,6 +785,6 @@ See the xref:manage:kubernetes/index.adoc[Manage Kubernetes topics] to learn how
 
 include::shared:partial$suggested-reading.adoc[]
 
-- xref:./k-high-availability.adoc[]
+- xref:deploy:redpanda/kubernetes/k-high-availability.adoc[]
 - xref:reference:k-redpanda-helm-spec.adoc[Redpanda Helm Specification]
 - xref:reference:k-crd.adoc[Redpanda CRD Reference]