fix: consolidate HA/DR nav duplication and sweep stale alias xrefs (DOC-2361)

modules/ROOT/nav.adoc

@@ -81,7 +81,6 @@
 **** 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]
@@ -126,7 +125,6 @@
 *** xref:manage:kubernetes/tiered-storage/index.adoc[Tiered Storage]
 **** xref:manage:kubernetes/tiered-storage/k-tiered-storage.adoc[Use Tiered Storage]
 **** xref:manage:kubernetes/tiered-storage/k-fast-commission-decommission.adoc[]
-**** xref:manage:kubernetes/tiered-storage/k-remote-read-replicas.adoc[Remote Read Replicas]
 **** xref:manage:kubernetes/tiered-storage/k-topic-recovery.adoc[Topic Recovery]
 **** xref:manage:kubernetes/tiered-storage/k-whole-cluster-restore.adoc[Whole Cluster Restore]
 *** xref:manage:kubernetes/networking/index.adoc[Networking and Connectivity]
@@ -149,11 +147,12 @@
 ***** xref:manage:kubernetes/security/authorization/k-group-controller.adoc[Manage Groups and ACLs (Operator)]
 ***** xref:manage:kubernetes/security/authentication/k-schema-registry-acls.adoc[Manage Schema Registry ACLs (Operator)]
 **** xref:manage:kubernetes/security/k-audit-logging.adoc[Audit Logging]
+*** xref:manage:kubernetes/k-high-availability.adoc[High Availability]
 *** xref:manage:kubernetes/k-rack-awareness.adoc[Rack Awareness]
 *** xref:manage:kubernetes/k-remote-read-replicas.adoc[Remote Read Replicas]
 *** xref:manage:kubernetes/shadowing/index.adoc[Shadowing]
 **** xref:manage:kubernetes/shadowing/k-shadow-linking.adoc[Configure Shadowing]
-**** xref:manage:kubernetes/shadowing/k-monitor-shadowing.adoc[Monitor]
+**** xref:manage:kubernetes/shadowing/k-monitor-shadowing.adoc[Monitor Shadowing]
 **** xref:manage:kubernetes/shadowing/k-failover-runbook.adoc[Failover Runbook]
 *** xref:manage:kubernetes/k-manage-resources.adoc[Manage Pod Resources]
 *** xref:manage:kubernetes/k-scale-redpanda.adoc[Scale]

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

@@ -167,6 +167,6 @@ A Stretch Cluster can act as the shadow (target) cluster of a shadow link. Using
 
 == 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:manage: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

@@ -507,7 +507,7 @@ NOTE: You must provision one dedicated worker node for each Redpanda broker that
 
 See also:
 
-- xref:deploy:redpanda/kubernetes/k-high-availability.adoc[]
+- xref:manage:kubernetes/k-high-availability.adoc[]
 - xref:deploy:redpanda/kubernetes/k-requirements.adoc#number-of-worker-nodes[Kubernetes Cluster Requirements]
 
 === TLS
@@ -740,7 +740,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:deploy:redpanda/kubernetes/k-high-availability.adoc[]
+See also: xref:manage:kubernetes/k-high-availability.adoc[]
 
 === Graceful shutdown
 
@@ -810,6 +810,6 @@ See the xref:manage:kubernetes/index.adoc[Manage Kubernetes topics] to learn how
 
 include::shared:partial$suggested-reading.adoc[]
 
-- xref:deploy:redpanda/kubernetes/k-high-availability.adoc[]
+- xref:manage:kubernetes/k-high-availability.adoc[]
 - xref:reference:k-redpanda-helm-spec.adoc[Redpanda Helm Specification]
 - xref:reference:k-crd.adoc[Redpanda CRD Reference]

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

@@ -911,7 +911,7 @@ See also: https://kubernetes.io/docs/tasks/run-application/configure-pdb/[Kubern
 
 === Rack awareness and topology spread
 
