System Architecture

Editable source: architecture.excalidraw

Testudo has five layers: entry points, API aggregation, Kubernetes API and CRDs as the source of truth, the operator execution layer, and runtime dependencies.

Entry Layer

Users manage disaster recovery objects from the web console, CLI, automation systems, or direct REST API calls. User-facing writes are converted into Kubernetes CRD creates, updates, or deletes.

API Aggregation Layer

disaster-server provides:

• Authentication and JWT middleware.
• Business REST APIs under /apis/....
• Compatibility aliases under /api/....
• Watch routes for instances, groups, operations, clusters, and events.
• Statistics and event aggregation APIs.
• Frontend-friendly DTOs.

The server does not execute disaster recovery actions directly. It writes intent into CRDs and reads CRD status, Kubernetes Events, and statistics resources.

Kubernetes API And CRDs

Kubernetes API is the source of truth. Server writes desired state into CRDs. Operator writes status, conditions, history, and Events back to the same control plane.

Operator Execution Layer

disaster-operator watches testudo.softcdata.com/v1 resources and reconciles:

• DisasterInstance
• DataSync
• ResourceSync
• AppBackup and AppRestore
• DisasterOperation
• DisasterGroup
• DisasterDrill
• Cluster and StorageRepository

Runtime Dependencies

The operator accesses remote clusters through kubeconfig or token-based credentials, drives Velero Backup and Restore resources, and stores backup artifacts in S3-compatible object storage such as MinIO.

Data Flow

1. A user creates a DisasterInstance.
2. disaster-server validates the request and writes the CRD.
3. disaster-operator observes the instance and aligns DataSync and ResourceSync.
4. Sync controllers create AppBackup and AppRestore, which drive Velero resources.
5. Status, events, history, and statistics are written back.
6. Server streams the result to the web console through REST and Watch APIs.