--- title: Intended Audience product: trilio-site-recovery-for-kubernetes doc_type: concept version: 0.2.0 source: git2docs (code-derived, validation-filtered) canonical: https://docs-tsr.trilio.io/trilio-site-recovery-for-kubernetes/site-recovery/intended-audience --- # Intended Audience _Who should use this operator and what Kubernetes knowledge is required_ ## Overview This page describes who Trilio Site Recovery is designed for, what background knowledge you need to use it effectively, and what operational responsibilities it addresses. Understanding whether this product fits your role and environment helps you decide where to start and which workflows apply to your deployment. ## Content ## Who This Product Is For Trilio Site Recovery is built for **platform engineers and site reliability engineers (SREs)** who are responsible for the availability and recoverability of KubeVirt virtual machine workloads running on OpenShift clusters. If you design, operate, or are accountable for disaster recovery (DR) plans for virtualized workloads on Kubernetes, this product is intended for you. It is not a general-purpose backup tool and does not address application-level data consistency beyond what lifecycle hooks provide. It is also not a self-service tool for application developers — the workflows it exposes (cluster registration, protection policy definition, failover execution) require cluster-level access and an understanding of Kubernetes storage and networking. ## What Operational Problems It Addresses Trilio Site Recovery automates the replication and failover of KubeVirt `VirtualMachine` objects and their persistent volumes across two geographically separate OpenShift clusters. Without a tool like this, recovering a virtual machine after a site outage typically involves manual steps: identifying which volumes need to be restored, promoting a standby replica, reconfiguring network identity, and restarting workloads in the correct order. Site Recovery replaces that runbook with declarative Kubernetes custom resources that can be driven by `kubectl`, GitOps tooling, or the TSR web console. Specifically, Site Recovery addresses: - **Continuous block-level replication** — DRBD Protocol C synchronous replication keeps a mirror of every protected VM's persistent volumes on the DR cluster. Because replication is synchronous, RPO is always zero: no writes are acknowledged on the primary until both sides confirm. - **Coordinated failover** — A `FailoverRequest` custom resource triggers a planned or unplanned failover of all VMs in a `ProtectionGroup` to a specified target cluster. Every failover is initiated explicitly; nothing happens automatically. - **Non-disruptive DR validation** — A `TestFailover` custom resource spins up isolated copies of protected VMs on the standby cluster using DRBD snapshots, inside a network-fenced namespace, without touching production VMs. - **Credential and access management** — Zone credentials (kubeconfig Secrets) that grant the TSR-Manager orchestration access to each workload cluster are managed exclusively through the `tsrctl` CLI, with rotation and RBAC refresh supported without downtime. - **Observability** — `ReplicationGroupStatus` and `RPOEvent` custom resources aggregate per-VM DRBD metrics and emit immutable audit records on every replication status transition, giving you a compliance-ready history of replication health. ## Required Kubernetes Knowledge This product assumes intermediate Kubernetes proficiency. You should be comfortable with the following before working through the installation and operations workflows: - **Custom Resource Definitions and `kubectl`** — All DR operations are declared through CRDs in the `siterecovery.trilio.io/v1alpha1` API group. You apply, patch, and inspect these resources with `kubectl` the same way you would any other Kubernetes object. If you have not worked with CRDs before, review the upstream Kubernetes documentation on custom resources first. - **Namespaces and RBAC** — Site Recovery places TSR-Manager-side resources (ProtectionZone, ProtectionGroup, ProtectionRequest, and related CRs) in a dedicated `dr-` namespace on the TSR-Manager cluster. Workload-side components (the workload control plane and DRBD node agent DaemonSet) are installed into `trilio-site-recovery-system` on each workload cluster. You need cluster-admin or equivalent access to both sets of clusters to install and configure the operator. - **Persistent Volumes and Storage Classes** — Site Recovery works at the block level. It provisions DRBD-backed frontend PVCs for each protected VM's disks and requires you to supply storage class mappings between the primary and DR clusters as part of zone configuration. Understanding how PVCs, PVs, and StorageClasses relate is essential for diagnosing replication and protection failures. - **DaemonSets and node taints** — The `drbd-node-agent` DaemonSet runs one pod per worker node on each workload cluster and manages DRBD kernel state on that node. During startup, it applies a `siterecovery.trilio.io/not-ready:NoSchedule` taint to its node until DRBD converges. You should understand how DaemonSets are scheduled and how node taints interact with workload placement. - **OLM (Operator Lifecycle Manager)** — On OpenShift, Site Recovery is installed through OLM using a `CatalogSource`, `OperatorGroup`, and `Subscription`. Familiarity with how OLM manages operator lifecycle and upgrades will help you understand what the operator controls and what it does not. - **KubeVirt** — The objects being protected are KubeVirt `VirtualMachine` resources. You should understand the relationship between a `VirtualMachine`, its `VirtualMachineInstance`, and the PVCs that back its disks. Note that live migration and cold migration of protected VMs are denied by admission webhooks for the lifetime of a protection, and draining a node that hosts a running protected VM will not complete. ## OpenShift Requirement Trilio Site Recovery is designed and validated for **OpenShift 4.17 and later** for the TSR-Manager cluster and both workload clusters. The DRBD node agent relies on the OpenShift privileged Security Context Constraint (SCC), and the TSR web console is accessible only on OpenShift through an oauth-proxy Route created automatically by the ProtectionZone controller. Upstream Kubernetes workload clusters are supported on versions corresponding to OpenShift 4.17 and later, but several capabilities — SCC-based node agent admission, the web console Route, and reliable test-failover network isolation — are OpenShift-specific and are not available or not validated on upstream Kubernetes. RHEL CoreOS 9 nodes are the validated node distribution for workload clusters in this Tech Preview release. RHEL CoreOS 10 nodes are not validated. ## Topology Responsibility Site Recovery requires you to provision and maintain three separate Kubernetes clusters: - A **TSR-Manager cluster** — the dedicated management cluster that hosts all orchestration controllers, stores zone credentials, and holds all TSR-Manager-side custom resources. It runs no VM workloads and carries no DRBD replication traffic. - A **primary (active) workload cluster** — where KubeVirt VMs run under normal operating conditions. - A **DR (standby) workload cluster** — where standby DRBD replicas are maintained and to which VMs are failed over during a DR event. Provisioning these clusters, ensuring network connectivity between primary and DR worker nodes on TCP ports 7000–8000 inclusive (one port per replicated VM volume, with port 8000 mandatory), and maintaining round-trip latency below 10 ms between workload clusters for synchronous replication are your responsibility before installing Site Recovery. ## Tech Preview Status This is the initial Tech Preview release of Trilio Site Recovery. All components — including the TSR web console — are Tech Preview. No component has reached general availability. You should factor this into your evaluation and deployment planning. ## Examples The following example shows how to verify that your `kubectl` context is pointed at the correct cluster before running any Site Recovery commands. All TSR-Manager-side resources live in a `dr-` namespace on the TSR-Manager cluster; running the same command against a workload cluster returns an empty list because those CRDs are not registered there. ```bash # Confirm you are targeting the TSR-Manager cluster kubectl config current-context # List all ProtectionZones on the TSR-Manager cluster kubectl get pz -A ``` The following example shows how to confirm that workload-side components are installed in the correct namespace on a workload cluster. ```bash # Confirm the workload control plane is running on a workload cluster kubectl get pods -n trilio-site-recovery-system \ -l app.kubernetes.io/part-of=site-recovery # Confirm the DRBD node agent DaemonSet is present kubectl get daemonset -n trilio-site-recovery-system \ -l app.kubernetes.io/component=drbd-node-agent ``` The following example shows how to inspect a ProtectionZone's validation status. The `ClustersValidated` condition must be `True` before the TSR-Manager admission webhooks will accept new `ProtectionGroup` or `ProtectionRequest` creates. ```bash # Inspect the ClustersValidated condition on a zone named "zone-prod" # (run against the TSR-Manager cluster, in the dr-zone-prod namespace) kubectl get pz zone-prod -n dr-zone-prod -o jsonpath='{.status.conditions}' | \ python3 -m json.tool ``` ## Related concepts - **Install and configure the control plane** — Covers the OLM-based installation path (CatalogSource, OperatorGroup, Subscription) and the subsequent ProtectionZone CR that triggers automated workload control plane deployment. - **Provision zone credentials** — Explains how `tsrctl zone-credential create` mints the kubeconfig Secrets that grant the TSR-Manager orchestration access to each workload cluster, and how to rotate them. - **Create a ProtectionZone** — Describes the top-level configuration object that registers a primary and DR workload cluster pair with the TSR-Manager and validates cluster reachability, identity, and RBAC. - **Protect a virtual machine** — Walks through creating a `ProtectionRequest` to bring a KubeVirt VM under DRBD replication and reach the `Protected` phase. - **Monitor replication health** — Explains `ReplicationGroupStatus` and `RPOEvent` custom resources, and how to use them to assess replication health and SLA compliance. - **Run a test failover** — Covers `TestFailover` CRs and the isolated test namespace created on the standby cluster for non-disruptive DR validation. - **Execute a planned failover** — Describes creating a `FailoverRequest` with `failoverType: planned` to perform a graceful, zero-data-loss role flip. - **Execute an unplanned failover** — Describes creating a `FailoverRequest` with `failoverType: unplanned` for RTO-optimized forced promotion when the primary site is unavailable. - **Collect a support bundle** — Explains how to run `oc adm must-gather` with the `site-recovery-must-gather` image on the TSR-Manager cluster to collect logs, CRs, and DRBD state from the entire estate.