-Configure topology spread constraints to distribute brokers across availability zones. For configuration instructions, see xref:deploy:redpanda/kubernetes/k-high-availability.adoc#multi-az-deployment[Multi-AZ deployment].
+Configure topology spread constraints to distribute brokers across availability zones. For configuration instructions, see xref:manage:kubernetes/k-high-availability.adoc#multi-az-deployment[Multi-AZ deployment].
 
 Production deployments require each Redpanda broker to run in a different availability zone to ensure that a single zone failure does not cause loss of quorum. For a three-broker cluster, brokers must be distributed across three separate zones.
 

modules/deploy/partials/high-availability.adoc

@@ -2,10 +2,10 @@
 ifdef::env-kubernetes[]
 :remote-read-replicas: manage:kubernetes/k-remote-read-replicas.adoc
 :rack-awareness: manage:kubernetes/k-rack-awareness.adoc
-:tiered-storage: manage:kubernetes/storage/tiered-storage/k-tiered-storage.adoc
+:tiered-storage: manage:kubernetes/tiered-storage/k-tiered-storage.adoc
 endif::[]
 ifndef::env-kubernetes[]
-:remote-read-replicas: deploy:redpanda/manual/remote-read-replicas.adoc
+:remote-read-replicas: manage:remote-read-replicas.adoc
 :rack-awareness: manage:rack-awareness.adoc
 :tiered-storage: manage:tiered-storage.adoc
 endif::[]

modules/deploy/partials/kubernetes/guides/external-access-intro.adoc

@@ -14,5 +14,5 @@ To access your Redpanda brokers externally, you can map your worker nodes' IP ad
 ====
 IP addresses can change. If the IP addresses of your worker nodes change, you must update your `/etc/hosts` file with the new mappings.
 
-In a production environment, it's a best practice to use ExternalDNS to manage DNS records for your brokers. See xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#use-externaldns-for-external-access[Use ExternalDNS for external access].
+In a production environment, it's a best practice to use ExternalDNS to manage DNS records for your brokers. See xref:deploy:redpanda/kubernetes/k-production-deployment.adoc#externaldns[Use ExternalDNS for external access].
 ====

modules/home/pages/index.adoc

@@ -11,11 +11,11 @@
 :page-deploy-1-icon: lightning
 :page-deploy-2-title: Kubernetes
 :page-deploy-2-desc: Deploy production-ready clusters with the Redpanda Operator.
-:page-deploy-2-link: deploy:deployment-option/self-hosted/kubernetes/index.adoc
+:page-deploy-2-link: deploy:redpanda/kubernetes/index.adoc
 :page-deploy-2-icon: kubernetes
 :page-deploy-3-title: Linux installation
 :page-deploy-3-desc: Install Redpanda on bare metal or VMs for maximum performance.
-:page-deploy-3-link: deploy:deployment-option/self-hosted/manual/index.adoc
+:page-deploy-3-link: deploy:redpanda/manual/index.adoc
 :page-deploy-3-icon: terminal
 // Popular topics section
 :page-popular-title: Popular topics

modules/manage/pages/cluster-maintenance/decommission-brokers.adoc

@@ -85,7 +85,7 @@ ID    HOST                          PORT   RACK
 
 The output shows four racks (A/B/C/D), so you might want to have at least four brokers to make use of all racks.
 
-Rack awareness is just one aspect of availability. Check out xref:deploy:deployment-option/self-hosted/manual/high-availability.adoc[High Availability] for details on deploying Redpanda for high availability.
+Rack awareness is just one aspect of availability. Check out xref:manage:high-availability.adoc[High Availability] for details on deploying Redpanda for high availability.
 
 === Cost
 
@@ -146,7 +146,7 @@ Cost and use case requirements dictate how much to spend on local disk capacity.
 ====
 At this point in the example, it remains unclear whether or not it makes sense to scale down to five brokers. Current calculations are based on five brokers. You can consider other broker counts later as needed.
 
