Multi-cluster

Satusky can coordinate deployments across multiple Kubernetes clusters while keeping one control plane and one PostgreSQL metadata store.

Core model

single Satusky API + PostgreSQL
          │
          ├── Cluster A
          └── Cluster B

The clusters are not peer control planes. The Satusky API fans out desired state to each cluster and aggregates runtime observations back upward.

Modes

Mode	Meaning	Best for
Active-active	Multiple clusters serve traffic	latency and resilience for stateless workloads
Active-passive	Primary serves traffic, secondary is warm	disaster recovery

What is shared versus per-cluster

Shared	Per cluster
desired deployment metadata	pods and Services
organization identity	route objects
deployment history	PVCs
multi-cluster config	local health / capacity

Statefulness

Persistent volumes are zone-local. A PVC in one cluster is not magically shared with another cluster. Multi-cluster stateful apps need explicit replication or an external/shared data plane such as object storage.

Backups

The CLI exposes backup-related deployment flags for multi-cluster workflows. The architecture should treat backup configuration as part of the workload spec, but not confuse “backup configured” with “cross-cluster state automatically consistent.”

Relationship to SideroLink

SideroLink is machine-management connectivity, not the user workload data plane. Multi-cluster traffic strategy still depends on routing, DNS, edge load balancing, and application design.

Current gaps and target direction

Gap	Target
Public routing and failover semantics are not yet documented with the same precision as single-cluster deploys.	Define how DNS, LB health, and failover states are exposed to users.
Stateful behavior is partly product policy, partly app responsibility.	Make the boundary explicit per storage type.
Machine pools and cluster placement are converging concepts.	Future selector-based placement should compose with cluster/zone strategy rather than creating parallel scheduling languages.