云原生时代， Kubernetes 多集群架构初探

为何咱们须要多集群？

近年来，多集群架构已经成为“老生常谈”。咱们喜欢高可用，喜欢异地多可用区，而多集群架构天生就具有了这样的能力。另外一方面咱们也但愿经过多集群混合云来下降成本，利用到不一样集群各自的优点和特性，以便使用不一样集群的最新技术（如 AI、GPU 集群等）。

就是由于这种种缘由，多集群几乎成为了云计算的新潮流，而被谈及最多而且落地的多集群场景主要有这三类：

一类用于应对“云突发”。以下图 1 所示，正常状况下用户使用本身的 IDC 集群提供服务，当应对突发大流量时，迅速将应用扩容到云上集群共同提供服务，将多集群做为备用资源池。该模式通常针对无状态的服务，能够快速弹性扩展，主要针对使用 CPU、内存较为密集的服务，如搜索、查询、计算等类型的服务。

第二类用于“云容灾”。以下图 2 所示，一般主要服务的集群为一个，另外一个集群周期性备份。或者一个集群主要负责读写，其余备份集群只读。在主集群所在的云出现问题时能够快速切换到备份集群。该模式可用于数据量较大的存储服务。

第三类则用于“异地多活”。如图 3 所示，与“云容灾”的主要区别是数据是实时同步的，多集群均可以同时读写。这种模式一般针对极其重要的数据，如全局统一的用户帐号信息等。

可是多集群同时也带来了巨大的复杂性，一方面如何让应用能够面向多集群部署分发，另外一方面是但愿应用真正能作到多集群之间灵活切换，想到传统应用迁移的难度可能就已经让咱们望而却步了。面向多集群，咱们依然缺少足够成熟的应用交付和管理的能力。

多集群的最后一千米

早在 2013 年，很多老牌云计算厂商就已经在聊“为何要多集群”，并开始倡导多集群是“Next Big Thing”。

然而残酷的现实倒是，每个不一样的云、每个数据中心都是一套本身的 API 与设计方式，所谓“多集群”多数状况下只是厂商 A 主动集成不一样类型集群的一套接入层。

这种背景下的多集群一直以来都以架构复杂著称，具体表现就是各个厂商发布会上使人眼花缭乱的多集群 / 混合云解决方案架构图，以下 图 4 就是一个传统的多集群企业级解决方案架构图，不得不说，咱们很难彻底理解图中的全部细节。

这种背景下的多集群技术，其实更像是厂商对一个封闭产品的代名词。不一样厂商的云有不一样的 API、不一样的能力特性，厂商们在这之上架构的多集群、混合云解决方案，大量的精力都是在适配和整合不一样集群平台上的各种能力。

而对于用户，最终的结果又会是另外一种形式的绑定。这样的多集群没法造成生态，也许这就是咱们迟迟没法面向这种多集群构建统一的应用交付、构建真正多集群能力的缘由。

Kubernetes：全世界数据中心的统一 API

不过，伴随着云原生理念的迅速普及，“步履蹒跚”的多集群理念却迎来了一个很是关键的契机。

从 2015 年 CNCF 成立到如今，短短四年多的时间，其组织下就孵化了数十个项目，吸引了近四百位企业级会员的加入，项目贡献人数达到六万三千多人，而每一年参与 CNCF 官方活动的人数也早已超过了十万人， CNCF Lanscape 下符合云原生标准的项目已经达到了上千个。

这种 Kubernetes 以及云原生技术体系迅速崛起的直接结果，就是在全部公有云之上， Kubernetes 服务都已经成为了毋庸置疑的一等公民；而全世界几乎全部的科技公司和大量的企业终端用户，也都已经在本身的数据中内心使用 K8s 来进行容器化应用的编排与管理。

不难看到，Kubernetes 正在迅速成为全世界数据中心的统一 API。

这层统一而标准的 API 之下，多集群和混合云的能力才开始真正体现价值。

Kubernetes 和它所推崇的声明式容器编排与管理体系，让软件交付自己变得愈来愈标准化和统一化，而且实现了与底层基础设施的彻底解耦；而另外一方面，云原生技术体系在全部公有云和大量数据中内心的落地，使得软件面向一个统一的 API 实现“一次定义，处处部署”成为了可能。

Kubernetes API 在全世界数据中内心的普及，终于让多集群和混合云理念有了一个坚实的事实基础。而伴随着软件产业对提高效率、下降成本的巨大渴望，云原生加持下的云计算飞轮终于启动，并将越飞越快。

多集群时代的 “ The Platform for Platform”

你们可能据说过，Kubernetes 项目的本质实际上是 Platform for Platform，也就是一个用来构建“平台”的“平台”。

相比于 Mesos 和 Swarm 等容器管理平台，Kubernetes 项目最大的优点和关注点，在于它始终专一于如何帮助用户基于 Kubernetes 的声明式 API ，快速、便捷的构建健壮的分布式应用，而且按照统一的模型（容器设计模式和控制器机制）来驱动应用的实际状态向指望状态逼近和收敛。

而当 The Platform for Platform 的特质和多集群链接在一块儿， Kubernetes 的用户实际上直接拥有了面向多集群统一构建平台级服务的宝贵能力。

好比， kubeCDN 项目就是这样的一个典型案例，它的核心思想，就是直接基于全世界公有云上的 K8s 集群来自建 CDN。借助云原生技术，巧妙的解决了使用传统 CDN 厂商服务的不少痛点（包括安全性没有保障、服务质量依赖外部厂商、CDN 厂商看重利润忽视部分用户需求、商业机密可能被泄露洞察等等）。在实现上，kubeCDN 在不一样的区域构建 K8s 集群，并经过 Route53 来根据延迟智能路由用户的请求到最优的集群。而做为搭建 CDN 的基础，Kubernetes 则帮助用户整合了基础设施，其自己统一的 API 又使得用户能够快速分发内容部署应用。

不难看到，基于 Kubernetes 的多集群给了 kubeCDN 灾备和统一多集群资源的能力；而统一标准的 Kubernetes API 层，则把构建一个全球级别 CDN 的代价减小到了几百行代码的工做量。基于 K8s 的多集群混合云，正在为不一样的产业带来了新的活力和更多的想象空间。

云的将来，是面向多集群的应用交付

若是说多集群是云计算的将来，那么多集群的将来又是什么呢？

云原生技术的发展路径是持续输出“事实标准的软件”，而这些事实标准中，应用的弹性（resiliency）、易用性（usability）和可移植性（portability）是其所解决的三大本质问题。

• 应用的弹性对于云产品的客户来讲等价于业务可靠性和业务探索与创新的敏捷性，体现的是云计算所创造的客户价值，应用弹性的另外一个关注点在于快速部署、交付、以及在云上的扩缩容能力。这就须要完善的应用交付链路以及应用的云原生开发框架支撑；
• 其次，良好易用性才能更好地发挥应用的弹性。在微服务软件架构成为主流的情形下，易用性须要考虑经过技术手段实现对应用总体作全局性的治理，实现全局最优。这凸显了 Service Mesh 的服务能力；
• 最后，当应用具有良好的可移植性，实现多集群和混合云的战略将成为必然趋势。

就像 K8s 是云时代的操做系统，而在这操做系统之上构建的应用还须要一系列的开发、交付、管理工具。云计算的价值，最终会回归到应用自己的价值。而如何服务好这些应用，将成为云厂商们新一轮能力的体现。

在这条路径上，统一的云原生应用标准定义和规范，通用的应用托管和分发中心，基于 Service Mesh 的、跨云的应用治理能力，以及 K8s 原生的、面向多集群的应用交付和管理体系，将会持续不断的产生巨大的价值。

Kubernetes 项目在“多集群”上的探索

当前 K8s 围绕多集群也已经开始了许多项目，如 Federation V2，Cluster Registry，Kubemci 等。在这以前更早开始的项目是 Federation v1，可是现在已经逐渐被社区所废弃。这其中的主要缘由，在于 v1 的设计试图在 K8s 之上又构建一层 Federation API，直接屏蔽掉了已经取得普遍共识的 K8s API ，这与云原生社区的发展理念是相悖的。

而 RedHat 后来牵头发起的 Federation V2 项目， 则以插件的形式融入到 K8s API 中（即咱们熟悉的 CRD）。它提供了一个能够将任何 K8s API type 转换成有多集群概念的 federated type 的方法，以及一个对应的控制器以便推送这些 federated 对象 (Object)。而它并不像 V1 同样关心复杂的推送策略（V1 的 Federation Scheduler），只负责把这些 Object 分发到用户事先定义的集群去。

须要注意的是，这里被推送到这些集群上的对象，都来自于一个相同的模板，只有一些元数据会有差异。另外，被推送的 type 都须要制做 Fedrated type，这在 type 类型比较有限的时候才比较方便。

这也就意味着 Federation v2 的主要设计目标，实际上是向多集群推送 RBAC，policy 等集群配置信息：这些可推送资源类型是固定的，而每一个集群的配置策略格式也是基本相似的。

因此说，Federation v2 的定位暂时只是一个多集群配置推送项目。

然而，面向多集群交付应用背后每每是有着复杂的决策逻辑的。好比：集群 A 当前负载低，就应该多推一些应用上去。再好比，用户可能有成百上千个来自二方、三方的软件（ 都是 CRD + Operator）要面向多集群交付，在目前 Fed v2 的体系下，用户要去维护这些 CRD 的 Fedreted type，代价是很是大的。

面向应用的 Kubernetes 多集群架构初探

那么一个以应用为中心、围绕应用交付的多集群多集群管理该具有何种能力呢？这里面有三个技术点值得深刻思考：

1. 用户 Kubernetes 集群多是没有公网 IP、甚至在私有网络当中的：而不管用户的 Kubernetes 集群部署在任何位置，多集群服务都应该可以将它们接入进来，而且暴露完整的、没有通过任何修改的 Kubernetes API。这是用户进行应用交付的重要基础。
2. 以 GitOps 驱动的多集群配置管理中心：用户接入集群的配置管理，须要经过一个中心化的配置管理中心来推送和同步。但更重要的是，这些配置信息应该经过 GitOps、 以对用户彻底公开、透明、可审计的方式进行托管，经过 Git 协议做为多集群控制中心与用户协做的标准界面。
3. “托管式”而非“接管式”的统一鉴权机制：不管用户是在使用的是公有云上的 Kubernetes 服务，仍是自建 IDC 集群，这些集群接入使用的鉴权证书是由统一机构颁发的。云提供商，不该该存储用户集群的任何秘钥 (Credentials) 信息，而且应该提供统一的受权权限管理能力，容许用户对接入的任何集群作子用户受权。

多集群架构的基石：Kubernetes API 隧道

要将 Kubernetes 集群以原生 API 的托管方式接入到多集群管理体系当中，这背后主要的技术难点是“集群隧道”。

集群隧道会在用户的 Kubernetes 集群里安装一个 agent，使得用户的集群无需公网 IP，就能够被用户像使用公有云上的 Kubernetes 服务同样在公网访问，随时随地愉快的使用、管理、监控本身的集群，拥有统一的鉴权、权限、日志、审计、控制台等等一系列的功能。

集群隧道的架构也应该是简洁的。以下图 7 所示，其核心分为两层，下层是被托管的集群，在其中会有一个 Agent，Agent 一方面在被托管的集群中运行，能够轻易的在内网访问被托管的集群，另外一方面它经过公网与公有云接入层中的节点 (Stub) 构建一个隧道 (tunnel)。在上层，用户经过公有云统一的方式接入审计、鉴权、权限相关功能，经过访问 Stub，再经过隧道由 Agent 向用户本身的 Kubernetes 集群转发命令。

经过这样的层层转发，用户可使用公有云统一的鉴权方式透明的使用被托管的集群，而且公有云自己不该该触碰和存储用户的鉴权信息。要实现这样的集群隧道，多集群架构必需要能克服两大难题：

• 在用户访问时，API 接入公有云统一的证书管理，包括鉴权、权限、子用户受权等等。
• 在 API 转发到用户 Agent 时，再将请求变为 K8s 集群原有的受权访问，被托管集群的鉴权永远只存在集群自己。

这两大难题，是现有的开源 Tunnel 库、以及原生的四层转发与七层转发都不能彻底解决的，这里一一列举以下：

• ngrok：一个曾经颇有名，可是目前已经被废弃的项目，github 的 Readme 中明确的写着，“不要在生产环境使用”；
• go-http-tunnel：很简洁的项目，可是一方面源码的协议是 AGPL-3.0，意味着代码没法商用，另外一方面，在 kubectl 执行 exec 等命令时须要 hijack 链接，基于 http2 的 tunnel 在协议原理上就自然不知足这个功能；
• chisel: 一样很简洁的项目，底层基于 TCP 构建链接，而后巧妙的利用了 ssh 实现 tcp 链接的 session 管理和多路复用。可是依然没法解决在 tunnel 的一端 (Stub) 对接解析公有云的证书，验证后又在另外一端 (Agent) 使用 K8s 的 token 发起新的请求；
• rancher/remotedialer：rancher 的这个项目功能与 chisel 类似，基于 websocket，agent 直接把集群的 token 传递到了 Server 端，须要存储用户本身的集群鉴权信息，与咱们的目标不符；
• frp: 一个大而全的项目，有不少如 UI、Dashboard 等功能，可是依然没有直接知足咱们在 stub 端证书解析、agent 端 token 访问需求；
• apiserver-network-proxy：与 chisel 的功能很像，基于 grpc，刚开始没多久的项目，一样不能直接知足需求。

阿里云 Kubernetes 服务多集群架构

目前，在阿里云 Kubernetes 服务中（ ACK ）提供的多集群能力，遵循的正是上述“以应用为中心”的多集群架构。这个功能，以“接入已有集群”做为入口，以下图所示：

集群隧道

这个多集群架构如图 9 所示，跟上一节所述是基本一致的。具体来讲，阿里云的 ACK 服务（容器服务 Kubernetes 版）会在用户集群上安装一个 Agent，安装完毕后 Agent 只须要可以公网访问，用户就能够在 ACK 上使用本身的集群，经过 ACK 统一的鉴权方式体验原生的 K8s API。

长链接与长响应

在 Kubernetes 控制操做中，存在诸如 kubectl exec , kubectl port-forward 基于非 HTTP 协议的长链接以及 kubectl logs -f 这种反馈持续时间较长的长响应。它们对于通讯链路的独占使得 HTTP/2 的多路复用没法运做，Go 语言官方库中的 HTTP/1.1 自己也不支持协议升级，故而没法采用原生七层 HTTP 转发。

为了解决这两大难题，ACK 的隧道技术上采用了一系列策略进行应对：

• 使用原生七层转发，对转发数据进行证书识别，将 Kubernetes 权限注入，解决鉴权问题；
• 对于协议升级请求，劫持七层链路，使用四层链路，进而使用原生四层无感知转发，解决长链接问题；
• 只在发送请求方向上复用链路，每次反馈创建新链路，防止阻塞，解决长响应问题。

隧道高可用

除此以外，在 ACK 的隧道设计中，因为中间的链路（Agent 与 Stub）对于用户而言是透明的，在客户端以及目标集群的 API Server 正常运转的状况下，不能由于中间链路的故障致使没法链接，所以 ACK 隧道还提供了 Agent 与 Stub 的高可用能力，提升容错力，下降故障恢复时间。

Agent 高可用

容许多个 Agent 同时链接 Stub，多个 Agent 的存在不只能够高可用，还能够做为负载均衡来使用。

• 多 Agent 负载均衡 ：一方面，每一个 Agent 会定时向 Stub 发送当前的可用状态，另外一方面，Stub 进行数据包转发时，采用随机轮询的方式，选择一个可用的 Agent 转发；
• 多集群防干扰、集群切换：在多 Agent 的存在下，可能会涉及到 Agent 来自不一样的 Kubernetes 集群形成干扰，因此一样须要加入 Agent 的集群惟一 ID。当原先集群的全部链接都断开时，会进行集群切换。

Stub 高可用

在 Stub 端，因为客户端只会向同一个 IP 发送，多个 Stub 的存在须要使用 Kubernetes 的 Service 进行协调，例如可使用 LoadBalancer。可是，若是使用 LoadBalancer 对请求进行分流，一个重要问题是，因为长链接的存在，从客户端发出的信息多是上下文相关的而非互相独立的。TCP 四层分流会破坏上下文，因此 Stub 在同一时刻应当只能有一个在起做用。

在只有一个 Stub 运行的状况下，依然要保证其高可用，这里 ACK 隧道采用了 Kubernetes 的 Lease API 等高可用能力。所以 Stub 端的高可用虽然不能像 Agent 端同样起到分流分压做用，可是它提供滚动升级等能力。

结语

云的边界正在被技术和开源迅速的抹平。愈来愈多的软件和框架从设计上就再也不会跟某云产生直接绑定。毕竟，你没办法抚平用户对商业竞争担心和焦虑，也不可能阻止愈来愈多的用户把 Kubernetes 部署在全世界的全部云上和数据中内心。

在将来云的世界里，K8s 会成为连通“云”与“应用”的高速公路，以标准、高效的方式将“应用”快速交付到世界上任何一个位置。而这里的交付目的地，既能够是最终用户，也能够是 PaaS/Serverless ，甚至会催生出更加多样化的应用托管生态。“云”的价值，必定会回归到应用自己。

多集群与混合云的时代已经来临，以应用为中心的多集群多集群架构，才是云计算生态发展的必然趋势，你的云能够运行在任何地方，而咱们帮你管理。让咱们一块儿迎接面向应用的云原生多集群时代，一块儿拥抱云原生，一块儿关注应用自己的价值！

做者介绍：

孙健波，阿里云容器平台技术专家，Kubernetes 项目社区成员，负责 ACK 容器服务相关开发工做。
殷达，清华大学与卡内基梅隆大学计算机专业在读研究生，于阿里云容器平台部实习，主要参与 ACK 容器服务多云技术及云原生应用开发。

---

原文连接

本文为云栖社区原创内容，未经容许不得转载。