-Additionally, assumptions have been made regarding a constant throughput and perfect data balancing. Throughput fluctuates across all partitions, which causes data imbalance. The calculations above attempt to accommodate for this by padding disk size by 1%. You can increase this buffer (for example, in the case of expected hot spot partitions). For details on sizing, see xref:deploy:deployment-option/self-hosted/manual/sizing.adoc[Sizing Guidelines].
+Additionally, assumptions have been made regarding a constant throughput and perfect data balancing. Throughput fluctuates across all partitions, which causes data imbalance. The calculations above attempt to accommodate for this by padding disk size by 1%. You can increase this buffer (for example, in the case of expected hot spot partitions). For details on sizing, see xref:deploy:redpanda/manual/sizing.adoc[Sizing Guidelines].
 ====
 
 === Durability

modules/manage/pages/cluster-maintenance/node-property-configuration.adoc

@@ -16,7 +16,7 @@ The default `redpanda.yaml` file groups broker properties into categories:
 
 The `redpanda.yaml` file rarely needs to be edited after the system is installed, but you can choose to change broker configuration property values.
 
-NOTE: The broker configuration property xref:reference:properties/broker-properties.adoc[`node_id`] is immutable. To ensure safe operations, omit the `node_id` field from `redpanda.yaml` and allow Redpanda to assign it automatically. For more information, see xref:deploy:deployment-option/self-hosted/manual/production/production-deployment.adoc#do-not-configure-broker-ids[Do not configure broker IDs].
+NOTE: The broker configuration property xref:reference:properties/broker-properties.adoc[`node_id`] is immutable. To ensure safe operations, omit the `node_id` field from `redpanda.yaml` and allow Redpanda to assign it automatically. For more information, see xref:deploy:redpanda/manual/production/production-deployment.adoc#do-not-configure-broker-ids[Do not configure broker IDs].
 
 To change a broker property setting:
 

modules/manage/pages/disaster-recovery/shadowing/index.adoc

@@ -5,3 +5,7 @@
 :page-categories: Management, High Availability, Disaster Recovery
 :page-aliases: deploy:redpanda/manual/disaster-recovery/shadowing/index.adoc
 
+ifndef::env-cloud[]
+These topics cover Shadowing concepts and the configuration workflow for Linux deployments. If you deploy Redpanda in Kubernetes, see xref:manage:kubernetes/shadowing/index.adoc[Shadowing in Kubernetes] to configure shadow links with the Redpanda Operator or Helm chart.
+endif::[]
+

modules/manage/pages/kubernetes/cloud-topics/k-cloud-topics.adoc

@@ -23,7 +23,7 @@ For an overview of how Cloud Topics work, including storage modes, use cases, an
 You must have the following:
 
 - **kubectl**: Ensure you have the https://kubernetes.io/docs/tasks/tools/#kubectl[`kubectl`^] command-line tool installed and configured to communicate with your cluster.
-- **Redpanda**: A xref:deploy:deployment-option/self-hosted/kubernetes/kubernetes-deploy.adoc[Redpanda Operator and a Redpanda resource deployed] in your Kubernetes cluster running Redpanda v26.2 or later.
+- **Redpanda**: A xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[Redpanda Operator and a Redpanda resource deployed] in your Kubernetes cluster running Redpanda v26.2 or later.
 - **Object storage**: A configured object storage backend (Amazon S3, Google Cloud Storage, Azure Blob Storage, or an S3-compatible store such as MinIO).
 - **Enterprise license**: A valid Redpanda Enterprise license applied to the cluster.
 +

modules/manage/pages/kubernetes/k-decommission-brokers.adoc

@@ -92,7 +92,7 @@ ID    HOST                          PORT   RACK
 
 The output shows four racks (A/B/C/D), so you might want to have at least four brokers to use all racks.
 
-Rack awareness is just one aspect of availability. Refer to xref:deploy:redpanda/kubernetes/k-high-availability.adoc[High Availability] for more details on deploying Redpanda for high availability.
+Rack awareness is just one aspect of availability. Refer to xref:manage:kubernetes/k-high-availability.adoc[High Availability] for more details on deploying Redpanda for high availability.
 
 === Cost
 
