Harness Engineering

Tue, 09 Jun 2026 20:30:00 +0800

从架构视角深入解读 Harness 的设计哲学，帮助工程师建立对现代 CI/CD 平台的认知框架

一、Harness 到底是什么

一句话：Harness 是一个构建在 Kubernetes 之上的、以 Delegate 为核心执行引擎的、SaaS 化的软件交付平台。

这句话里有三个关键词，每一个都值得展开。

1. 构建在 Kubernetes 之上

Harness 的控制平面（Control Plane）是一组微服务，运行在 Kubernetes 集群中。这意味着：

弹性伸缩是天然能力，不是事后补丁
多租户隔离通过 K8s 的 namespace 和资源配额实现
服务治理依赖 K8s 原生的服务发现和负载均衡

这不是什么了不起的事——几乎所有现代 SaaS 产品都跑在 K8s 上。但关键在于，Harness 把 K8s 的能力向下暴露给了用户：你的 Pipeline 可以直接操作 K8s 集群进行部署，而不是通过一层中间转换。

2. Delegate 是核心执行引擎（重点）

这是理解 Harness 最关键的一个概念。

Delegate 是一个运行在你基础设施中的进程，负责执行 Pipeline 中的所有任务。它不是 Harness 帮你跑的——它跑在你的环境里。

为什么要这样设计？因为软件交付涉及的操作，绝大多数都需要访问内网资源：代码仓库、制品库、K8s 集群、数据库、云账号。如果这些操作全部由 Harness 的 SaaS 控制平面来执行，就意味着你的内网资源必须对 Harness 开放——这在安全合规层面几乎不可接受。

Delegate 的架构解决了这个问题：

┌─────────────────────────────────────────────────────┐
│ Harness SaaS控制平面 │
│ (Pipeline 编排、状态管理、UI、API) │
└──────────────────────┬──────────────────────────────┘
 │ 出站连接（Delegate 主动拉取任务）
 │ ← 不需要入站端口暴露
┌──────────────────────▼──────────────────────────────┐
│ 你的基础设施 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Delegate │ │ Delegate │ │ Delegate │←可部署多个 │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌───▼───┐ ┌────▼───┐ ┌────▼───┐ │
│ │K8s集群 │ │代码仓库 │ │云账号 │ │
│ └───────┘ └────────┘ └────────┘ │
└─────────────────────────────────────────────────────┘

核心设计要点：

Agent Workflow on LinyingBlog

Harness Engineering

一、Harness 到底是什么

1. 构建在 Kubernetes 之上

2. Delegate 是核心执行引擎（重点）