长期以来，我们一直在谈论将工作负载迁移到云中，但是对许多IT组织的应用程序组合的观察表明，仍有许多工作要做。在许多情况下，尽管云中的数据库已经可用了多年，但在云中持久存储和移动数据的挑战仍然是阻碍云采用的主要限制因素。因此，最近对数据基础结构的兴趣激增，旨在充分利用云计算所提供的好处。一个云计算的本地数据库是一个实现的可扩展性，弹性，可观测性和自动化的目标，该K8ssandra项目就是一个很好的例子。它将ApacheCassandra和支持工具打包到可用于生产的Kubernetes部署中。

这就提出了一个有趣的问题：必须将在Kubernetes上运行的数据库视为云原生数据库吗?虽然Kubernetes最初是为无状态工作负载设计的，但Kubernetes的最新改进(例如StatefulSets和持久卷)也使运行有状态工作负载成为可能。甚至对Kubernetes上运行数据库持怀疑态度的长期DevOps从业人员也开始浮出水面，并且最佳实践也开始浮出水面。

但是当然，勉强接受在Kubernetes上运行数据库并不是我们的目标。如果我们不希望在云原生数据库中寻求更大的成熟度，那么我们将错过一个巨大的机会。为了使数据库成为最“云原生”的数据库，我们需要包含Kubernetes必须提供的所有内容。真正的云原生方法意味着采用Kubernetes设计范例的关键元素。云原生数据库必须是可以在Kubernetes上有效运行的数据库。让我们探索一些指明方向的Kubernetes设计原则。

原则1：将计算，网络和存储作为商品API

云计算成功的关键之一是计算，网络和存储的商品化，这是我们可以通过简单的API进行配置的资源。考虑以下AWS服务样本：

·计算：我们通过EC2和自动伸缩组(ASG)分配虚拟机

·网络：我们使用ElasticLoadBalancer(ELB)，Route53和VPC对等管理流量

·存储：我们使用诸如简单存储服务(S3)进行长期对象存储或弹性块存储(EBS)卷之类的选项来持久化数据。

Kubernetes提供了自己的API来为世界范​​围内的容器化应用程序提供类似的服务：

·计算：容器，部署和副本集管理计算硬件上容器的调度和生命周期

·网络：服务和入口公开了容器的网络接口

·存储：持久性卷和有状态集可实现容器与存储的灵活关联

Kubernetes资源促进了Kubernetes发行版和服务提供商之间应用程序的可移植性。这对数据库意味着什么?它们只是利用计算，网络和存储资源来提供数据持久性和检索服务的应用程序：

·计算：数据库需要足够的处理能力来处理传入的数据和查询。每个数据库节点均作为Pod部署并分组在StatefulSets中，从而使Kubernetes能够管理横向扩展和横向扩展。

·网络：数据库需要公开用于数据和控制的接口。我们可以使用KubernetesServices和IngressControllers公开这些接口。

·存储：数据库使用指定存储类的持久卷来存储和检索数据。

从数据库的计算，网络和存储需求的角度考虑，消除了在Kubernetes上部署所涉及的许多复杂性。

原理2：将控制平面和数据平面分开

Kubernetes促进了控制平面和数据平面的分离。KubernetesAPI服务器是用于请求计算资源的关键数据平面接口，而控制平面则管理将这些请求映射到基础IaaS平台的细节。

原则3：简化可观察性

可观察系统的三大支柱是日志记录，指标和跟踪。通过将每个容器的日志暴露给第三方日志聚合解决方案，Kubernetes提供了一个很好的起点。度量和跟踪需要花费更多的精力来实现，但是有多种解决方案可用。

原则4：确保默认配置安全

Kubernetes网络默认是安全的：必须显式公开端口才能从外部访问Pod。这为数据库部署树立了有用的先例，迫使我们仔细考虑如何公开每个控制平面和数据平面接口，以及应该通过KubernetesService公开哪些接口。

原则5：首选声明式配置

在Kubernetes声明性方法中，您可以指定所需的资源状态，并且控制器可以操纵底层基础结构以实现该状态。Cass-operator允许您指定集群中所需的节点数，并管理放置新节点以按比例放大以及选择要删除的节点以按比例缩小的详细信息。

关于为什么Kubernetes是运行云原生数据库的最佳技术相信大家已经知晓了吧，想了解更多关于数据库的信息，请继续关注中培伟业。