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

43次阅读

共计 2750 个字符,预计需要花费 7 分钟才能阅读完成。

作者:Á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…
正文完
 0