Multi-Cluster Fleet Management, Disaster Recovery & Security
The layer that holds every other cluster type together: fleets that deploy the same way everywhere, DR that has been rehearsed, and security that produces evidence.
What this usually looks like
You have more than one cluster, more than one site, and a security questionnaire you cannot yet answer.
- Clusters were stood up at different times by different people, and they are all subtly different.
- A disaster recovery plan exists as a document nobody has executed.
- Access is broad because narrowing it might break something nobody understands.
- A customer sent a security questionnaire and it is now someone's whole week.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Fleet consistency review across clusters and sites
- DR readiness test: restore a service in an isolated environment, timed
- Access review: who can do what, and whether it is still justified
- Security evidence gap analysis against the framework you are asked about
Build
One-off delivery: design, code, hardening, handover
- Fleet management (Karmada, Rancher Fleet, Argo CD ApplicationSet, Cluster API) with governance in Git
- Velero backup and restore across clusters, with scheduled restore testing
- Dual-site architecture with a witness/arbiter design where sync replication is required
- Secrets management (Vault) with rotation and audit trails
- Supply-chain controls: image signing (Cosign/Sigstore), SBOM generation (Syft/Grype), policy admission (Kyverno)
- Zero-trust networking between sites (WireGuard, Tailscale, NetBird)
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Quarterly DR drill, executed, with a written report and measured RTO/RPO
- Fleet drift detection and remediation, reported
- Vulnerability and SBOM review on a schedule
- Access recertification support for your auditors
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Fleet management
- Karmada
- Rancher Fleet
- Argo CD ApplicationSet
- Cluster API
- Open Cluster Management
- Spoke/agent architectures
Backup & DR
- Velero
- Kasten K10 (evaluation)
- etcd snapshot tooling
- pgBackRest / WAL-G off-site
- ZFS send/recv off-site
- dual-site witness design
Secrets & identity
- HashiCorp Vault
- External Secrets Operator
- SOPS + age
- SPIFFE / SPIRE
- OIDC + Keycloak
- RBAC audits
Supply chain
- Cosign / Sigstore
- Syft / Grype
- Trivy
- Falco
- OpenSCAP
- Kyverno policy enforcement
Network security
- WireGuard
- Tailscale
- NetBird
- zero-trust segmentation
- mTLS everywhere
- network policies as code
Compliance evidence
- CIS Benchmark / kube-bench
- auditd
- immutable audit logs
- SBOM deliverables
- access recertification reports
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- A DR drill completed with real RTO and RPO numbers, delivered quarterly.
- Every cluster in the fleet configurable from a single Git source of truth.
- Secrets rotated on a schedule with an audit trail of every access.
- Container images verified by signature at admission — unsigned images do not run.
- Audit evidence produced as a repeatable artifact, not assembled by hand each time.
What we would build, and where the weak point is
The fleet controller is a single point of failure for changes, though not for serving traffic. That distinction matters: if it dies, existing clusters keep running, but nothing new deploys until it is restored.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Out of scope
Acting as your compliance auditor or issuing certifications
We produce evidence and implement controls. Independent certification comes from an accredited auditor.
- Out of scope
Legal interpretation of CCPA, GDPR, HIPAA or PCI requirements
We implement controls you or your counsel specify. We do not give legal advice and will not pretend to.
- Requires partner
SIEM operations and 24×7 security monitoring as a SOC
We build detection infrastructure and integrate with your SIEM or MSSP. We do not operate a security operations centre.
- Requires partner
Incident response as a digital forensics firm
We do infrastructure containment and evidence preservation, and we will introduce a forensics partner when the situation requires one.
What it looked like last time
A multi-site Kubernetes fleet with no tested recovery: Velero-based restore plus a witness-arbiter design, and a first drill that recovered a full production namespace to a secondary site in 23 minutes — a number the customer had previously estimated at "probably a few hours".
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the security & reliability engineer about your fleet, dr & security
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a security & reliability engineer: botonwa@gmail.com · +86 130 5181 3099