从单体Harness到联邦Harness架构演进

从单体Harness到联邦Harness架构演进：解锁多云多集群部署下的DevOps无限潜能

关键词

单体Harness、联邦Harness、DevOps平台、多云架构、微服务编排、多集群管理、联邦数据同步

摘要

随着云计算技术的普及，企业的IT基础设施逐渐从单云单集群向多云混合、多集群分散的模式演进——有的核心业务跑在AWS EKS，有的数据密集型应用依赖阿里云ACK的GPU集群，边缘IoT设备的部署则绑定Azure IoT Edge，甚至还有本地私有云集群承载敏感合规数据。此时，传统的单体Harness DevOps平台会面临部署延迟、资源浪费、合规性挑战、高可用性瓶颈等一系列痛点。

本文将以讲故事+一步步推理的方式，带你从认识单体Harness的优缺点开始，逐步剖析联邦Harness的核心概念、技术原理、实现路径，再通过具体的案例、代码示例、系统架构设计，展示联邦Harness如何解决上述问题。最后，我们还会探讨联邦Harness的行业发展趋势、未来挑战以及最佳实践，帮助你判断是否需要将自己的DevOps平台迁移到联邦架构，以及迁移时需要注意什么。全文约12000字，适合DevOps工程师、架构师、技术负责人以及对多云多集群DevOps感兴趣的开发者阅读。

1. 背景介绍

1.1 核心概念

本节我们将先快速过一遍文章中后续会反复用到的几个基础核心概念（更详细的核心概念解析会放在第2章）：

1. 单体Harness：将所有Harness DevOps组件（如UI、控制平面、执行代理、数据库、消息队列、镜像仓库集成层等）部署在同一个Kubernetes集群或云虚拟机组中的DevOps平台架构。
2. 联邦Harness：采用“中央联邦控制平面（Hub）+ 区域/环境/集群专属联邦成员平面（Spoke）”的分布式架构，Hub负责全局策略、多集群资源调度、跨集群可见性管理，Spoke则负责本地集群的具体部署、测试、监控执行，两者通过加密的联邦数据同步协议通信。
3. 多云混合架构：同时使用公共云（如AWS、Azure、阿里云）、私有云（如VMware vSphere、OpenStack）以及本地物理服务器的IT基础设施架构。
4. 多集群管理：对多个部署在不同区域、不同云平台、不同环境（如开发、测试、预发、生产）的Kubernetes集群进行统一的资源分配、应用部署、权限控制、监控告警的技术。
5. 联邦数据同步：在Hub和Spoke之间、Spoke和Spoke之间（可选），安全、高效、一致地同步DevOps核心数据（如流水线配置、环境变量、用户权限、执行日志摘要、部署状态等）的技术。

1.2 问题背景

1.2.1 企业IT基础设施的演变历程

让我们先把时间倒回2010年左右——那时候，“上云”对大部分企业来说还是一个“高大上”的概念，大多数中小企业的IT基础设施都是本地单数据中心+单一物理服务器集群，大型企业可能有几个本地数据中心，但仍然以“统一管理、集中部署”为主。

2015年左右，Kubernetes正式发布v1.0版本，容器化技术开始普及，企业的IT基础设施逐渐转向本地/单云Kubernetes集群，这时候，单体架构的DevOps工具（如早期的Jenkins、单体Harness）刚好能够满足需求——所有组件集中在一个集群，部署简单，维护方便，数据一致性容易保证。

但从2020年开始，情况发生了翻天覆地的变化：

• 业务全球化：企业需要将应用部署在靠近用户的区域，以降低网络延迟，提升用户体验——比如电商企业在东南亚部署AWS集群，在欧洲部署Azure集群，在中国部署阿里云集群；
• 成本优化：不同云平台的定价策略不同（比如阿里云的OSS存储比S3便宜，AWS的EC2 Spot实例比Azure的Batch更适合批处理任务），企业开始采用“多云采购策略”，哪里便宜用哪里；
• 合规性要求：很多国家和地区出台了严格的数据隐私法规（如欧盟的GDPR、中国的《个人信息保护法》），要求某些敏感数据（如用户的身份证号、银行卡号、医疗记录等）必须存储在特定的区域或私有云中，不能跨区域或跨云平台传输；
• 高可用性与灾备：为了避免单云单集群故障导致业务中断，企业开始采用“多集群灾备策略”——比如在AWS的us-east-1和us-west-2各部署一个生产集群，其中一个故障时，另一个可以快速接管；
• 边缘计算的兴起：随着IoT设备的普及，越来越多的应用需要部署在边缘节点（如工厂的车间、城市的路灯杆、加油站的POS机），这些边缘节点的计算资源有限，网络连接不稳定，无法和中央云平台保持实时通信。

