在生产环境中将 Kubernetes 用于 MySQL 等集群数据库是否合理？
有mysql galera example等示例配置。但是，大多数示例都没有使用持久卷。据我了解，持久卷必须驻留在此处定义的某个共享文件系统上Kubernetes types of persistent volumes。共享文件系统不能保证 pod 的数据库文件在托管 pod 的机器上是本地的。它将通过相当慢的网络访问。此外，例如 MySQL 和 NFS 也存在问题。
这对于测试环境来说可能是可以接受的。但是，我应该在生产环境中做什么？在 Kubernetes 之外运行数据库集群并在 Kubernetes 中只运行应用程序服务器会更好吗？
【问题讨论】：
标签： mysql database kubernetes production-environment
Kubernetes 项目引入了PetSets，这是一种新的 pod 管理抽象，旨在运行有状态的应用程序。 目前是一个 alpha 功能（从 1.4 版开始）并且发展迅速。列表中列出了我们进入测试版时的各种问题here。引用when to use petsets上的部分：
PetSet 确保指定数量的具有唯一身份的“宠物”在任何给定时间运行。宠物的身份包括：
除了上述之外，它还可以与其他几项功能相结合，帮助您部署和管理集群状态应用程序。例如，与dynamic volume provisioning 结合使用，可用于自动配置存储。
有几个 YAML 配置文件可用（例如您引用的那些），它们使用 MySQL 和其他数据库的 ReplicaSets 和 Deployments，它们可能在生产环境中运行，也可能以这种方式运行。但是，PetSet 有望让运行这些类型的工作负载变得更加容易，同时支持升级、维护、扩展等。
您可以找到一些带有宠物集here 的分布式数据库示例。
供应联网和非本地（例如 GlusterFS）的持久卷的优势是大规模实现的。但是，对于相对较小的集群，有一个建议允许将来使用local storage persistent volumes。
【讨论】：