When Clusters Collide: The Misadventures of Disaster Recovery in K8s
summary
Claims Kubernetes DR is deceptively tricky and shows a concrete two‑region EKS setup with a working failover pattern: two clusters, ExternalDNS and cert‑manager, Route53 CNAME switching with short TTL, and a single TLS secret issued with multiple SANs so the main hostname validates. For volumes it demos backup and replication options like Velero or Portworx. Notes practical pitfalls: cannot duplicate the same Ingress, manifest and image registries must be reachable, and monitoring and auth need DR testing — chaos engineering is required.
AI-written summary · about
chapters (12)
- 0:00intro
- 0:14introduction to cluster collision
- 0:42challenges in kubernetes disaster recovery
- 2:26setting the stage for disaster recovery
- 2:50simple stateless deployment example
- 3:41handling incoming traffic and dns management
- 4:56persistent volumes and data replication
- 6:00self-service dns and certificates
- 7:19routing traffic and certificate issues
- 12:28comprehensive dr configuration
- 13:10final thoughts and best practices
- 14:59conclusion and q&a
related talks
30mIs Your Kubernetes Disaster Recovery Actually Ready?
46mKubernetes Stateful Application Disaster Recovery with Zero Data Loss
35mDisaster Recovery of Stateful Applications in a Multi-Cluster Environment
06m⚡ Lightning Talk: Disaster Recovery - How IaCaC and Kubernetes Enables Cost Efficiency and Fast Recovery
01h 00mApplication resilience in Kubernetes... certainty even before your DRP?
45mKubernetes Resiliency
31mThe Myth of the Monocluster
41mKubernetes the Very Hard Way