云计算革命激发并受益于多种相互关联的趋势。自助服务、公共云基础设施的可用性有助于推动微服务架构和DevOps实践的采用，包括自动化和可观察性。
朝着容器化和容器编排的方向发展，使得Kubernetes作为管理云原生应用程序的环境被广泛采用。
但这场革命的滞后领域之一是数据和数据基础设施。长期以来，数据一直存在于Kubernetes之外，这给开发人员部署云原生应用程序带来了大量额外的工作和复杂性。
在Kubernetes的早期，一个经常重复的公理是，它还没有为有状态工作负载做好准备。值得庆幸的是，一个重大转变已经悄然发生，事实上已经到了成熟的阶段。
这一转变起初进展缓慢，最初是将现有数据库容器化。对于在单个计算节点上运行的小型数据库，或者为云原生世界设计的数据库（如Apache Cassandra和Dynamo DB），这种方法相对来说效果较好，但仍存在挑战。
在过去的两三年中，出现了新一代数据库。这些“Kubernetes原生”数据库从一开始就被设计为在这个开源编排系统上运行。
在这里，我们将定义数据库Kubernetes原生的特性，以及采用Kubernete原生数据库所带来的好处。为了做到这一点，我们将查看两个打上Kubernetes原生标签的数据库：TiDB和DataTax Astra DB。
Kubernetes原生的TiDB
首先，让我们检查一个以关系为重点的数据库：TiDB（Titanium Database的简称）。TiDB是一个由PingCAP构建的开源系统，它提供了一个MySQL兼容的数据库以及一个列式数据库，以支持混合事务处理和分析处理（简称HTAP）。
如下图1所示，TiDB具有微服务设计，其中TiDB查询层、TiKV MySQL数据库、TiFlash列式数据库、Spark节点和元数据管理都作为可扩展的微服务部署在各自的集群中。这种设计将计算密集型工作与存储密集型工作分开，因为查询层和数据库层是独立可扩展的。
图1:TiDB架构
TiDB创建者做出的一个关键承诺是，数据库只在Kubernetes上运行。这足以使它成为Kubernetes原生吗？让我们再深入一点。首先，TiDB由Kubernetes operator使用定制资源（CRD）进行部署和管理。TiDB CRD包括TiDBCluster，它允许你指定每个微服务的缩放和配置，以及数据库层组件如何通过Kubernetes Persistent Volumes使用存储。其他CRD用于部署监控工具以及管理备份和恢复等运维任务。
TiDB还有一个可选的调度程序扩展，它与默认的K8s调度程序接口，以做出更具应用程序意识的调度决策。这种对使用现有Kubernetes功能的强调是Kubernete原生数据库的标志。
Kubernetes原生的DataStax Astra DB
我们看看另一个Kubernetes原生数据库，并注意一些相似之处和不同之处。Cassandra是一个高度可扩展的NoSQL数据库，它是最早宣称自己是云原生的数据库之一，但在Kubernetes中部署Cassandra会是什么样子？DataTax Astra DB是Cassandra的一个版本，已被分解到微服务中，如图2所示。
与TiDB类似，该数据库包括与查询处理和数据存储相关的微服务，以及身份和访问控制、数据修复和备份/恢复服务。数据服务在存储的使用方面特别有趣——Kubernetes Persistent Volumes仅用于缓存，对象存储用于长期持久性。将压缩分离到自己的服务中，使这种计算密集型处理能够在后台进行，而不会影响为读写流量提供服务的数据服务的性能。
图2:DataTax Astra DB架构
Astra DB作为托管服务在多个云区域提供。每个区域都包含一个由上述服务组成的数据平面，由Kubernetes operator管理，以及基础设施服务，包括Kube-Prometheus堆栈（用于可观察性）和etcd（用于元数据管理）。数据平面由控制平面管理，该控制平面可以在一个或多个云中运行，以执行诸如管理客户账户和数据库以及在新区域配置Kubernetes集群等任务。
Astra DB的一个新方面是其多租户架构，其中多个用户数据库可以共享相同的微服务和支持基础设施，从而降低了规模较小用户的单位经济性。随着用户应用程序的增长，他们可以选择转移到专用资源，以实现规模上的最佳性能，所有这些都是在“按需付费”的基础上实现的。
Kubernetes原生数据库原理
根据对TiDB和Astra DB的观察，我们可以得出一些关于Kubernetes数据库原生的想法。其中许多都对应于云原生数据的原则列表：
——可组合的微服务架构：首先，一个被分解为微服务的数据库使每个服务都可以独立扩展。对于真正的无服务器解决方案，某些类型的计算密集型处理甚至可以扩展到零，特别是当与多租户设计结合时。
——将计算、网络和存储视为商品：由Kubernetes原生数据库组成的微服务应最大限度地利用KubernetesAPI来管理云原生应用程序的基本资源：用于管理工作负载的计算资源（如StatefulSet和部署）、用于存储的持久卷子系统、Kubernetes入口和服务（用于暴露对数据的网络访问等）。这包括利用Kubernetes中已有的功能（如etcd）进行元数据管理，而不是使用具有重复功能的组件。
——利用Kubernetes最佳实践：遵循Kubernete应用程序的常见模式将产生多种运维优势，例如，暴露每个微服务的活跃度和就绪性检查以帮助可用性，并通过Prometheus PromQL API暴露度量以实现可观察性。默认情况下，Kubernetes本身为数据库提供了一个很好的安全示例：使用Kubernetes Secrets分发安全凭据，只根据需要公开端口等。
——通过operator进行声明性管理：Kubernetes原生数据库应该体现通过operator和自定义资源进行声明性的管理的Kubernete原则，而不是依赖于传统的数据库管理UI和CLI。必要时，可以使用Kubernetes扩展点（如调度器扩展）来添加特定于应用程序的行为。目标是将数据平面功能（管理数据）与控制平面功能（数据库管理）彻底分离。
忠实采用这些原则的数据库和其他数据基础设施将带来好处，包括在所有规模上实现最佳成本的高性能、降低运维复杂性从而加快上市时间以及符合标准的解决方案，以满足当今的高可用性和安全性需求。
Kubernetes原生数据基础设施的未来
仍有许多进展在等着，不仅仅限于数据库。Kubernetes原生原则可以应用于其他类型的数据基础设施，包括流媒体、分析和机器学习。
Kubernetes原生解决方案将继续在多集群和多云部署方面取得进展，以便在全球范围内扩展，并将采用多租户和无服务器原则，以实现更好的成本优化。Kubernetes本身在为StatefulSet增加更多灵活性和支持多集群联合方面还有改进的空间。
