Upgrade Your Vault Using Failover
summary
Upgrade uses a passive region to test a new Vault version before cutting over so production keeps running. Cluster architecture is two regional HA clusters (east/west), upgrade the passive cluster from 1.0.3 to 1.2.7, exercise logins and tokens, then flip DNS to make that cluster active, upgrade the other cluster, and optionally flip back. Uses Kubernetes Helm changes to replicas and image, automatic unseal, and an in‑house deploy tool. Backups use Google Cloud Storage and Data Transfer, rollback requires restoring storage and downgrading with a small downtime. Helm values change GCS backup and restore
AI-written summary · about
chapters (8)
- 0:00Introduction
- 3:02Upgrade concepts
- 5:43Architecting for failover
- 7:46Configuration
- 13:27Upgrade procedure
- 19:51Rollback strategy
- 22:18Live demo
- 27:33Conclusion
related talks
23mHashiCorp Vault and Getting Day 2 Operations Right
25mRecapping HCP Vault and the Path Ahead
27mVault Futures: The Roadmap Ahead for Vault
29mAdopting HashiCorp Vault: Deployment, Adoption, and Beyond
29mAutomating Vault deployments: Patterns, pitfalls, and practical lessons
23mManaging Vault with Terraform
25mAutomating Kubernetes Upgrades for Zero Downtime
06mNever ever upgrade