1.2.2 单体Harness面临的挑战

当企业的IT基础设施从“单云单集群”转向“多云混合多集群边缘一体化”时，单体Harness DevOps平台的缺点就暴露无遗了，我们可以通过一个电商企业的真实场景来具体分析：

假设某电商企业叫“云购天下”，之前的IT基础设施是“阿里云上海单数据中心+ACK单集群”，DevOps平台是部署在同一ACK集群的单体Harness，一切都运行得很好。但随着业务的发展，云购天下做了以下几个决策：

1. 在欧洲部署了一个AWS eu-west-1的生产集群，以降低欧洲用户的访问延迟；
2. 在阿里云深圳部署了一个GPU ACK集群，用于运行商品推荐系统的训练任务；
3. 建立了一个本地私有云集群（基于OpenStack），用于存储用户的身份证号、银行卡号等敏感数据；
4. 在全国300多个城市的加油站POS机上部署了边缘IoT应用（基于Azure IoT Edge），用于实时处理用户的支付数据。

现在，云购天下仍然使用原来的单体Harness来管理所有这些集群，结果出现了以下问题：

（1）部署延迟高

云购天下在欧洲AWS集群部署应用时，流水线需要先从上海ACK集群的单体Harness拉取镜像仓库配置、流水线脚本、环境变量等，然后再通过公网连接到欧洲AWS集群执行部署——上海到欧洲的公网延迟通常在200ms以上，更不用说镜像传输的时间了！假设镜像大小是1GB，上海到欧洲的公网带宽是100Mbps，那么镜像传输的时间就是80秒，加上拉取配置、执行部署的时间，整个部署流程可能需要10分钟以上——这对于需要快速迭代的电商企业来说，简直是“噩梦”！

（2）资源浪费严重

云购天下的阿里云深圳GPU集群主要用于每周一、周三、周五的晚上进行商品推荐系统的训练，其他时间基本处于闲置状态——但因为单体Harness的所有执行代理都部署在上海ACK集群，GPU集群无法运行本地的执行代理，所以训练任务只能通过上海ACK集群的代理远程触发，这不仅增加了网络延迟，还浪费了GPU集群的本地计算资源！

另外，边缘IoT应用的部署频率很低（通常每月一次），但边缘节点的数量很多（300多个）——为了管理这些边缘节点，单体Harness需要和所有边缘节点保持实时的WebSocket连接，这会占用上海ACK集群大量的带宽和CPU资源，即使边缘节点没有部署任务！

（3）合规性风险大

云购天下的本地私有云集群存储了用户的敏感数据，GDPR和《个人信息保护法》要求这些敏感数据不能跨区域或跨云平台传输——但因为单体Harness的所有组件（包括数据库、消息队列）都部署在上海ACK集群，所以如果云购天下在本地私有云集群部署应用时需要用到敏感的环境变量（如数据库密码、API密钥等），这些环境变量必须先上传到上海ACK集群的单体Harness数据库，然后再通过公网传输到本地私有云集群，这就存在严重的合规性风险！

另外，欧洲用户的支付数据必须存储在欧洲AWS集群的本地数据库中，但单体Harness的执行日志摘要（包括支付数据的部分元数据）会自动上传到上海ACK集群的单体Harness数据库，这也违反了GDPR的要求！

（4）高可用性瓶颈明显

云购天下的单体Harness部署在上海ACK集群，如果上海ACK集群出现故障（比如阿里云上海数据中心断电、ACK集群升级失败等），那么整个DevOps平台都会瘫痪——欧洲AWS集群、阿里云深圳GPU集群、本地私有云集群、边缘IoT节点都无法进行部署、测试、监控！这对于需要7×24小时服务的电商企业来说，损失是不可估量的！

