Skip to content
Published on

Flux 2.9 与 Weaveworks 之后的两年 — 失去赞助商的 GitOps 项目是怎么撑下来的

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 — 「这个项目的未来有危险吗?」

2024 年 1 月 14 日，fluxcd/flux2 仓库里出现了一个正是这个标题的讨论 — "Is the project future at risk?"。正文简短而直接：Weaveworks 已经把项目预算烧完了，那些全职做 Flux 的开发者面临的局面是，要么另找工作，要么自掏腰包继续贡献。第二天，核心维护者 Stefan Prodan 亲自回复了 — 「是的，情况属实(Yes this is accurate)」。他还补了一句，很快会有官方回应，请大家期待。

几周后真正发生的事更糟。做出 Flux 的公司 Weaveworks 宣布于 2024 年 2 月初停止商业运营。那个造出 GitOps 这个词的公司、Flux 大多数维护者的雇主，消失了。

本文是此后两年半里真正发生之事的记录。契机是 2026 年 6 月 30 日发布的 Flux v2.9.0 — 赞助商崩塌之后的第六个次要版本。对于「开源项目失去企业赞助商就会死吗?」这个问题，Flux 是眼下数据最丰富的案例研究。不靠推测，只用发布日期、维护者名单、官方公告这类一手资料来重构一遍。

时间线 — 只放可验证的事实

日期全部是从公开资料里直接确认的。

  • 2022-11-30 — Flux 成为 CNCF 毕业(Graduated)项目。当时没人料到，这个治理身份在一年后对生存起了决定性作用。
  • 2024-01-14 — 社区提出「项目的未来有危险吗」这个讨论。第二天 Stefan Prodan 承认属实。
  • 2024 年 2 月初 — Weaveworks 宣布停止商业运营(CNCF 公告的原话是 "announced that it would cease commercial operations at the start of February")。
  • 2024-02-15 — 英国安全咨询公司 ControlPlane 宣布把核心维护者 Stefan Prodan 和 Soule Ba 招为正式员工。同时启动符合 FIPS 的企业版 Flux 发行版业务。
  • 2024-03-19 — CNCF 在 KubeCon EU 上发布了支持 Flux 的企业名单。Aenix、Aviator、Microsoft Azure、ControlPlane、Edgecell、Fairwinds、Giant Swarm、Gimlet、GitLab、Nearform、OpsMx、OpsWorks、OSO、Teracloud、TNG — 共 15 家。Microsoft 的评论尤其实在：「Flux 是驱动 Azure 上多种 GitOps 体验的引擎(Flux is the engine that powers several GitOps experiences on Azure)。」
  • 2024-05-13 — 关停之后的第一个次要版本 v2.3.0。
  • 2026-06-30 — v2.9.0 发布。关停之后的第六个次要版本。

这里有一处值得留意。在 Weaveworks 垮掉之前的 2023 年初，GitLab 就已经把 Flux 集成为自家 Kubernetes agent 的推荐 GitOps 方案，而 Microsoft 则把它当作 Azure(AKS 的 GitOps 插件)的底座。也就是说，Flux 早就不是「一家公司的产品」，而已经成了好几家大厂产品里的零件，这份依赖正是救援行动的动机。法国电信运营商 Orange 也在 CNCF 的公告里明确说，自家电信网络的 GitOps 框架就是 Flux。

发布节奏实测 — 动摇过，但没断过

关于「项目是否还活着」，最难操纵的指标是发布节奏。我从 GitHub Releases 直接扒下了 v2.0 GA 以来每一个次要版本的日期和间隔(同样的日期由 endoflife.date 独立佐证)。

版本发布日期与上一个次要版本的间隔
v2.0.02023-07-05— (GA)
v2.1.02023-08-2450 天
v2.2.02023-12-12110 天
v2.3.02024-05-13153 天 ← 关停区间
v2.4.02024-09-30140 天
v2.5.02025-02-20143 天
v2.6.02025-05-2998 天
v2.7.02025-09-30124 天
v2.8.02026-02-24147 天
v2.9.02026-06-30126 天

能读出来的是：

  • 最长的空档(153 天)恰好就是贯穿关停的那一段。 在 v2.2.0(2023 年 12 月)和 v2.3.0(2024 年 5 月)之间 — 正是维护者们失去雇主、四处另寻新窝的那段时间。
  • 不过就算是这个最糟的区间，也只比第二长的间隔(2.7→2.8 的 147 天)多了区区 6 天。与其说是崩塌，不如说是「延后了一个周期」的程度。
  • 按年看：2023 年 3 个(2.0、2.1、2.2)，2024 年 2 个(2.3、2.4)，2025 年 3 个(2.5、2.6、2.7)，2026 年光上半年就 2 个(2.8、2.9)。Flux 的官方发布政策标榜「至少与 Kubernetes 同速(每年 3 个次要版本)」，而只有发生关停的 2024 年没达到这个目标，从 2025 年起就恢复了。

