遵循云原生数据基础设施准则

专业的工程师需要寻求标准，并基于最佳实践开展工作。为了尽可能地让数据变得更“云原生”，需要充分发挥Kubernetes的所有功能。真正的云原生方案秉承Kubernetes关键的设计范式并以此为基础。对于一个完整的云原生应用，数据也必须能有效地运行在Kubernetes上。下面列举了一些有代表性的云原生数据基础设施准则。

准则1：将计算、网络和存储作为商品化的API使用

云计算成功的关键原因之一是将计算、网络和存储进行商品化，并通过简单的API将其变为可供使用的资源。以下是AWS服务的示例：

计算

通过Amazon的弹性计算云（EC2）和自动伸缩组（ASG）分配虚拟机。

网络

通过弹性负载均衡器（ELB）、Route 53和虚拟私有云（VPC）管理流量。

存储

在数据持久化方面，可以选择简单存储服务（S3）以实现长期的对象存储，而在计算实例方面可以选择弹性块存储（EBS）卷。

针对容器化应用，Kubernetes提供了自己的API以实现类似的服务：

计算

通过Pod、Deployment和ReplicaSet管理计算硬件上的容器调度和生命周期。

网络

通过Service和Ingress对外提供容器的网络接口。

存储

通过PV和StatefulSet实现容器和存储的灵活关联。

Kubernetes资源实现了应用在Kubernetes发行版和服务供应商之间的可移植性。这对数据库意味着什么呢？数据库应用提供数据持久化和检索功能，正是利用了计算、网络和存储资源：

计算

数据库的运行需要充足的处理能力来满足数据存储和检索需求。将每个数据库节点部署为一个Pod，并通过StatefulSet编组，Kubernetes就能对其进行伸缩管理。

网络

数据库需要对外公开数据和控制的接口。Kubernetes的Service和Ingress控制器可以做到这一点。

存储

数据库可以使用指定StorageClass的PV来存储和检索数据。

从计算、网络和存储需求的角度考虑数据库，可以大大降低在Kubernetes上部署数据库的复杂性。

准则2：分离控制平面和数据平面

Kubernetes促进了控制平面和数据平面的分离。Kubernetes API服务器是用于请求计算资源的数据平面接口，而控制平面负责管理这些请求和底层IaaS（基础设施即服务）平台之间的具体映射关系。

这种模式同样适用于数据库。例如，数据库的数据平面包含了供客户端访问的端口，分布式数据库包含了供数据库节点之间通信的端口。数据库控制平面则包含了管理和监控的接口及运维工具。许多功能都可以并且应该通过Kubernetes实现。使用Operator能够配置自定义资源，并提供控制循环来观察和按需调整这些资源的状态，以扩展Kubernetes特定域逻辑。

准则3：简化可观测性

日志、指标监控和链路追踪是可观测性的三大支柱。Kubernetes上每个容器的日志都可供第三方日志整合方案访问，为简化可观测性提供了良好的基础。有很多方法可以实现指标监控、链路追踪和可视化，在本书后续相关章节将对此进行深入探讨。

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

Kubernetes网络在默认情况下是安全的：接口要明确对外公开，以便从外部访问Pod。这为数据库的安全部署提供了有价值的参考示例，驱使我们仔细思考如何公开每个控制平面和数据平面接口，以及哪些接口应该通过Kubernetes Service对外公开。Kubernetes还提供了密钥管理工具，可用于分享密钥及配置管理员账户。

准则5：优先选择声明式配置

在Kubernetes声明式配置方法中，需要先声明资源的期望状态，再由控制器通过底层数据基础设施来实现该状态。通过Operator可以对数据基础设施的智能扩展进行细致的管理。例如，在弹性扩展时决定如何重新分配分区，或在弹性缩减时选择移除哪些节点。

下一代Operator应当能为存储的数据大小、每秒事务数或同时为二者指定具体规则。这样或许可以指定最大集群和最小集群的大小，以及指定何时将不常用的数据迁移到对象中存储。这些功能会给数据基础设施带来更高的自动化效率。