3.2　Kubernetes 高可用层级

回到Kubernetes 的主题，Kubernetes 作为一个容器云管理平台，并非孤立存在，其与底层的基础架构、企业周边的公共服务形成了一个完备的生态系统。在设计出Kubernetes高可用落地方案之前，就需要充分了解Kubernetes 的生态系统及各层级的依赖关系，利用各个层级的各种技术的优势，来实现高可用的目的。如图3-4 所示，一个完备的Kubernetes系统在设计和实现时，需要考虑多层面的高可用性问题。当任意层面不能高可用时，都将限制系统整体的可用性。

因此，解决系统性的高可用问题，需从下到上立足各个层面，找出每层的最优解决方案，最终串联组成最优的整体解决方案。下面具体介绍实现各个层面高可用时需要考虑的问题、策略和方法。

1.基础架构管理

从数据中心的规划上，为了支持高可用的生产应用，需要在多地部署多个数据中心。每个数据中心需要划分成具有独立供电、制冷、网络设备的高可用区。每个高可用区管理独立的硬件资产，包括机架、计算节点、存储、负载均衡器、防火墙等硬件设备。

2.主机管理

虽然所有的硬件设备都需要配置管理，但作为云计算平台，计算节点是重中之重。我们在第2 章已经详述了主机管理的方方面面：包括选定哪个版本的系统内核、哪个发行版、安装哪些工具集、主机网络如何规划等。这些参数会极大影响服务的稳定性。日常的主机镜像升级更新也可能是造成服务不可用的因素之一。主机镜像更新可以通过A/B 系统OTA（Over The Air）升级方式进行。A/B 系统升级，也叫作无缝更新。顾名思义，设备上有A和B 两套可以工作的系统，分别使用A、B 两个存储空间，共享一份用户数据。在升级过程中，OTA 更新即往其中一个存储空间写入升级包，同时保证了另一个系统可以正常运行，而不会打断用户。如果OTA 失败，那么设备会启动到OTA 之前的磁盘分区，并且仍然可以使用。

3.集群管理

主机就绪后，就要考虑集群层面的管理，即如何利用这些主机通过控制平面向用户提供高可用的云服务。在集群设计时，应思考和规划以下问题：

● 如何设定单个集群规模

社区声明单一集群可支持5000 节点，在如此规模的集群中，大规模部署应用是有诸多挑战的。努力提升单一集群节点的支持上限，把5000 节点提升至10000 节点；或者将计算节点先划分成中等规模的集群，比如每个集群保持3000 节点，再搭建更多的集群。判断哪一种方式是更明智的选择，需要考虑的因素也非常多。

● 如何根据地域划分集群

是否应该将不同地域的计算节点划分到同一集群，以便上层应用在同一集群中即可享受跨地域高可用的便利？还是应该将同一地域的节点划分到同一集群，以获得更低的网络延迟？

● 如何规划集群的网络

企业办公环境、测试环境、预生产环境和生产环境应如何进行网络分离？同一生产环境中的不同集群之间、集群中的不同租户之间应如何进行网络隔离？

● 如何自动化搭建集群

如何与企业的公共服务集成，例如如何集成公司统一的认证平台、负载均衡服务及存储服务等。如何自动化搭建和升级集群，包括自动化部署控制平面和数据平面的核心组件，以及常用插件如KubeDNS、监控系统等。这些组件能够支撑整个平台的正常运行。

4.企业公共服务

Kubernetes 并非孤岛。要将其在企业中真正落地，承载企业的各类应用，就需要将企业的公共服务整合到Kubernetes 的生态系统中。

首先，需要与企业认证平台集成，这样企业用户就能通过统一认证平台接入Kubernetes集群，而无须重新设计和管理一套用户系统。

然后，需要集成企业的域名服务、负载均衡服务，提供集群服务对企业外发布的访问端口。在与企业的公共服务集成时，需要考虑它们的服务是否可靠。对于不能异步调用的请求，采用同步调用需要设置合理的超时时间。过长的超时时间，会延迟结果等待时间，导致整体的链路调用时间延长，从而降低整体的QPS。

最后，需要区分调用失败的类型，并分别设置合理的重试次数。有些失败是短暂的、偶然的（比如网络抖动），进行重试即可。而有些失败是必然的，重试反而会造成调用请求量放大，加重对调用系统的负担。

5.Kubernetes 公共服务

Kubernetes 是平台，亦是微服务的集大成者。比如Jenkins，支持了Kubernetes 插件，可以以极低的成本为企业的不同应用提供持续集成平台。比如CoreDNS，是可以横向扩容的、基于插件进行功能扩展的域名服务器，可以面向集群外部提供域名服务。再比如日志收集、指标收集及告警系统等，这些系统皆可面向平台用户，打造统一的监控方案，从而降低应用的运维成本。封装这些有利于应用高可用的服务，提供简单的部署和使用方案，不仅能够帮助用户提升应用的高可用性，而且还能够提升用户体验，极大地推动了Kubernetes 在企业的落地进程。

6.集群运维

集群运维的核心内容是对平台的各个组件和服务进行监控、故障排除和版本升级等，确保业务所需的所有组件能够按照预期工作。除了日常的监控手段，还可以进行业务模拟和断言，即使用定期执行的程序模拟真实的用户行为，并判断处理结果是否符合预期。如果结果不符合预期，相关组件存在潜在的故障风险，则应自动修复。如果故障不能自动修复，则应自动将不可修复的组件实例或节点及时移出集群，并用新的组件实例或节点替换以保证集群的处理能力或容量不变。运维人员不应仅仅是徒手的 “救火专员”。建立完善的监控体系和自动化的修复手段，才是真正保证服务高可用的最后一道防线。

7.应用开发

集群运维是辅助，应用开发才是输出。Kubernetes 作为微服务平台，其价值及核心竞争力就是为开发人员提供了统一的应用接入规范。开发人员需要关注的内容包括应用逻辑的开发，即依托于Kubernetes 的持续集成平台将代码编译成为容器镜像；在应用测试时应进行压力性能测试，获取在固定的计算资源下应用最大可承受的用户请求数量和延时等关键指标，并设计监控预警方案；在应用部署之前需要对应用进行部署规划，比如明确实例个数和扩缩容机制、每个实例需要的计算资源、实例数量、故障域、与其他应用的亲和性，等等。系统管理员在开发控制平面组件时，与应用开发人员并无不同，控制平面组件的开发应遵循相同的流程。

Kubernetes 生态系统中涵盖的服务、技术、工具的多样化和易用性，很大程度上支持了Kubernetes 容器云平台在企业的落地。几乎能够以原生形式部署Kubernetes，这是前所未有的壮举。庞大的开发者社区正不断扩展Kubernetes 在各个服务、各个领域（例如安全、存储及监控等）的核心能力。不管是应用开发还是控制平面组件的设计和开发，本不应该关注集群的管理和运维，但是了解集群的底层技术和方案，更有利于设计出高可用的应用架构，充分利用Kubernetes 生态提供的技术和工具，避免重复造轮子的尴尬。