多机房下的 Kubernetes 演进

云计算 2023-01-04 大白菜程序猿手机阅读

1. 应用架构与业务发展、运维能力匹配

如上图，在业务发展的早期，我们可以在客户聚集的区域部署应用，就近提供服务。每个 Location 都能提供独立、完整的对外服务。Location 与 Location 之间可以通过公网互联，建立隧道，实现控制流的传输。这里的控制流并不只是局限于指令类，还可以是用户的元数据等，但是不应该传输用户产生的数据，比如上传的图片、文档等。由于业务的隔离，在每个 Location 会部署很多的 Kubernetes。单个 Kubernetes 的节点越少，越易于维护，爆炸半径越小，风险越可控。但这也意味着，我们会有很多的集群，而管理和维护这些集群也需要人力投入。同时，集群版本差异，也会增加开发适配难度、影响应用技术选型、削弱积累的运维经验价值。

3. 中期多区下的 Kubernetes

如上图，业务具有一定规模时，我们可以进行集群的合并。在早期，为了规避风险，集群数量会非常大，一个部门上百个集群会给集群管理、维护带来巨大成本。集群维护者，每天关注的是资源不足、内存泄露、拉不到镜像、增删节点、权限不够、配置差异等等。而另一方面看到的是，有些新的集群负载很低、内核版本很高，用户没有反馈问题。这也是大量小集群的弊端，维护成本高，HPA 伸缩空间有限。通过合并集群，能够有效提高集群的整体负载率。但随之而来的还有超大规模集群带来的各种问题：