Add Choose Your Deployment chooser page for Kubernetes

antora.yml

@@ -38,7 +38,8 @@ asciidoc:
     latest-console-tag: 'v3.3.1'
     latest-release-commit: 'ebee215fdb2b8004735c6f800e532564cdcc05e1'
     latest-operator-version: 'v2.3.8-24.3.6'
-    operator-beta-tag: ''
+    operator-beta-version: '26.2.1-beta.3'
+    operator-beta-tag: 'v26.2.1-beta.3'
     helm-beta-tag: ''
     latest-redpanda-helm-chart-version: ''
     redpanda-beta-version: ''

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]

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

@@ -0,0 +1,77 @@
+= 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
+
+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). This page compares the available topologies and routes you to the right deployment guide.
+
+== What you're protecting against
+
+Each topology mitigates a different class of failure:
+
+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="2,2,2,2,2,1,2"]
+|===
+| Topology | Survives | Replication and RPO | Failover | Latency requirement | License | Deployment guide
+
+| Single cluster, multi-AZ
+| Loss of one AZ (with three or more AZs)
+| Synchronous (Raft), zero data loss
+| Automatic
+| Low inter-AZ latency
+| Community
+| xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[] with xref:manage:kubernetes/k-rack-awareness.adoc[rack awareness]
+
+| Stretch Cluster (one cluster across Kubernetes clusters)
+| Loss of one region, data center, or Kubernetes cluster (with three or more)
+| Synchronous (Raft), zero data loss, one set of offsets
+| Automatic
+| Low inter-cluster latency (under 50 ms recommended); requires WAN tuning
+| Enterprise
+| xref:deploy:redpanda/kubernetes/k-stretch-clusters.adoc[]
+
+| Independent clusters with asynchronous replication (Shadowing)
+| Loss of an entire region or cluster; also isolates the replica from many data-corruption events
+| Asynchronous, near real time, offset-preserving; RPO greater than zero
+| Runbook-driven: fail over shadow topics, then redirect clients
+| None; any distance
+| Enterprise
+| 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.
+
+In this release, 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