啊，Kubernetes！我们DevOps挑战的万灵药。
Kubernetes是一个开源的容器编排工具，本应加速软件交付、保护我们的应用程序、降低成本并减少我们的头痛问题，对吗？
不过说真的，Kubernetes已经彻底改变了我们编写和交付软件的方式。随着EKS、AKS、GKE、红帽OpenShift、Rancher和K3s的普及，Kubernetes真正赢得了容器编排战斗。随着我们扩展应用程序、云平台和数据，我们开始识别出Kubernetes在安全性和易用性方面尚未完全满足需求的领域。因此，我们需要找到方法来帮助Kubernetes跟上我们的增长。
Kubernetes实践者转向第三方工具进行网络、安全和有状态应用的弹性，这有助于使他们的部署更加可靠。
在这篇博客中，我们将更深入地探讨Kubernetes应用的数据弹性。
Kubernetes旨在解决应用编排的挑战，假设是Kubernetes节点是短暂的。然而，在现实中，应用程序确实会消费和/或产生数据。在Kubernetes中，这被称为StatefulSets。此外，Kubernetes对象、CRDs、工件等都是在集群失败时需要可用的细节，因此意识到即使是Kubernetes部署也需要灾难恢复策略。
StatefulSets的崛起
StatefulSets设计用于处理需要唯一网络标识符和稳定存储的有状态工作负载。数据库、消息队列或分布式文件系统的每个实例通常需要稳定的网络身份和持久存储。StatefulSets通过为集合中的每个pod提供有序的、唯一的网络标识符和持久存储来应对这一挑战。当然，还有大量的Kubernetes存储部署依赖于静态卷附件，但它们没有水平扩展能力，因此目前不在这篇博客讨论范围内。
除了提供唯一的ID和扩展能力外，StatefulSets还提供了将持久卷挂载到每个pod的能力。这允许有状态应用存储和访问在pod重启或重新调度时持续存在的数据。StatefulSets中的每个pod都会收到自己独特的持久卷，实现数据本地性，最大限度地减少对其他pod的影响。
容器存储接口（CSI）标准是最广泛使用的API标准。它使得Kubernetes中的容器化工作负载能够访问任何块或文件存储系统。2019年底发布的容器存储接口驱动程序和快照为StatefulSets打开了大门。参见Kubernetes CSI。
云原生计算基金会（CNCF）框架包括了各种项目，以满足Kubernetes的存储需求。然而，实践者必须精通存储基础知识，这通常不是与DevOps相关联的技能。
像Portworx by Pure、Rancher Longhorn、Rook和LINBIT这样的公司正在为容器存储设定新标准（此外还有NetApp和HPE等供应商的产品）。它们提供了多种企业特性，使容器存储更加高效。
有了这些背景，我们转向考虑Kubernetes中多集群数据库弹性。
单集群应用
对于在单个集群中运行的应用程序，Kubernetes（与CSI存储组件一起）提供了卷复制的功能。每个持久卷可以设置为在本地具有一定数量的副本（通常是3个）。
如果节点失败，Kubernetes将采取行动。它将在新节点上重启服务，并将其附加到复制的卷版本。这有助于防止数据丢失。（暂时不考虑静态CSI或NFS驱动）
对于在本地复制数据的工具，数据是同步复制的，因为它是一个本地集群。使用Kubernetes控制平面，节点重启是即时完成的。因此，恢复时间被认为是零。
从恢复角度来看，这被认为是零恢复时间目标（RTO）。恢复点目标（RPO）在这种情况下也可能是零，但这当然取决于数据损坏、日志记录等的缓解措施。
放大到复杂环境，情况就更加复杂了。这些环境包括跨多个集群、平台甚至云提供商的集群。
多集群数据库弹性
了解多集群 Kubernetes 的原因和方式可能很困难。幸运的是，Traefiklabs 的朋友写的这篇文章 详细解释了 Kubernetes 多集群。
多集群 Kubernetes 的架构如下图所示：
我们讨论中相关的是这些集群之间的流量路线。从用户的角度来看，应用请求通过全球负载均衡器被路由到美国集群或欧盟集群。
那么，当美国集群中的节点1的一个Pod需要与欧盟集群中的节点1通信时会发生什么？由于两个集群之间的距离和复杂性，这可能构成一个挑战。至少，数据必须穿过至少两个网络边界，从美国集群出发，穿越大西洋，进入欧盟集群。
这种在本地网络和外部网络之间的网络流量流称为南北流量。"北"指的是从本地网络到外部网络的出站流量。"南"指的是从外部网络到本地网络的入站流量。
从数据平面的角度来看，集群之间的南北流量引入了更高的延迟和相比本地集群内部流量的降低可靠性。而集群内部的流量是同步的（快速、可靠）；远程集群之间的流量因此是异步的（更慢、不那么可靠）。
对于那些希望了解更多关于同步和异步流量的人来说，可能想要查看这篇文章。
南北流量和同步/异步通信如何与Kubernetes多集群数据库弹性相关联？
Kubernetes中的CSI存储连接器使用同步通信处理本地集群内的流量。这意味着数据同时写入到主数据卷和副本数据卷。
远程集群的数据首先在本地写入。然后，数据的快照副本定期发送到第二个集群。这是异步完成的。
这种方法的不同也对数据弹性以及在故障后如何恢复数据产生了影响。
Kubernetes在本地集群内的灾难恢复场景中的恢复是即时的。这是因为数据被同时复制到本地副本。因此，数据可用性也是即时的。
从技术术语来说，我们追踪两个指标。恢复时间目标（RTO）是从故障中恢复所需的时间。恢复点目标（RPO）是允许的最大数据丢失量。
因此，本地Kubernetes集群内的灾难恢复可以说是零RPO / 零RTO
（关于Kubernetes中RPO和RTO考虑的深入讨论，我强烈推荐Bijit Ghosh和Matt LeBlanc的文章。）
然而，在远程集群的情况下，情况有所不同。在评估跨多平台或多云应用程序时，云架构师或SRE应考虑异步复制对恢复时间目标（RTO）的影响。复制副本的运输、南北流量以及在恢复地点的活跃集群上的恢复都需要时间。这意味着灾难恢复操作有时间延迟。
这种时间延迟可能是显著的。保守估计表明，CSI解决方案可以将RTO减少到15分钟。这意味着我们可以有零RPO和15分钟的RTO。
大多数DevOps团队和云架构师专注于单集群、单区域和单平台部署。他们可能没有考虑灾难恢复架构和要求。因此，许多早期采用者可能会对15分钟的RTO感到满意。
传统的基础设施架构师和数据所有者可能想要探索市场上的新解决方案。这些解决方案可以帮助他们实现接近零的恢复时间目标和跨多个Kubernetes平台的灾难恢复。
像KubeSlice这样的工具可以通过在多个集群或平台之间建立低延迟数据平面互连来降低RTO阈值。这有助于加快Kubernetes应用程序和数据的恢复速度。
KubeSlice通过应用层虚拟化将南北流量转换为东西流量，通过安全/加密的连接，从而消除了穿越网络边界的需要。这为数据平面创建了低延迟的连接，并使数据在灾难恢复站点的同步复制成为可能。
KubeSlice使远程集群看起来像是主集群的本地集群。这使恢复接近于实现零恢复时间目标（RTO）。
无论采用哪种恢复方案，应用程序所有者都应仔细考虑他们的应用程序和数据弹性需求，并相应规划。
正如《Kubernetes上的数据》报告指出的那样，将数据部署在Kubernetes上，三分之一的组织看到生产力增加了两倍，这对于各个技术成熟度水平的组织都有益处。
总结
容器存储接口（CSI）标准和像Portworx和Rancher Longhorn这样的项目是向Kubernetes持久性应用的软件定义存储方法迈出的良好开端。
文章探讨了Kubernetes中多集群数据库的弹性，从单集群应用的弹性开始。它解释了Kubernetes如何处理节点故障时的卷复制，确保单集群内零恢复点目标（RPO）和零恢复时间目标（RTO）。然而，当处理跨多个平台和云提供商的多集群环境时，复杂性就出现了。文章讨论了南北流量和远程集群之间的异步通信的挑战，并解释了这些挑战对灾难情况下的数据弹性和恢复的影响。
文章介绍了KubeSlice作为一种工具，可以通过在多个集群或平台之间建立低延迟数据平面互连来降低RTO阈值。它将南北流量转换为东西流量，使Kubernetes应用程序和数据的恢复更快，并实现数据在灾难恢复（DR）站点的同步复制。文章强调了仔细考虑应用程序和数据弹性需求的重要性，并提到了在Kubernetes上部署数据的好处。
总的来说，文章聚焦于Kubernetes中与数据弹性相关的挑战和解决方案，特别是在多集群部署中，并强调了像KubeSlice这样的工具在实现更快恢复时间方面的作用。
作者：Ray Edwards
更多技术干货请关注公号【云原生数据库】
squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。
irds.cn，多数据库管理平台（私有云）。