作者：Álvaro Hernández
当技术决策人考虑在 Kubernetes 上部署数据库时，面临的第一个问题就是：” Kubernetes 有应对有状态服务的能力吗？“多年来的答案都是” 不建议“，而且理由充分。毕竟，Kubernetes 最初的设计便是用于处理无状态服务的容器编排。如今，有状态服务的相关技术已经相当成熟，是时候重新考虑在 Kubernetes 上运行数据库了。
要实现数据库的容器化，还需要从三个重要的技术角度考虑：
[En]
To achieve database containerization, you also need to consider from three important technical perspectives:
- Kubernetes 本身的技术成熟度
- Kubernetes 处理有状态服务的能力
- 容器中运行数据库的可用性和性能
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 存储，开销可以忽略不计。
因此，容器的临时性不会影响高可用性？因为容器只是“包装”过程，所以它们的生命周期与过程的生命周期有关。换句话说，容器将与在其中运行的数据库进程一样稳定。
[En]
So the temporary nature of the container will not affect high availability? Because containers are only “packaging” processes, their life cycle is related to the life cycle of the process. In other words, the container will be as stable as the database process running in it.
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/
引用参考:
- Kubernetes：https://thenewstack.io/category/kubernetes/
- CNCF 基金会：https://cncf.io/?utm_content=inline-mention
- 云原生调查报告：https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf
- Thoughtworks：https://www.thoughtworks.com/radar/platforms/kubernetes
- StatefulSets：https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
- Vitess：https://vitess.io/
- Kubernetes Operator：https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
- Day-2 Operation：https://jimmysong.io/blog/what-is-day-2-operation/
- Kubernetes 2021 调查报告：https://dok.community/dokc-2021-report/
Original: https://www.cnblogs.com/radondb/p/16021115.html
Author: RadonDB
Title: 翻译 | Kubernetes 将改变数据库的管理方式
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/505552/
转载文章受原作者版权保护。转载请注明原作者出处！