容器云平台的高可用架构设计概述.docx

? ? ? ? ? ? ? 容器云平台的高可用架构设计概述 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  1 绪论 1.1 什么是高可用 高可用（HighAvailability），是设计分布式系统架构所必须要考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 虽然大部分情况下，我们的系统都能够很好的运行。但绝对不会故障的系统是不存在的。无论代码写的多好，硬件如何的可靠，也无法保证整个系统的稳定。因为故障总是会发生在意想不到的地方。 比如 2015 年 5 月 27 日支付宝在杭州的一个机房光纤被挖断，导致部分用户无法正常使用支付宝，直到当日晚上 7 点 20 分，支付宝才宣布用户服务恢复正常。 再以微信为例，在 2019 年 10 月 29 日微信发生了一场事故：与银联系统对接时发生网络故障，导致支付系统宕机近 30 分钟，使得近两千万笔订单无法正常的完成。 阿里腾讯的技术水平不可谓不强，而支付业务又是其中的重中之重。尽管如此，还是会有一些揪心的时刻。为了能够尽可能的减少服务的不可用时间，最大降低损失，我们可以通过架构设计的手段为服务提供强的可用性，即高可用架构设计。 1.1.1 高可用架构的设计原则 ◎ 冗余：单点永远是高可用的最大敌人。任何组件都有可能奔溃，哪怕只是简单的执行ping命令。单点组件一旦奔溃，如果没有后备组件的话，那么这一组件就算是彻底不可用了。为了保证组件的故障不会导致整个系统的故障，我们应当为每一个组件都留有一个到 N 个冗余后备。 ◎ 故障转移：出了故障后，要是请求还在往故障的节点上发，那么有再多的冗余节点也是毫无意义。所以需要自动的检查故障的产生，并将流量转发到冗余中的可用节点上。而想要及时的实现故障转移，我们就需要有健康检查机制去检查服务的状态。 ◎ 排查异常：如果高可用架构设计完美，那么即使发生故障，用户也很可能永远感知不到。但这并不代表就不需要检查并解决故障了，定期的维护可以进一步提高系统的可用性。 1.1.2 其他未能提到的机制 对于高可用架构还应当考虑服务分级与降级，灾难恢复与异地多中心等等机制或场景。随着服务规模的不断扩张，保持或提高可用性的成本会以一种夸张的方式上涨。由于篇幅有限，对于很多知识点都难以面面俱到的深入探讨，在实际应用中还是需要更多的参考实际场景来进行规划。 1.2 容器云平台架构介绍 通过前一节的介绍我们可以知道，如果想要保证整个云平台的高可用，对于云平台各个部分自然是需要一定程度了解的。接下来让我们看看常见的容器云平台架构： ◎ 基础设施：基础设施指的是位于架构中最底层的物理设备及相应的资源池。虽然基础设施通常都有专门的团队进行维护，或者使用了诸如 AWS、阿里云之类的公有云服务。但是我们仍然需要能够为应用实现对物理机的亲和与反亲和（如多个高 IO 应用避免部署在同一个物理机下的不同虚拟机中），对于部分应用还需要做到分机房部署。 ◎ 容器云平台：容器云本质上我们可以将其看作就是一个普通的 Web 应用（通常是无状态的，持久化数据使用集群 etcd），通过将其部署到 Kubernetes 中，并配置好健康检查与副本集来为其实现高可用。 ◎ 私有镜像仓库：如果我们的容器云平台是私有云，或者我们的 CI\CD 制品不想上传到公网上，那么我们就会需要一个自己的私有镜像仓库。在容器云平台完成相关设置后，从此以后私有的镜像就可以都从内网中拉取。当有 Pod 不可用，开始漂移时，这个 Pod 可能会飘到一个并没有去过的节点中，这时候就会需要向私有镜像仓库拉取镜像。如果这个过程失败了，那么我们的 Pod 就会长时间处于不可用的状态，进而可能会对业务的可用性造成影响。 ◎ 容器云平台纳管的 Kubernetes 集群：这些集群是通过容器云平台进行创建和管理的集群。通常多云架构中会包含这一层，这样通过在多个云厂商下部署集群来提高更多的冗余。当然，这一层并不是必要的。 ◎ 容器云托管应用：在布置好容器云平台后，我们就可以在平台上部署应用了。这一部分除了容器云平台的用户所部署的应用外，还包含诸如监控、日志收集和网格网络等由容器云管理者所创建的应用。这些应用的可用性和状态则由容器云平台和 Kubernetes 共同维护， 而这部分内容会在后面的小节中具体描述。 2 Kubernetes集群高可用 在容器这一新秀刚刚发展起来的那段时间里，曾经出现过大量的容器编排系统。其中以Swarm、Mesos和Kubernetes三个项目最受欢迎。在经过多年的竞争与发展后，如今，由 Kubernetes 构建的容器生态体系已经成为了容器领域中的事实标准。 安装一个高可用的 Kubernetes 集群是保障容器云平台高可用的第一步。尽管我们可以通过诸如Kubea