Best Practices for Running Databases on Kubernetes
summary
Argues Kubernetes is ready for databases if you apply concrete practices: use Percona Operators to automate replication, failover, backups and lifecycle; store data on persistent volumes (cloud EBS for reliability or local disks for speed) and keep data per pod small — single‑terabyte volumes are realistic while 50+TB single pods are operationally unsafe; enforce anti‑affinity, matched requests and limits, pod priority, encryption, and regular backups including binary log shipping to S3 for near‑point‑in‑time restores.
AI-written summary · about
chapters (9)
- 0:00Introduction and welcome
- 4:14Why run databases on Kubernetes
- 8:11Kubernetes best practices for databases
- 16:41High availability and anti-affinity rules
- 23:07Security and backups for databases
- 26:44Modern cloud-native databases
- 27:47CPU choices and node sizing
- 31:00Percona tools for Kubernetes
- 35:55Q&A session
related talks
25mAre Containers Ready for Production Databases?
34mDatabases on Kubernetes
45mDatabases on Kubernetes: Why you should care
08mLightning Talk: Should You Run Your Database on Kubernetes
47mFrom a Database in Container to DBaaS on Kubernetes
26mChallenges of Managing Stateful Applications in Kubernetes
31mOpen Source Databases on Kubernetes: Best Practices
25mPostgres on Kubernetes for the Reluctant DBA