多机房下的 Kubernetes 演进

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

在行业会议、文档博客中，我们时常能见到各种优秀的解决方案，但是如果直接照搬到自己的业务，却又频频碰壁。因为，这些技术方案是特定的业务场景孵化出来的，不同的业务形态、不同的业务规模、不同的业务发展阶段都会影响技术的落地。

另一方面，应用需要人去维护，需要构建合适的平台辅助应用生命周期的管理，这就要求与之匹配的运维能力。落后的运维能力会降低生产效率，给竞争对手可乘之机；过于超前的运维能力投入产出比低，容易拖垮公司。

我们不必为了几万的 QPS 的流量去打造一个微博，应对各种热点流量；也不必为了追新的技术热点，招聘一批大牛消耗资金流。

应用架构与业务发展、运维能力是相匹配的。业务的向前发展，赚到了钱，用户量更大、需求更多，就会促使架构上的升级；架构的升级，又可以更好地服务于用户，成就更多的用户。这是一个动态、相互促进的过程，也促使着技术人员的流动，在市场上找到合适的位置。

如上图，在业务发展的早期，我们可以在客户聚集的区域部署应用，就近提供服务。

每个 Location 都能提供独立、完整的对外服务。Location 与 Location 之间可以通过公网互联，建立隧道，实现控制流的传输。这里的控制流并不只是局限于指令类，还可以是用户的元数据等，但是不应该传输用户产生的数据，比如上传的图片、文档等。

由于业务的隔离，在每个 Location 会部署很多的 Kubernetes。单个 Kubernetes 的节点越少，越易于维护，爆炸半径越小，风险越可控。

但这也意味着，我们会有很多的集群，而管理和维护这些集群也需要人力投入。同时，集群版本差异，也会增加开发适配难度、影响应用技术选型、削弱积累的运维经验价值。

如上图，业务具有一定规模时，我们可以进行集群的合并。

在早期，为了规避风险，集群数量会非常大，一个部门上百个集群会给集群管理、维护带来巨大成本。

集群维护者，每天关注的是资源不足、内存泄露、拉不到镜像、增删节点、权限不够、配置差异等等。而另一方面看到的是，有些新的集群负载很低、内核版本很高，用户没有反馈问题。这也是大量小集群的弊端，维护成本高，HPA 伸缩空间有限。

通过合并集群，能够有效提高集群的整体负载率。但随之而来的还有超大规模集群带来的各种问题：

解决了这些问题之后会带来一系列的收益:

伴随着对 Kubernetes 及周边技术栈的深入挖掘，会培养一批对云原生更具见解的技术人员。

首先需要达成共识的是，在运维能力允许的情况下，大集群比大量的小集群要好。

其次是能在集群内完成的事情就不要跨集群。在早期阶段，由于服务分布于各个小集群中，频繁的跨集群服务调用，不仅性能低下，而且维护转发规则成本极高。

虽然通过合并集群能够解决这些问题，但是在后期，单一的大集群是无法满足单 Location 的大流量冲击的。因此，会有下面这张图：

在一个 Location，我们划分若干的 Region，每个 Region 是一个大集群，Region 与 Region 之间通过内网线路互联，既能够传输控制流，也能够传输用户数据。

当然，如果对业务架构进行了单元化，那么每个集群就是一个 Unit 。这样不仅对开发人员会更加清晰，而且无论运维人员是否熟悉 Kubernetes 都能很快理解架构融入团队。

如上图，一个 Region 包含若干个单元。这些单元所属不同环境、不同业务，但是在架构上是对等的，通过统一的平台软件，我们能够无差别的管理这些单元。

本文主要是涉及在多区域部署 Kubernetes 的一些思考。这些内容起源于工作上正在经历的一次应用架构大调整。我将海外、国内的业务与应用架构放在一起，发现他们只是所处的业务阶段不同而已，在架构演进上是一致的。

起初是业务量小，快速部署了很多小的 Kubernetes 集群上线业务；随着运维能力的提升，集群规模也越来越大；但无限大下去也是不可能的，最终还是会归回到一种可扩展的单元化集群的方案。