为什么不推荐多区域 Kubernetes 部署？答案

【问题标题】：Why multi-region Kubernetes deployments are not recommended?为什么不推荐多区域 Kubernetes 部署？
【发布时间】：2021-02-10 13:58:14
【问题描述】：

Kubernetes 文档说支持多区域集群，但不支持多区域集群。同时Kubernetes同时支持failure-domain/zone和failure-domain/region。

让我的 Kubernetes 集群同时成为多专区和多区域有什么缺点？它只是延迟吗？如果是，它需要多少延迟数字才能使其可靠？

从好的方面来说，我看到了服务发现，并且能够跨多个区域部署应用程序，而无需额外的工具。

我知道联邦 v1 和 v2 正在开发中，但它似乎增加了很多复杂性，而且 v2 还远未准备好生产。

【问题讨论】：

【解决方案1】：

这是推测，但它是知情推测，所以希望这意味着它仍然会有所帮助

让我们看看 Kubernetes 所做的两件事，并将它们外推到一个多区域集群中：

负载均衡器成员资格 -- 至少在 AWS 上，没有将不同区域的成员添加到负载均衡器的机制，这意味着 type: LoadBalancer 无法将所有 Pods 分配给 Service
持久卷连接 - 同样在 AWS 上，没有机制可以跨可用区域附加 EBS 卷，更不用说跨区域了

对于其中的每一个，绝对可以找到“是的，但是！”场景来演示这些限制无关紧要的情况。但是，由于 kubernetes 试图以与云无关的方式解决一般情况，这就是我强烈怀疑为什么他们甚至建议不要尝试多区域集群——不管它是否恰好适合你现在的情况.

【讨论】：

感谢您的回答。不幸的是，我没有在 AWS 上使用 Kubernetes 的经验。我当前的集群在裸机上，我正在研究跨数据中心（又名 AWS/GCP 的跨区域）集群。我有自定义负载平衡器和 rook/ceph 用于存储。
好吧，在这种情况下，您实际上可能对所有问题免疫（因此可能属于“是的，但是！”类别:-)）。只要您有一个 Ingress 控制器或其等效的数据中心感知控制器，并且在持久卷管理方面有类似的好故事，那么我猜“试试看”是简短的版本
嗨@Maklaus，你最终让它工作了吗？如果你愿意，你介意分享你的经验吗？谢谢！