[DOC-1274][DOC-1275][2026.1][k8s] YBA Operator HA and new CRDs (PitrRestore, xCluster DR, Read replica) for Operator

docs/content/stable/yugabyte-platform/administer-yugabyte-platform/_index.md

@@ -42,6 +42,12 @@ For information on configuring alerts, health checks, and diagnostics reporting
     href="high-availability/"
     icon="fa-thin fa-clone">}}
 
+  {{<index/item
+    title="Operator high availability"
+    body="Synchronize Kubernetes Operator resources during YBA failover and failback."
+    href="operator-high-availability/"
+    icon="fa-thin fa-arrows-rotate">}}
+
   {{<index/item
     title="Manage runtime configuration settings"
     body="Customize YugabyteDB Anywhere by changing default settings for the application, universes, and providers."

docs/content/stable/yugabyte-platform/administer-yugabyte-platform/high-availability.md

@@ -30,6 +30,8 @@ Each HA cluster includes a single active YBA instance and at least one standby Y
 
 When you promote a standby instance to active, YBA restores your selected backup, and then attempts to demote the previous active instance to standby mode. If the previous active instance is unavailable, it has to be manually decommissioned.
 
+If you use the [YugabyteDB Kubernetes Operator](../anywhere-automation/yb-kubernetes-operator/) and deploy YBA across separate Kubernetes clusters, {{<tags/feature/ea idea="2460">}}[Operator HA](operator-high-availability/) synchronizes operator custom resources and secrets to the standby cluster during promotion.
+
 ## Prerequisites
 
 Before configuring a HA cluster for your YBA instances, ensure that you have the following:

docs/content/stable/yugabyte-platform/administer-yugabyte-platform/operator-high-availability.md

@@ -0,0 +1,81 @@
+---
+title: YugabyteDB Anywhere Operator high availability
+headerTitle: Operator high availability
+description: Extend YBA high availability to synchronize Kubernetes Operator custom resources across clusters
+headcontent: Synchronize operator-managed resources during YBA failover and failback
+linkTitle: Operator high availability
+menu:
+  stable_yugabyte-platform:
+    identifier: platform-operator-high-availability
+    parent: administer-yugabyte-platform
+    weight: 45
+type: docs
+---
+
+{{<tags/feature/ea idea="2460">}}YugabyteDB Anywhere (YBA) Operator high availability extends the [YBA high availability (HA)](../high-availability/) framework to synchronize Kubernetes Operator custom resources (CRs) and their associated secrets between active and standby YBA instances. This ensures that a standby YBA instance can resume management of operator-controlled universes after a failover, without requiring you to manually recreate CRs or secrets.
+
+## Integration with YBA HA
+
+Operator HA is a direct extension of the existing YBA HA framework. It uses the same asynchronous backup and restore mechanisms that replicate YBA management data between active and standby instances. Operator resources are included in those backups and restored automatically when a standby instance is promoted.
+
+Because Operator HA builds on the standard YBA HA path, improvements to YBA HA are automatically inherited by the operator, providing a unified experience for both platform state and operator-managed Kubernetes resources.
+
+## Prerequisites
+
+Before you can use Operator HA, ensure the following:
+
+- [YBA HA is configured](../high-availability/) between your active and standby instances.
+- The [YugabyteDB Kubernetes Operator](../../anywhere-automation/yb-kubernetes-operator/) is enabled on each YBA instance in the HA cluster.
+- Each YBA instance in the HA cluster can reach the Kubernetes API server for its local cluster.
+
+## Multi-cluster environments
+
+Operator HA is designed for deployments where YBA instances run on _separate Kubernetes clusters_. This is common in [Multi-Cluster Services (MCS)](../../configure-yugabyte-platform/kubernetes/#configure-kubernetes-multi-cluster-environment) environments.
+
+In a single-cluster deployment, both the active and standby YBA instances typically share access to the same Kubernetes control plane and the same CRs. Operator HA is not required in that scenario.
+
+In a multi-cluster deployment, a failover creates a management blackout: the standby YBA instance receives YBA platform state through HA backups, but the operator CRs and secrets that define and manage universes exist only on the primary cluster's Kubernetes API. Without Operator HA, the standby instance cannot manage those universes after promotion.
+
+Operator HA addresses this when:
+
+- YBA instances are deployed on entirely separate Kubernetes clusters.
+- The primary cluster goes offline and the standby YBA on a remote cluster must take over management of existing universes.
+- The standby instance needs immediate access to the CRs and secrets (such as kubeconfigs and certificates) used to create and maintain those universes.
+
+## What to expect on failover and failback
+
+You can expect a streamlined transition of management capabilities when a failover or failback is triggered.
+
+### During failover
+
+- Resource Synchronization: The standby node automatically imports and applies all necessary YAML definitions for Operator CRs and their associated secrets (such as Kubeconfigs and certificates) to its local Kubernetes API.
+
+- State alignment: The system applies "force/replace" logic to ensure the new active instance's state matches the latest source of truth from the backup, avoiding inconsistencies.
+
+- Operator Activation: After operator resources are successfully applied, the standby YBA service activates its operator thread, and resumes management of the infrastructure. You do not need to manually recreate CRs or re-import universes.
+
+For general failover steps, see [Promote a standby instance to active](../high-availability/#promote-a-standby-instance-to-active).
+
+### During failback
+
+When you fail back to the original primary, Operator HA keeps operator resource state consistent across both clusters.
+
+- Spec Consistency: When you fail back to the original primary, Operator HA ensures that any edits made while the standby was active are synchronized back to the original primary. This prevents specifications from being rolled back to an outdated state.
+
+- Lifecycle management: If a CR was deleted during the failover period, the system recognizes this state and ensures the resource is not incorrectly recreated upon failback.
+
+## Supported resources
+
+The HA mechanism tracks and transfers all critical YBA Operator resources, including the following:
+
+- Universes and providers.
+- Backup, scheduled backup, and PITR configurations.
+- Storage configurations and YugabyteDB certificates.
+- Referenced Kubernetes secrets containing credentials and tokens.
+
+For details on each CR type, see [YugabyteDB Kubernetes Operator CRDs](../../anywhere-automation/yb-kubernetes-operator/#yugabytedb-kubernetes-operator-crds).
+
+## Learn more
+
+- [Enable high availability](../high-availability/)
+- [YugabyteDB Kubernetes Operator](../../anywhere-automation/yb-kubernetes-operator/)

docs/content/stable/yugabyte-platform/anywhere-automation/yb-kubernetes-operator.md

@@ -18,7 +18,7 @@ The Operator establishes `ybuniverse` as a Custom Resource Definition (CRD) in K
 
 You can define and update these custom resources to manage your universe's configuration, including granular resource specifications (CPU and memory for Masters and TServers) and precise regional/zonal placement policies to ensure optimal performance and high availability. Custom resources support seamless upgrades with no downtime, as well as automated, transparent scaling, and cluster-balanced deployments.
 
-{{<tags/feature/ea idea="2004">}}You can additionally convert Kubernetes universes that are managed via Helm charts to be managed by the YugabyteDB Kubernetes Operator, using the `operator-import` API. See [Import universe](#import-universe).
+You can additionally convert Kubernetes universes that are managed via Helm charts to be managed by the YugabyteDB Kubernetes Operator, using the `operator-import` API. See [Import universe](#import-universe).
 
 ![YugabyteDB Kubernetes Operator](/images/yb-platform/yb-kubernetes-operator.png)
 
@@ -907,7 +907,7 @@ spec:
 
 ## Import universe
 
-{{<tags/feature/ea idea="12874">}} Available in YugabyteDB Anywhere v2025.2.2 and later.
+Available in YugabyteDB Anywhere v2025.2.2 and later.
 
 Use the operator import universe feature to import existing YugabyteDB Anywhere Kubernetes universes that are managed via Helm charts to be managed by the Kubernetes Operator.
 
@@ -919,7 +919,7 @@ Currently, universes with any of the following configurations are not supported
 
 ### Before you begin
 
-- Install the operator. The operator must be enabled on your instance. See [Installing Kubernetes Operator](#installing-kubernetes-operator).
+- Install the operator. The operator must be enabled on your instance. See [Install Kubernetes Operator](#install-kubernetes-operator).
 - Verify namespace configuration.
   - If the operator is configured to watch a single, specific namespace, the namespace provided in the import payload must match that runtime configuration (for example, `yb.kubernetes.operator.namespace`).
   - If the operator is not watching a specific namespace, the payload should be the namespace you want the resources to be created in.
@@ -986,6 +986,12 @@ Importing a universe to the operator creates or adopts the following in the targ
 - Storage configurations related to the backups or backup schedules, including secrets to access the storage configuration.
 - Release, including secrets to access the release.
 
+## Operator high availability
+
+{{<tags/feature/ea idea="2460">}}If you deploy YBA across separate Kubernetes clusters with [YBA high availability](../../administer-yugabyte-platform/high-availability/) enabled, Operator HA synchronizes operator CRs and their associated secrets to the standby cluster during failover and failback. This lets the standby YBA instance resume management of operator-controlled universes without manually recreating resources.
+
+For details, see [Operator high availability](../../administer-yugabyte-platform/operator-high-availability/).
+
 ## Limitations
 
 - YugabyteDB Kubernetes Operator can only deploy universes on the _same_ Kubernetes cluster it is deployed on.