光看数字，这更接近「几乎都没怎么动摇」，而不是「活下来了」。但你得看看这层光滑表面底下的结构。

现在的 Flux 是谁在做 — 读一读 CORE-MAINTAINERS 文件

Flux 项目的 CORE-MAINTAINERS 文件(以 2026 年 7 月现状为准)上列着 9 个人。按所属数一数：

  • ControlPlane 3 人 — Stefan Prodan、Matheus Pimenta、Leigh Capili
  • SUSE 1 人 — Paulo Gomes
  • NexHealth 1 人 — Aurel Canciu
  • Associmates 1 人 — Max Jonas Werner
  • 无所属(Independent) 3 人 — Hidde Beydals、Sanskar Jaiswal、Soule BA

有两点很显眼。

第一，纸面上是多元化的，但活动量并非如此。 打开 v2.9.0 的变更日志扫一眼 PR 列表就会发现，功能开发的相当一部分出自 Stefan Prodan 和 Matheus Pimenta 之手 — 两人都属于 ControlPlane。CLI 插件系统(RFC-0013)的提案和实现都是 Prodan。文件上写的 9 个人，和真正拉着路线图往前走的人数，是两回事。

第二，雇佣关系一直在动。 2024 年 2 月被宣布与 Prodan 一同受雇于 ControlPlane 的 Soule Ba，到 2026 年 7 月，在文件上标注为无所属。「某公司雇了维护者」这条新闻只是一张快照，两年后那套结构还在不在并无保证 — 这份文件把这一点原原本本地摆了出来。

钱从哪里来 — 开放核心模式及其分界线

社区从 Weaveworks 的失败里得到的教训是「光靠善意养不起全职维护者」。如今 Flux 的资金结构，大致可以这样概括。

上游仍留作 CNCF 项目，而商业发行版来付维护者的工资。 ControlPlane 以 Enterprise for Flux CD 之名，成了一家卖 FIPS 合规构建、旧版本兼容、24/7 支持的公司，并用这笔营收雇用维护者。这条分界线在官方发布说明里也明确出现过 — v2.9.0 的发布说明写着，Flux 项目只支持最新的 3 个 Kubernetes 次要版本，而更老的 Kubernetes 和 OpenShift 的向下兼容，由 ControlPlane 这类厂商提供。

最好把这条线的位置具体地确认下来。 上游(免费)这一侧是：

  • CLI 和控制器的最近 3 个次要版本支持 — 但把文档的原话照搬过来的话，回移(backport)是「由社区以尽力而为的方式(best-effort basis)提供」。这不是 SLA。
  • 与最新 3 个 Kubernetes 次要版本兼容(以 v2.9 为准是 1.34/1.35/1.36)。

商业(付费)这一侧是：

  • 旧版本 Kubernetes/OpenShift 的兼容构建、FIPS、支持合同。
  • Flux Operator — 一个管理 Flux 安装与生命周期、并提供 Web UI 的 operator。它不属于 CNCF Flux 项目，而是放在 ControlPlane 的 GitHub 组织(controlplaneio-fluxcd)下的 AGPL-3.0 项目，在企业发行版里则以商业许可打包发出。

这不是要批评这个结构 — 比起 Weaveworks 的路子(拿 VC 的钱补贴免费开发)，它看上去更诚实也更可持续。只是采用者得知道，你嘴里那个「Flux」里面，混着受 CNCF 治理的那一部分和属于某一家公司的产品的那一部分，并据此划出线来。一旦因为需要 UI 而开始倚靠 Flux Operator，那一部分押的就不是 CNCF，而是 ControlPlane 的持续性。

Flux 2.9 里实际装了什么

先从治理的话题挪开 — 发布本身也值得一看。以 v2.9.0 发布说明和官方博客为准的主要条目：

  • CLI 插件系统 — 以 RFC-0013 提出的 kubectl/krew 风格扩展。把一个 flux-<name> 可执行文件放进插件目录，它就成了 flux <name> 子命令。从托管在 GitHub 上的中央目录用 flux plugin install 安装，并校验 SHA-256 校验和。首批插件是 Mirror(chart、OCI 制品、镜像仓库的镜像同步)和 Schema(基于 JSON Schema 与 CEL 规则的清单校验)。要注意的是，正如 RFC 文档自己所言，v1beta1 里只有校验和验证，没有 Cosign/SLSA 签名验证。 而且 Operator 插件由 ControlPlane 而非 Flux 项目维护 — 等于说上面讲的那条分界线，已经伸进 CLI 里面了。
  • Server-Side Apply 的字段忽略规则 — 可以在 Kustomization 里把特定的受管字段排除在漂移检测之外。对于 HPA 会动的 replicas 这类字段导致漂移永远报个不停的经典痛点，这是官方解法。
  • SOPS 的 Age 后量子加密支持 — 密钥解密路径上加进了抗量子加密选项。
  • OpenBao/Vault 的 Workload Identity 认证、基于 SSH 密钥的 Git 提交签名与验证、无需密钥的 OIDC webhook Receiver — 这三项都是「减少长期留存的密钥」这同一个方向上的变化。
  • Helm 的后渲染策略与 chart hook 支持，以及相当于 helm --set-literal 的字面值模式。
  • API 移除 — image.toolkit.fluxcd.io/v1beta2 和 notification.toolkit.fluxcd.io/v1beta2 已从 CRD 中移除。如果你还在用这些旧版本 API，升级前需要先迁移。

