乐趣区

关于数据库:翻译-Kubernetes-将改变数据库的管理方式

jiezi

作者：Á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…
退出移动版