（5）扩展性差

随着业务的发展，云购天下的集群数量还会继续增加（比如可能在北美部署AWS us-east-1集群，在日本部署GCP集群），流水线的数量也会越来越多（比如现在有1000条流水线，未来可能有10000条）——但单体Harness的控制平面和执行代理是紧耦合的，所有的流水线调度都由中央控制平面负责，当集群数量和流水线数量增加到一定程度时，中央控制平面就会成为性能瓶颈，无法及时调度任务！

另外，不同的集群有不同的技术栈（比如欧洲AWS集群用的是Terraform+Helm，阿里云深圳GPU集群用的是Kubeflow+Kustomize，边缘IoT节点用的是Azure IoT Edge SDK），但单体Harness的扩展插件是集中管理的，无法针对不同的集群安装不同的扩展插件——这就导致很多技术栈无法在单体Harness中得到很好的支持！

1.3 目标读者

本文的目标读者包括但不限于：

1. DevOps工程师：负责日常的流水线配置、应用部署、监控告警工作，需要了解联邦Harness的具体操作和最佳实践；
2. DevOps架构师：负责DevOps平台的架构设计和技术选型，需要了解联邦Harness的核心概念、技术原理和实现路径；
3. 技术负责人/CTO：负责企业的IT战略规划，需要判断是否需要将自己的DevOps平台迁移到联邦架构，以及迁移时需要注意什么；
4. 多云多集群管理工程师：负责多云混合多集群的资源分配、权限控制、监控告警工作，需要了解联邦Harness如何与现有多集群管理工具（如AWS EKS Distro、Azure Arc、阿里云ACK One、Rancher）集成；
5. 对多云多集群DevOps感兴趣的开发者：想要了解最新的DevOps技术趋势，提升自己的技术水平。

1.4 核心问题或挑战

在本文中，我们将重点解决以下几个核心问题或挑战：

1. 什么是联邦Harness？它和单体Harness、普通多集群Harness有什么区别？
2. 联邦Harness的核心概念有哪些？它们之间的关系是什么？
3. 联邦Harness的技术原理是什么？比如联邦数据同步是如何实现的？多集群资源调度是如何工作的？
4. 如何从零开始搭建一个联邦Harness？需要哪些工具和环境？
5. 联邦Harness有哪些实际的应用场景？
6. 将单体Harness迁移到联邦Harness需要注意什么？有哪些最佳实践？
7. 联邦Harness的未来发展趋势是什么？有哪些潜在的挑战和机遇？

2. 核心概念解析

2.1 核心概念详细解释

在上一节的背景介绍中，我们已经快速过了一遍文章中后续会反复用到的几个基础核心概念，现在我们将用生活化的比喻来详细解释这些概念，以及联邦Harness中的其他核心概念。

2.1.1 比喻的引入：从“中央厨房”到“中央厨房+区域分厨房+社区配送站”

为了让大家更容易理解联邦Harness的核心概念，我们可以将DevOps平台比作餐饮连锁企业的后厨系统：

• 应用程序比作各种菜品；
• Kubernetes集群/云虚拟机组/边缘节点比作餐厅的厨房/区域分厨房的厨房/社区配送站的简易厨房；
• 部署流水线比作菜品的制作流程；
• 环境变量/配置文件比作菜品的配方和调料；
• 执行日志/部署状态比作菜品的制作记录和销售状态；
• 用户权限比作后厨人员的岗位职责（比如大厨可以修改配方，学徒只能洗菜切菜）。

（1）单体Harness：“只有一个中央厨房的餐饮连锁企业”

假设某餐饮连锁企业叫“味美鲜”，一开始只有一家餐厅，后厨系统就是“只有一个中央厨房的餐饮连锁企业”——所有的菜品都在中央厨房制作，然后通过配送员送到餐厅的前台；所有的配方和调料都存放在中央厨房的仓库里；所有的后厨人员都在中央厨房工作；所有的制作记录和销售状态都存放在中央厨房的收银系统里。

这和单体Harness的架构完全一致：

• 所有的部署、测试、监控任务都由中央控制平面调度，由中央执行代理执行；
• 所有的流水线配置、环境变量、配置文件都存放在中央数据库里；
• 所有的用户权限都由中央权限系统管理；
• 所有的执行日志、部署状态都存放在中央监控系统里。