从功能清单里读出的项目方向很清楚 — 比起向新领域扩张，这是一个补齐安全链条(签名、基于身份的认证、去掉密钥)和运维边缘情况(漂移、hook、monorepo)的成熟期版本。作为赞助商崩塌两年后的一个版本，这个样子是健康的。

诚实的风险评估 — 还剩下什么

活下来这个事实，并不意味着风险消失了。站在 2026 年 7 月这个时点，我看到的残余风险：

单一企业集中正换个形态重演。 Weaveworks 时代的问题是「维护者大多属于同一家公司」。如今 9 位核心维护者里属于 ControlPlane 的是 3 人，但提交与 RFC 的重心就压在这 3 人那边。要是 ControlPlane 的企业业务动摇，我们可能会再看一遍同一部电影。要说差别的话 — 这一次 Microsoft 和 GitLab 都把 Flux 当作自家产品的零件在用，所以就算最坏的情况，接住它的手也更多。

「社区 best-effort」不是 SLA。 3 个次要版本的支持与回移政策，在文档里被明确写成是尽力而为的。在受监管的行业里如果需要补丁保证，最后还是会走向商业合同，而这份合同的对手方实际上只有一家。

生态的偏重也依然如故。 同一时期 Argo CD 发布了 3.3.0(2026-02-02)、3.4.0(2026-05-05)，维持着由多家厂商分担的开发体制。从工具选型角度的对比，ArgoCD vs FluxCD 对比文章里已经讲过，这里就不重复了，只点一句：在「维护者雇佣结构」这条轴上，两个项目现在的形状相当不同。

UI、生命周期管理这类便利层，在 CNCF 之外。 纯粹的上游 Flux 依旧是 CLI 加控制器的一捆东西，需要仪表盘就得去找 ControlPlane 的 Flux Operator(AGPL + 商业许可)或者第三方。比起还有 Weave GitOps 这个免费 UI 的年代，这部分反倒是倒退了。

站在采用者的角度 — 该确认什么、决定什么

把这个案例里能拿到的实务检查清单整理一下：

  1. 确认你所依赖的开源项目的维护者雇佣结构。 在 MAINTAINERS 文件里写明所属的项目，比你想的要多。比起「是不是 CNCF 毕业项目」，「全职贡献者的工资从哪儿出」是更敏感的先行指标。Flux 活下来，一半靠 CNCF 治理，一半靠大厂产品早就把它当零件在用。
  2. 把上游的支持窗口体现在运维计划里。 Flux 只支持最近 3 个次要版本，而每年出 2 到 3 个次要版本。意思是大约一年上下就会被挤出支持窗口。随着 v2.9 发布，v2.6 已经 EOL。这与「装完就忘」的运维方式并不相容。
  3. 把处在免费/付费分界线上的组件区分开来。 在架构文档里把 CNCF Flux(CLI + 控制器)和 ControlPlane 的产品(Flux Operator、旧版本兼容构建)涂成不同颜色，日后的厂商谈判或风险评估会干净得多。
  4. 如果你已经把 Flux 用得挺好，那就没有换掉它的理由。 节奏恢复得让 2024 年的恐慌显得多余，而 2.9 是个有货的版本。「Weaveworks 倒了，所以 Flux 有风险」这个判断，和 2026 年当下的数据对不上。

结语

对 2024 年 1 月那句「这个项目的未来有危险吗?」，2026 年 7 月的回答可以这样整理 — 项目并没有危险。只是它的生还不是白来的，而是在开放核心的商业模式和大厂们的产品依赖这两根柱子上重新盖起来的。

正如发布间隔的数据所示，Flux 在最糟的区间也只是以延后一个周期的程度撑住了，现在则恢复了政策上的节奏。与此同时，正如 CORE-MAINTAINERS 文件和发布说明的字里行间所示，维护动力的重心依旧偏向一家公司。开源基础设施的可持续性就是这样 — 既不是戏剧性的死亡宣告，也不是圆满的大团圆 — 而是作为结构与金钱的问题被持续管理着。采用与否的判断，也用这双眼睛来看就好。

参考资料

Discuss on Twitter • View on GitHub