如何在 Kubernetes 中运行数据库
内容提要
在Kubernetes中运行数据库的争论一直存在。使用节点选择器和单独的节点组或节点池可以实现成功运行数据库。在Kubernetes中实现高可用性需要精心规划恢复和可用性策略。备份和恢复可以使用磁盘卷的定期快照或数据库的专有工具。在决定在哪里运行生产数据库之前，需要权衡利弊。
延伸解读
可用区约束与节点规划
在大多数云平台上，持久卷通常只能挂载到单一可用区，这直接限制了数据库 Pod 的调度范围。文章建议使用节点选择器将数据库 Pod 固定到卷所在的可用区，并为数据库工作负载创建独立的节点组或节点池，配合污点和容忍度，避免因资源不足导致调度失败或不可用。
高可用实现的两种路径
托管数据库服务通常内置高可用和故障转移，而在 Kubernetes 中需要自行规划。文章给出两种方式：一是使用 Kubernetes Operator（如 Zalando Postgres Operator），可配置只读副本并自动故障转移；二是针对 NoSQL 的手动方案，通过 Pod 亲和性、init 容器复制数据、只读挂载和定时重启来维持副本。
备份恢复的权衡
备份方面，文章提到许多服务商支持对磁盘卷进行定期快照，这种方式设置简单且恢复更快，是更受推荐的做法。另一种方式是结合数据库专有工具，例如用 pg_dump 配合 CronJob 备份到 S3。选择时需权衡恢复速度与操作复杂度。
成本与供应商无关性
文章指出，在 Kubernetes 中运行数据库的一个不常被提及的优势是成本。例如，RDS 上 db.m4.2xlarge 实例每月约 1200 美元，而类似规格的 EC2 实例约 150 美元，且一个节点可运行多个 Pod 进一步优化资源。此外，供应商无关性使得工作负载能跨平台迁移，但需权衡初始学习曲线和运维复杂度。
Q&A
在Kubernetes中运行数据库的主要争论是什么？
主要争论是数据库应作为云服务管理，还是可以在Kubernetes中成功运行。
如何确保数据库Pod位于正确的可用区？
可以使用节点选择器来确保数据库Pod位于其卷可以挂载的可用区。
在Kubernetes中实现高可用性数据库需要哪些策略？
需要精心规划恢复和可用性策略，可以使用Kubernetes Operators或手动方法实现高可用性。
使用Kubernetes Operators有什么优势？
Kubernetes Operators可以简化高可用性数据库的设置和管理，提供自动故障转移等功能。
如何在Kubernetes中备份数据库？
可以使用服务提供商的定期快照功能，或结合数据库的专有工具进行备份。
在Kubernetes中运行数据库的成本效益如何？
在Kubernetes中运行数据库的成本通常低于使用云服务，例如EC2实例的费用远低于RDS。