（2）普通多集群Harness：“中央厨房制作半成品，送到各个餐厅的厨房加热”

随着业务的发展，味美鲜开了10家餐厅，分布在城市的各个角落——这时候，如果所有的菜品都在中央厨房制作，然后通过配送员送到餐厅的前台，就会出现以下问题：

• 配送时间长，菜品容易变凉，影响口感；
• 配送成本高，需要雇佣大量的配送员；
• 中央厨房的压力大，高峰期可能无法及时制作所有的菜品。

为了解决这些问题，味美鲜改进了后厨系统：中央厨房制作半成品，送到各个餐厅的厨房加热——这样，配送时间就缩短了，配送成本也降低了，中央厨房的压力也减小了。

这和普通多集群Harness的架构基本一致：

• 中央控制平面仍然负责所有的调度、配置、权限管理；
• 执行代理部署在各个集群本地，负责本地集群的具体部署、测试、监控执行；
• 但所有的流水线配置、环境变量、配置文件仍然存放在中央数据库里，执行代理需要通过公网连接到中央数据库拉取这些数据；
• 所有的执行日志、部署状态仍然存放在中央监控系统里，执行代理需要通过公网连接到中央监控系统上传这些数据。

（3）联邦Harness：“中央厨房+区域分厨房+社区配送站”

随着业务的进一步发展，味美鲜开了100家餐厅，分布在全国30多个城市，甚至在海外也开了几家餐厅——这时候，“中央厨房制作半成品，送到各个餐厅的厨房加热”的后厨系统又出现了以下问题：

• 不同城市的用户口味不同，需要修改配方，但配方存放在中央厨房的仓库里，修改起来很麻烦；
• 某些城市的食材供应特殊（比如四川的辣椒、广东的海鲜），需要在当地采购，但食材的采购权仍然在中央厨房；
• 海外餐厅的食材运输成本高，而且某些食材（比如新鲜的牛奶）不能长时间运输，需要在当地制作；
• 中央厨房的收银系统如果出现故障，所有餐厅的销售记录都无法查询，影响财务核算。

为了解决这些问题，味美鲜再次改进了后厨系统，采用了**“中央厨房+区域分厨房+社区配送站”的三级架构**：

• 中央厨房（对应联邦Harness的Hub）：
  • 负责制定全局的菜品标准（比如所有餐厅的宫保鸡丁必须用鸡腿肉，不能用鸡胸肉）；
  • 负责全局的食材采购策略（比如某些常用食材由中央厨房统一采购，以降低成本）；
  • 负责全局的人员培训和岗位职责制定；
  • 负责全局的财务核算和销售数据分析；
  • 不需要直接制作菜品，只需要制作一些核心的调料和半成品，送到各个区域分厨房。
• 区域分厨房（对应联邦Harness的区域Spoke）：
  • 负责制定本区域的菜品配方（比如在四川的区域分厨房，可以将宫保鸡丁的辣椒用量增加一倍）；
  • 负责本区域的特殊食材采购（比如四川的辣椒、广东的海鲜）；
  • 负责本区域的半成品制作和菜品加工；
  • 负责本区域的餐厅后厨管理；
  • 负责本区域的销售记录存储和本地财务核算；
  • 只需要和中央厨房保持定期的通信，同步核心的调料配方、人员岗位职责、全局销售数据分析等，不需要实时通信。
• 社区配送站（对应联邦Harness的环境/集群/边缘Spoke）：
  • 负责本社区的简易菜品制作（比如加热汉堡、制作奶茶）；
  • 负责本社区的外卖配送；
  • 不需要和中央厨房直接通信，只需要和所属的区域分厨房保持定期的通信。

这和联邦Harness的架构几乎完全一致！接下来，我们将基于这个比喻，详细解释联邦Harness中的其他核心概念。

2.1.2 联邦Harness的核心架构组件

联邦Harness的核心架构组件可以分为两类：Hub组件和Spoke组件。

（1）Hub组件：中央联邦控制平面