@@ -146,15 +146,15 @@ Throughput is the primary measurement required to calculate future data storage
 | `(200MB/sec * 3d * 1.1) = 57.024TB / 5 brokers = 11.4TB`
 |===
 
-In the example cluster, only six hours of data locally must be retained. Any older data can be moved to xref:manage:kubernetes/storage/tiered-storage/k-tiered-storage.adoc[Tiered Storage] with a retention of one year. So each broker should have 1.2TB of storage available, taking into account both throughput and current data.
+In the example cluster, only six hours of data locally must be retained. Any older data can be moved to xref:manage:kubernetes/tiered-storage/k-tiered-storage.adoc[Tiered Storage] with a retention of one year. So each broker should have 1.2TB of storage available, taking into account both throughput and current data.
 
 Cost and use case requirements determine how much to spend on local disk capacity. Tiered Storage can help to both decrease costs and expand data retention capabilities.
 
 [NOTE]
 ====
 At this point in the example, it remains unclear whether it is safe to scale down to five brokers. Current calculations are based on five brokers.
 
-Additionally, some assumptions have been made regarding a constant throughput and perfect data balancing. Throughput fluctuates across all partitions, which causes data imbalance. The calculations presented as examples attempt to accommodate for this by padding disk size by 1%. You can increase this buffer, for example in the case of expected hot spot partitions. For details on sizing, see xref:deploy:deployment-option/self-hosted/manual/sizing.adoc[Sizing Guidelines].
+Additionally, some assumptions have been made regarding a constant throughput and perfect data balancing. Throughput fluctuates across all partitions, which causes data imbalance. The calculations presented as examples attempt to accommodate for this by padding disk size by 1%. You can increase this buffer, for example in the case of expected hot spot partitions. For details on sizing, see xref:deploy:redpanda/manual/sizing.adoc[Sizing Guidelines].
 ====
 
 === Durability

modules/deploy/pages/redpanda/kubernetes/k-high-availability.adoc → modules/manage/pages/kubernetes/k-high-availability.adoc

@@ -1,6 +1,6 @@
 = High Availability in Kubernetes
 :description: Explore high availability configurations of Redpanda in Kubernetes.
-:page-aliases: deploy:deployment-option/self-hosted/kubernetes/k-high-availability.adoc
+:page-aliases: deploy:deployment-option/self-hosted/kubernetes/k-high-availability.adoc, deploy:redpanda/kubernetes/k-high-availability.adoc
 :env-kubernetes: true
 :page-categories: Deployment, High Availability
 

modules/manage/pages/kubernetes/k-manage-resources.adoc

@@ -9,7 +9,7 @@ Managing Pod resources, such as CPU, memory, and storage, is critical for ensuri
 
 == Prerequisites
 
-- See xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc[] for the minimum worker node, memory, CPU, and storage requirements.
+- See xref:deploy:redpanda/kubernetes/k-requirements.adoc[] for the minimum worker node, memory, CPU, and storage requirements.
 
 - Make sure that your physical or virtual machines have enough resources to give to Redpanda. To see the available resources on the worker nodes that you have provisioned:
 +
@@ -262,7 +262,7 @@ kubectl --namespace <namespace> get pod <pod-name> -o jsonpath='{.spec.container
 [[qos]]
 == Quality of service and resource guarantees
 
-IMPORTANT: Redpanda supports only clusters in which each broker has at least two CPU cores and the Pods that run Redpanda use the `Guaranteed` https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/[quality of service (QoS) class]. Clusters whose Redpanda Pods run in the `Burstable` or `BestEffort` QoS classes are not supported. For the full minimum requirements, see xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc[].
+IMPORTANT: Redpanda supports only clusters in which each broker has at least two CPU cores and the Pods that run Redpanda use the `Guaranteed` https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/[quality of service (QoS) class]. Clusters whose Redpanda Pods run in the `Burstable` or `BestEffort` QoS classes are not supported. For the full minimum requirements, see xref:deploy:redpanda/kubernetes/k-requirements.adoc[].
 
 To run Redpanda in the `Guaranteed` https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed[QoS class], match resource requests and limits on all containers in the Pods that run Redpanda.
 

