使用多可用区Kubernetes进行灾难恢复

停机和性能下降是不可避免的，可能是运维人员犯错误、新的协议引入了错误、自然灾害、设备损坏等。

这就是为什么大多数平台管理员不相信亚马逊设计防飓风数据中心的能力，而是选择将应用程序的基础设施分布在多个可用性区域（AZ）。

AZ中断并不常见，但确实会发生，性能下降更为常见。而且灾难性的停机是可能的，比如飓风造成的停机，因此负责任的平台管理员围绕故障设计基础设施。

这是一件好事，值得称赞。但很少有平台管理者考虑多个AZ Kubernetes部署带来的新设计挑战。让我们深入探讨多AZ生产环境带来的新因素。

不能把基础设施跨AZ分布吗？

多AZ Kubernetes服务可能需要更多的跑腿工作，而不仅仅是声明希望节点分布在AZ上。虽然从技术上讲，你可以简单地跨多个AZ部署副本节点，但大多数应用程序都需要额外的配置。

具体来说，无状态应用程序可以在多个AZ之间正常工作。如果一个AZ出现故障，Kubernetes将在下一个AZ重新安排应用程序。在过渡期间，不会有任何状态工作负载需要保留，因此最终用户不会注意到任何不同。

然而，一个有状态的应用程序跨多个AZ工作就不是这么简单了。原因如下。

跨AZ的有状态

假设你跨多个AZ启动了一个应用程序，以获得灾难恢复能力，但没有考虑其有状态工作负载。

首先，你的应用程序无法正常运行很长时间，因为它在跨容器的有状态工作负载下运行，而容器在运行有状态应用程序时并不十分健壮。

比如说，需求激增或其他某种失败迫使Kubernetes杀死一个容器。当Kubernetes的调度程序重新启动你的有状态应用程序时，只有在其卷最初所在的同一个AZ中重新启动时，它才会运行。如果在其他地方重新启动，它将无法访问该卷。因此，平台管理员必须为带有附加卷的应用程序创建并维护关联规则，以确保它们仅在与其卷关联的应用程序中重新启动。

我们假设你已经为这个问题建立了一个解决方案，可能是通过利用一个不受AZ边界限制的合适的容器存储接口（CSI）提供程序。如果灾难恢复是一个目标，那么你需要确保解决方案能够创建持久卷副本。这样，如果一个容器出现故障，副本可以立即恢复，几乎没有停机时间。

但现在，你面临另一个挑战：确保副本均匀分布在AZ上。例如，主卷及其副本可能位于同一个AZ中，如果AZ发生故障或服务中断，这显然会影响你的灾难恢复能力。

此外，你还需要确定一种方法，以便随着时间的推移更改副本的托管位置。如果你决定添加另一个AZ或更改副本的布局，会发生什么？Kubernetes和云服务提供商的基础设施不会自动为你做到这一点。

为了解决这个问题，如果你主要使用AWS提供云服务，可以在Lambda中编写一些自定义脚本。但是，还有其他一些东西需要维护，当然，这不能跨不同的云服务提供商起作用。

解决方案：Kubernetes的拓扑密钥

幸运的是，Kubernetes提供了一个功能，我们可以使用它来构建一个解决方案，以解决有状态多AZ Kubernetes部署问题，称为拓扑密钥。这使得Kubernetes服务能够基于集群的节点拓扑来路由流量。

因此，使用拓扑密钥的一种方法是让Kubernetes用它所在的AZ标记每个节点。有了这些信息，CSI解决方案就可以将副本节点均匀地分布在AZ上，从而创建Kubernetes功能集中缺失的强大灾难恢复功能。

一举两得

上述方法正是Ondat所采取的。Ondat使用Kubernetes的拓扑密钥，通过一个称为拓扑感知放置的过程，在AZ上分发副本节点。

Ondat还确保在AZ、集群、节点或容器发生故障时，你的有状态工作负载保持不变。作为存储编排器，Ondat汇集了各个节点的存储，充当Kube原生分布式引擎的中介，从而将前端持久卷从底层平台拓扑中分离和抽象出来。

原文链接：

https://thenewstack.io/use-multi-availability-zone-kubernetes-for-disaster-recovery/