Hub是联邦Harness的“大脑”，负责全局的策略制定、多集群资源调度、跨集群可见性管理、全局用户权限管理、全局财务核算（如果是SaaS版本的Harness）等。Hub组件通常部署在一个高可用性的Kubernetes集群中（比如AWS的us-east-1和us-west-2的跨AZ集群，或者阿里云的上海和深圳的跨地域集群），以避免单点故障。

Hub组件主要包括以下几个部分：

1. Hub UI：联邦Harness的全局管理界面，用户可以在这里查看所有Spoke的状态、管理全局策略、调度跨集群任务、查看全局监控数据等。
2. Hub API Server：联邦Harness的全局API入口，负责处理Hub UI、第三方工具（如Slack、Jira、GitHub）的请求，以及和Spoke组件的通信。
3. Hub Policy Engine：联邦Harness的全局策略引擎，负责制定和执行全局的DevOps策略（比如“所有生产环境的部署必须经过两个人的审批”、“所有敏感的环境变量不能存储在Hub数据库中”、“所有欧洲集群的执行日志不能传输到欧盟以外的区域”等）。
4. Hub Resource Scheduler：联邦Harness的全局资源调度器，负责调度跨集群的任务（比如“将商品推荐系统的训练任务调度到GPU资源最充足的集群”、“将Web应用的灰度发布任务同时调度到欧洲和中国的生产集群”等）。
5. Hub Global Database：联邦Harness的全局数据库，负责存储全局的非敏感数据（比如全局策略、全局用户权限、Spoke的基本信息、跨集群任务的基本信息、全局监控数据的摘要等）。
6. Hub Message Queue：联邦Harness的全局消息队列，负责Hub组件之间的通信，以及Hub和Spoke之间的异步通信。
7. Hub Identity Provider (IdP)：联邦Harness的全局身份提供商，负责统一管理所有用户的身份认证（比如支持LDAP、OAuth2.0、SAML等），以及全局的用户权限分配。
8. Hub Observability Platform：联邦Harness的全局可观测性平台，负责收集、聚合、分析所有Spoke的可观测性数据（如执行日志摘要、部署状态、性能指标、告警信息等），并在Hub UI上展示。

（2）Spoke组件：区域/环境/集群专属联邦成员平面

Spoke是联邦Harness的“手脚”，负责本地集群的具体部署、测试、监控执行，本地敏感数据的存储，本地策略的制定和执行等。Spoke组件通常部署在对应的本地Kubernetes集群/云虚拟机组/边缘节点中，以降低网络延迟，减少资源浪费，保证合规性。

根据部署位置和功能的不同，Spoke可以分为以下三类：

1. 区域Spoke：部署在某个区域的高可用性Kubernetes集群中（比如AWS eu-west-1的跨AZ集群，或者阿里云深圳的跨AZ集群），负责管理该区域内的所有生产/预发/测试集群。
2. 环境/集群Spoke：部署在某个特定的环境或集群中（比如本地私有云集群，或者阿里云深圳GPU集群），负责管理该环境或集群的所有部署、测试、监控任务。
3. 边缘Spoke：部署在边缘节点中（比如工厂的车间、城市的路灯杆、加油站的POS机），负责管理该边缘节点的所有部署、测试、监控任务——边缘Spoke的组件通常比较轻量级，因为边缘节点的计算资源有限，网络连接不稳定。

不管是哪一类Spoke，主要组件都包括以下几个部分：