modules/manage/pages/kubernetes/k-manage-topics.adoc

@@ -12,7 +12,7 @@ You must have the following:
 
 * *Kubectl*: Ensure you have the https://kubernetes.io/docs/tasks/tools/#kubectl[`kubectl`^] command-line tool installed and configured to communicate with your cluster.
 
-* *Redpanda*: Ensure you have the xref:deploy:deployment-option/self-hosted/kubernetes/kubernetes-deploy.adoc[Redpanda Operator and a Redpanda resource deployed] in your Kubernetes cluster.
+* *Redpanda*: Ensure you have the xref:deploy:redpanda/kubernetes/k-production-deployment.adoc[Redpanda Operator and a Redpanda resource deployed] in your Kubernetes cluster.
 
 == Limitations
 

modules/manage/pages/kubernetes/k-remote-read-replicas.adoc

@@ -1,8 +1,8 @@
 = Remote Read Replicas in Kubernetes
 :description: Create read-only topics (Remote Read Replica topics) that mirror topics on a different cluster.
-:page-categories: Management, High Availability
+:page-categories: Management, High Availability, Data Replication
 :env-kubernetes: true
 :tags: ["Kubernetes", "Helm configuration"]
-:page-aliases: manage:kubernetes/remote-read-replicas.adoc
+:page-aliases: manage:kubernetes/remote-read-replicas.adoc, manage:kubernetes/tiered-storage/k-remote-read-replicas.adoc, manage:kubernetes/storage/tiered-storage/k-remote-read-replicas.adoc
 
 include::manage:partial$remote-read-replicas.adoc[]

modules/manage/pages/kubernetes/k-resilience-testing.adoc

@@ -8,7 +8,7 @@ Resilience testing is an important part of ensuring that a system is reliable an
 
 == Prerequisites
 
-* Create a test environment that mimics your production environment as closely as possible. The test environment should include a Redpanda cluster with at least three replicas, and any services that your application depends on. You can find guides for deploying Redpanda in xref:deploy:deployment-option/self-hosted/kubernetes/get-started-dev.adoc[Get Started with Redpanda in Kubernetes].
+* Create a test environment that mimics your production environment as closely as possible. The test environment should include a Redpanda cluster with at least three replicas, and any services that your application depends on. You can find guides for deploying Redpanda in xref:deploy:redpanda/kubernetes/get-started-dev.adoc[Get Started with Redpanda in Kubernetes].
 * xref:./monitoring/index.adoc[Set up monitoring] so that you can observe changes in the system behavior.
 
 == Simulate failure scenarios

modules/manage/pages/kubernetes/k-rolling-restart.adoc

@@ -11,14 +11,14 @@ You should perform a rolling restart during operations such as configuration upd
 
 You must have the following:
 
-* xref:deploy:deployment-option/self-hosted/kubernetes/index.adoc[A Redpanda cluster running in Kubernetes].
+* xref:deploy:redpanda/kubernetes/index.adoc[A Redpanda cluster running in Kubernetes].
 * The default xref:reference:k-redpanda-helm-spec.adoc#statefulset-updatestrategy-type[RollingUpdate strategy] configured in the Helm values.
 
 == What happens during a rolling restart
 
 When you run Redpanda in Kubernetes, your Redpanda cluster is managed as a StatefulSet where each broker runs inside its own Pod. As a result, you can perform a rolling restart using the Kubernetes API to terminate one Pod at a time, starting from the one with the highest ordinal.
 
-During a rolling restart the xref:deploy:deployment-option/self-hosted/kubernetes/k-deployment-overview.adoc[Redpanda Helm chart] automates the following procedure on each broker, using the `preStop` and `postStart` lifecycle hooks:
+During a rolling restart the xref:deploy:redpanda/kubernetes/k-deployment-overview.adoc[Redpanda Helm chart] automates the following procedure on each broker, using the `preStop` and `postStart` lifecycle hooks:
 
 . The `preStop` hook is executed immediately before a container is terminated.
 The `preStop` hook is responsible for the following: