翻译 | Kubernetes 将改变数据库的管理方式

作者：Álvaro Hernández

当技术决策人考虑在 Kubernetes 上部署数据库时，面临的第一个问题就是：“Kubernetes 有应对有状态服务的能力吗？”多年来的答案都是“不建议”，而且理由充分。毕竟，Kubernetes 最初的设计便是用于处理无状态服务的容器编排。如今，有状态服务的相关技术已经相当成熟，是时候重新考虑在 Kubernetes 上运行数据库了。

实现数据库容器化，还需要从三个重要的技术角度来考虑：

1. Kubernetes 本身的技术成熟度
2. Kubernetes 处理有状态服务的能力

3. 容器中运行数据库的可用性和性能

   Kubernetes 技术有多成熟？

虽然评估任何一项技术的成熟度都不是一个简单的过程，但还是可以依靠一些数据来推证的。

Kubernetes[1] 是 CNCF 基金会[2] 的毕
业项目，目前该技术很流行，且有很多的项目参与者。据 CNCF 2020 年的云原生调查报告[3] 显示，“91% 使用容器技术的受访者使用 Kubernetes，其中 83% 是在生产环境中使用。”

自 2017 年 11 月以来，知名分析公司 Thoughtworks[4] 一直将 Kubernetes 作为必须采用的技术之一，并解释说，“在将容器部署到集群中时，它已成为我们大多数客户的默认解决方案。”

图片来自 CNCF

Kubernetes 处理有状态服务的能力如何？

Kubernetes 的有状态功能经常受到质疑，第一代有状态技术 Persistent Set（简称“PetSet”）也（部分）受到了指责。这个特性被弃用后，取而代之的是 Kubernetes 有状态技术：StatefulSets[5]。2018 年 GA 版本发布，如今为无数的 Kubernetes 容器提供持久、非短暂存储的解决方案，同时也为 Vitess[6] 或其他云原生数据库提供了在 Kubernetes 中部署的可能性。

最值得注意的是，StatefulSets 将 PersistentVolumes（PV）装载到容器中。这些 PV 通常由 Kubernetes 节点外部的存储提供，可以是网络或软件定义的存储解决方案，如 OpenEBS。本质上，Kubernetes 和云上使用的存储与 AWS 上使用的 EBS 卷或 GCP 上使用的持久磁盘相同。

Kubernetes 上运行数据库的性能如何？

无疑，Kubernetes 上运行数据库性能会受到影响。容器被错误地视为“轻量级虚拟机”它们是相当轻量的抽象层，包裹着 Linux 内核提供的文件系统、进程和网络空间。如果只使用短暂的容器存储数据，可能会有一些开销。但如果使用外部 PV 存储，开销可以忽略不计。

那么容器的临时性不会影响高可用性吗？由于容器只是对进程的“包装”，它们的生命周期与进程的生命周期有关。换句话说，容器将和其中运行的数据库进程一样稳定。

Kubernetes 彻底改变了数据库的运行方式

在 Kubernetes 上运行数据库有明显的优势：部署简单，整个堆栈由同一个编排工具管理，自动修复，以及自动重新部署失败的容器，从而提高可用性。例如，如果运行数据库的其中一个节点出现故障，Kubernetes 将自动进行自我修复，重新安排另一个节点上的工作负载。通过与数据库管理软件的合作，它可以选择一个在以前存在的复制副本上运行的新数据库主节点，并将新节点重新初始化为一个新的复制副本，这一切都是自动的。但还有其他更重要的原因让你想在 Kubernetes 中运行数据库。

大多数公司希望将数据库作为 DBaaS（数据库即服务）进行操作。自我配置自愈数据库，包括备份和监视。虽然这是功能大多数云厂商也提供，但通过使用 Kubernetes 自己动手可以节省大量成本，并提供额外的功能，如多云和云可移植性。

这些功能可以通过 Kubernetes Operator[7] 来提供。Operator 是 Kubernetes 的特定于应用程序的扩展，它对部署和操作自动化进行编码，同时向用户公开简单的界面。高级的数据库 Operator 带来了以下好处：

• 这是一种用于部署和更新的声明性方法，使其对 GitOps 100% 友好，非常适合任何使用 CI/CD 的公司。操作员定义的 CRD（自定义资源定义）是高级对象，通常作为简单的 YAML 文件接口，允许以简单的方式部署和管理复杂的数据库架构。
• “Day-2 Operation”[8] 自动化：部署、高可用性、备份和监控；修复、清理、重新编制索引等。操作员可以将这些操作编码到 CRD、YAML 文件中，以便自动执行这些操作。
• 将数据库功能外部化到第三方、知名的 Kubernetes 组件，如 Envoy Proxy；Prometheus 和 Grafana 负责监控；或 Cert Manager 用于 SSL 证书管理。数据库 Operator 可以依赖这些组件来分离部分数据库功能，减少用户操作难度，因为它更熟悉更易获得更高级的功能。
  正如 Goldman Sachs、Zalando 和 Flipkart 等领先公司所表现的那样，在 Kubernetes 上运行数据库不仅是未来，也是现在。与任何技术一样，在部署生产工作负载之前，应该进行仔细和客观的评估。

在 Kubernetes 2021 调查报告[9] 中发现，90% 的公司认为 Kubernetes 已经准备好了应对有状态的工作负载。这些受访企业中的绝大多数（70%）在生产中运行有状态的工作负载，其中数据库排在首位。75% 的受访企业生产率提升两倍甚至更高！

鉴于以上的数据和优势，企业应该去考虑一下。在 Kubernetes 上运行数据是全面协调基础设施的最新前沿，我相信这一转变将为企业带来可观的价值。

原文：https://thenewstack.io/kubernetes-will-revolutionize-enterprise-database-management/

引用参考:

1. Kubernetes：https://thenewstack.io/catego...
2. CNCF 基金会：https://cncf.io/?utm_content=...
3. 云原生调查报告：https://www.cncf.io/wp-conten...
4. Thoughtworks：https://www.thoughtworks.com/...
5. StatefulSets：https://kubernetes.io/docs/co...
6. Vitess：https://vitess.io/
7. Kubernetes Operator：https://kubernetes.io/docs/co...
8. Day-2 Operation：https://jimmysong.io/blog/wha...
9. Kubernetes 2021 调查报告：​https://dok.community/dokc-20...