数据库如何在 Kubernetes 上运行？如果能够，哪些类型的数据库和数据最适宜应用 K8s？让咱们一起来看看。

Kubernetes 是用于主动部署、扩大和治理容器化应用程序的一个开源的容器编排解决方案。只管 Kubernetes 最后是为无状态利用程序设计的，但随着有状态工作负载的日益风行，Kubernetes 也能够于治理有状态应用程序。

通常状况下，容器是无状态的，如果容器解体或须要重启，容器中的数据必定会失落。作为一个容器编排器，Kubernetes 会放弃定期重启并在节点间挪动容器。无论 Kubernetes 对运行应用程序的容器做了什么，这对于须要保留数据的有状态工作负载来说都是一个重要的问题。

家喻户晓，数据库服务器是一个有状态的应用程序。

那数据库如何在 Kubernetes 上运行？Kubernetes 是否有机制来治理此类应用程序？如果是这样，什么类型的数据库和数据最适宜应用它？

在这篇文章中，咱们将找到答案。

运行数据库的不同形式

以企业中运行数据库服务器的不同形式为例分为：

  • 本地自有数据库：目前许多公司依然抉择应用虚拟机在本地或云上托管数据库服务器。企业负责设置数据库服务器、设置其安全性、装置补丁、降级、配置存储、提供高可用性、扩大、备份以及执行其余的数据库管理员操作。这是手动水平最高的形式，但这种形式能够齐全管制数据库和数据。
  • 云上托管数据库：大多数古代企业会抉择 Amazon RDS、Azure 数据库、谷歌云数据库 或 Instaclustr 等在云上部署和扩大数据库服务器更容易的解决方案。供应商负责存储、计算、网络带宽、装置、降级和高可用性等。作为消费者的企业只需将数据库托管在供应商提供的一个实例上，该实例运行你抉择的数据库引擎（如 SQL 或 NoSQL）。
  • Kubernetes 托管数据库：该形式是以上两种形式的混合体。你能够在本地或云端运行 Kubernetes 或者应用托管服务。通过这种办法，你能够利用 Kubernetes 的许多劣势，如主动调度、自修复或程度伸缩。但数据库的应用（如性能调优、备份和复原）仍须要你留神，并且可能会因为一些容器化特点而略有不同。

持久性存储和 K8s 的其余个性

只管开发 Kubernetes 的目标是治理不须要数据持久性的容器化应用程序，但它当初也提供了治理有状态应用程序的解决方案。长久卷（ Persistent volumes 简称 PV）[1] 提供了一个 API，容许 Kubernetes 管理员治理卷[2]，它与更多存储品种[3] 一起提供了一种平安而形象的形式来存储和治理数据。

然而，云是不可预测的，Kubernetes 常常须要重启和从新构建 pods。因而，长久卷很难在节点间挪动数据，并同时确保它们连贯到正确的容器。更简单的是，一些数据库须要运行在多节点集群配置中。

Kubernetes 1.5 版本[4] 中引入了一些设计来帮忙解决这些问题。StatefulSets[5] 确保 pods 基于雷同的容器标准，即便它们被挪动到另一个节点也放弃惟一的 ID。通过惟一 ID 将 pods 与长久卷耦合起来，即便在从新调度它们时，也能够保护工作负载的状态。DaemonSets[6] 尽管略微简单一些，但也是在集群的每个节点上运行工作正本的一种形式。

分布式有状态工作负载通常须要一系列预约义资源无奈解决的简单操作。例如，分布式数据库可能须要在数据库节点（在 Kubernetes 中，是一个 pod）呈现故障时执行一组特定的操作。这类操作的例子能够是选举领导者、均衡数据等等。

原生 Kubernetes 性能无奈真正解决这些状况，但其自定义资源（Custom resources）[7] 能够提供帮忙。 Custom resources 容许 Kubernetes API 应用畛域特定的逻辑进行扩大，定义新的资源类型和控制器[8]。Operator 模式[9] 通过帮忙开发自定义解决方案，利用自定义资源来管理应用程序及其组件。

OSS 框架，如 kubebuilder[10]，或 Operator Framework[11]，提供了构建块来创立 Operator，如 Postgres Operator[12]、MySQL Operator for Kubernetes[13], Elastic Cloud on Kubernetes (ECK)[14]，或 K8ssandra[15]。

分布式数据库的个性