1. Spoke UI（可选）：联邦Harness的本地管理界面，用户可以在这里查看本地集群的状态、管理本地策略、调度本地任务、查看本地监控数据等——如果用户只需要通过Hub UI管理所有集群，可以不部署Spoke UI。
2. Spoke API Server：联邦Harness的本地API入口，负责处理Spoke UI（如果有）、本地工具的请求，以及和Hub组件的通信。
3. Spoke Policy Engine：联邦Harness的本地策略引擎，负责制定和执行本地的DevOps策略（比如“本地私有云集群的部署只能在本地私有云网络中进行”、“本地GPU集群的训练任务只能在晚上10点到第二天早上6点之间运行”等）——本地策略的优先级高于全局策略。
4. Spoke Execution Agent Pool：联邦Harness的本地执行代理池，负责执行本地集群的所有部署、测试、监控任务——执行代理可以根据任务的类型和资源需求动态扩缩容。
5. Spoke Local Database：联邦Harness的本地数据库，负责存储本地的敏感数据（比如本地集群的环境变量、配置文件、执行日志的详细内容等）——这些敏感数据不会传输到Hub数据库中，除非用户明确授权。
6. Spoke Message Queue：联邦Harness的本地消息队列，负责Spoke组件之间的通信，以及Spoke和Hub之间的异步通信。
7. Spoke Identity Provider (IdP)（可选）：联邦Harness的本地身份提供商，负责统一管理本地用户的身份认证——如果用户只需要通过Hub IdP管理所有身份，可以不部署Spoke IdP。
8. Spoke Observability Platform：联邦Harness的本地可观测性平台，负责收集、存储、分析本地集群的可观测性数据（如执行日志的详细内容、部署状态、性能指标、告警信息等），并在Spoke UI（如果有）上展示——同时，本地可观测性平台会定期将可观测性数据的摘要（不含敏感信息）同步到Hub Observability Platform。
9. Spoke Sync Agent：联邦Harness的本地同步代理，负责Spoke和Hub之间的加密数据同步——这是联邦Harness最核心的组件之一，我们将在第3章详细解释它的工作原理。

2.1.3 联邦Harness的核心功能特性

基于“中央厨房+区域分厨房+社区配送站”的架构，联邦Harness具备以下几个核心功能特性：

1. 低延迟部署：因为执行代理部署在本地集群，流水线配置、环境变量、配置文件（非敏感的）可以提前同步到本地数据库，所以部署流程不需要通过公网连接到Hub，大大降低了网络延迟——比如云购天下在欧洲AWS集群部署应用时，部署时间可以从原来的10分钟缩短到1分钟以内！
2. 资源本地利用：因为执行代理部署在本地集群，所以本地集群的计算资源（比如CPU、内存、GPU）可以得到充分利用——比如云购天下的阿里云深圳GPU集群可以直接运行本地的执行代理，触发商品推荐系统的训练任务，不需要通过上海ACK集群的代理远程触发！
3. 合规性保证：因为本地的敏感数据（如环境变量、配置文件、执行日志的详细内容）存储在本地数据库中，不会传输到Hub数据库中，除非用户明确授权，所以可以满足GDPR、《个人信息保护法》等严格的数据隐私法规——比如云购天下的本地私有云集群的敏感环境变量不会上传到上海ACK集群的Hub数据库，欧洲AWS集群的执行日志的详细内容也不会传输到欧盟以外的区域！
4. 高可用性与灾备：因为Hub部署在高可用性的跨AZ/跨地域集群中，Spoke部署在本地集群中，两者之间是松耦合的，所以即使Hub出现故障，Spoke仍然可以独立运行本地的部署、测试、监控任务——比如云购天下的上海ACK集群的Hub出现故障，欧洲AWS集群、阿里云深圳GPU集群、本地私有云集群、边缘IoT节点仍然可以正常工作！
5. 线性扩展性：因为Hub和Spoke是松耦合的，所有的本地任务调度都由Spoke负责，只有跨集群的任务调度才由Hub负责，所以当集群数量和流水线数量增加时，只需要增加Spoke的数量，或者升级Spoke的硬件配置，就可以线性扩展联邦Harness的性能——比如云购天下未来在北美部署AWS us-east-1集群，只需要在该集群部署一个新的Spoke，就可以管理该集群的所有任务，不需要升级Hub的硬件配置！
6. 灵活的技术栈支持：因为Spoke的扩展插件是本地管理的，可以针对不同的集群安装不同的扩展插件，所以联邦Harness可以支持几乎所有的主流技术栈——比如云购天下的欧洲AWS集群可以安装Terraform+Helm的扩展插件，阿里云深圳GPU集群可以安装Kubeflow+Kustomize的扩展插件，边缘IoT节点可以安装Azure IoT Edge SDK的扩展插件！

2.2 概念间的关系和相互作用

2.2.1 概念核心属性维度对比

为了让大家更容易理解单体Harness、普通多集群Harness、联邦Harness之间的区别，我们可以从以下几个核心属性维度进行对比：

2.2.2 概念联系的ER实体关系图

为了让大家更容易理解联邦Harness的核心架构组件之间的实体关系，我们可以用Mermaid ER图来表示：