大多数数据库引擎都提供了一种或多种形式来散发数据并使其具备高可用性。当抉择要在 Kubernetes 上运行数据库时，你须要思考以下个性：

  • 复制：数据库是否反对复制？如果反对，它反对什么类型的复制（如：双向复制、事务复制和快照）？这将有助于进步可靠性、容错性和可拜访性。
  • 分片：数据库是否可能对数据进行分区，并在不同的实例（即 pod）中保留不同的片段？这能够帮忙优化冗余和扩散负载。
  • 故障转移：数据库是否可能从主节点、读写节点切换到其余只读节点并将只读节点晋升为主节点？这也将有助于进步可靠性、容错性和可拜访性。
  • 可伸缩性：数据库是否具备可伸缩性（向内扩大和向外扩大）？Kubernetes 为程度扩大铺平了路线，然而数据库须要依据须要增加或删除实例。这能够帮忙解决减少的负载或在负载下降时降低成本。
    具备这些个性的数据库（例如：MySQL、PostgreSQL、ClickHouse、Elasticsearch、MongoDB 或 Cassandra 等）能够更轻松地应答异构云环境的不确定性。

数据可用性的思考

因为 pod 和计算节点在实质上通常是长期的，因而，Kubernetes 更适宜于某些类型的数据。重要的是要理解数据的重要性，以及它必须在多大程度上可用。

为了实现高可用性，一些数据库引擎应用所谓的最终一致性模型。最终一致性是一种技术，它确保如果给定的数据块没有新的更新，所有对它的拜访都将返回最初更新的值。它假如，在任何工夫点，不同节点的数据可能存在一些不统一（取决于从哪里读取它），因为它正在不断更新，然而一旦更新实现，所有节点都将领有它的雷同正本，并且所有客户端申请都将取得雷同的数据。当你在 Kubernetes 中运行数据库系统时，须要从业务角度来看这是否可承受。

一些数据库引擎能够解决故障转移（例如，当运行数据的主正本的 pod 从新调度或解体时），但备用节点复原并承当次要节点角色可能须要一些工夫。你须要思考在这种状况下，能够接受多少数据不可用，以及是否能够承受应用旧数据。

如你所见，这齐全取决于业务需要。解决瞬态数据（如缓存层）、只读数据（如查找表）或可轻松重建的数据（如 API 输入）的工作负载时，很显然更适宜在 Kubernetes 上。

总结

作为一种容器编排技术，Kubernetes 简化了许多常见的操作问题，例如调度、主动扩大或故障转移。尽管它十分实用于无状态工作负载，但有状态工作负载（如数据库）还有其余须要解决的问题。咱们曾经看到：

  • 长久卷和存储类提供了一种平安而形象的形式来治理数据；
  • 通过容许将 pod 与持久数据绑定，能够在这些概念的根底上构建 StatefulSet 和 DaemonSet；
  • 自定义资源和 Operator 能够帮忙为须要数据持久性的应用程序提供自定义逻辑。
    然而，重要的是要思考对要在 Kubernetes 上运行的数据库引擎的可用反对，以及要存储的数据类型和数据的可用性要求。在 Kubernetes 中运行服务须要应答肯定水平的波动性。

因而，Kubernetes 上更适宜部署能够解决复制、分片和故障转移的数据库。同样，Kubernetes 托管的现实数据是能够轻松疾速从新生成的数据。归根结底，这将取决于业务须要的容错能力。

原文：https://www.containiq.com/pos...

援用链接

1.长久卷：https://www.containiq.com/pos...

2.卷：https://kubernetes.io/docs/co...

3.存储品种：https://kubernetes.io/docs/co...

4.Kubernetes 1.5：https://kubernetes.io/blog/20...

5.StatefulSets：https://www.containiq.com/pos...

6.DaemonSets：https://www.containiq.com/pos...

7.自定义资源：https://www.containiq.com/pos...

8.控制器：https://www.containiq.com/pos...

9.Operator 模式：https://kubernetes.io/docs/co...

10.kubebuilder：https://github.com/kubernetes...

11.Operator Framework：https://operatorframework.io/

12.Postgres Operator：https://github.com/zalando/po...

13.MySQL Operator：https://github.com/mysql/mysq...

14.Elastic Cloud on Kubernetes：https://github.com/elastic/cl...

15.K8ssandra：https://k8ssandra.io/