一个按钮发版到生产：Kargo 如何把零散部署变成「水果沙拉」式交付

作者提米哥
👉 工具网址：https://kargo.dev

你好，我是提米哥，提米大门（TMDM.cn）的首席选品官，专盯开发者真正用得上的硬核工具。今天不聊概念、不画大饼——直接上实战：怎么让一个后端服务、一个 Lambda 函数、一个前端页面，用同一套逻辑、同一个界面、一键推到生产环境？

答案不是写更多 YAML，也不是堆更多 CI 脚本，而是——用 Kargo 把部署这件事“拎出来”，单独做成一个聪明的物流系统。

🧩 以前为啥总卡在“发版”这一步？

想象一下：你改完代码，CI 流水线跑完测试 → 接着它还要自己去连 dev 环境、改 Helm 值、触发 Lambda 更新、再切前端 CDN……
→ 一旦 staging 环境网络抖了一下，整个流水线重跑 15 分钟，就为等一个 curl 成功？
→ 某个团队用 Terraform，另一个用 CDK，第三个手写 GitHub Actions —— 你查日志要开 4 个窗口？

这就是典型的「CI 和 CD 混在一起」的痛苦：建工厂（CI）和送快递（CD）雇了同一个人，他得先造车、再开车、再卸货、再签收……还不能请假。

✅ Kargo 的解法：只干一件事——当好「物流调度员」

它不碰你的代码，也不管你怎么构建。它只认一个东西：一个带版本号的、可验证的「货物」（Artifact）。
– 这个“货物”可以是 Docker 镜像（标准容器）
– 也可以是一个“空瓶子”（OCI marker），里面没代码，但贴了张小纸条（OCI annotation），写着：“真正的 JS 包在 S3://xxx”，“Helm Chart 在 charts.payfit.internal/v2.1.0”
– Kargo 就盯着镜像仓库（比如 ECR），一看到新标签（如 v1.2.3），立刻拆纸条、找包裹、按规则发货

下面这段就是我们 nx-core 发布器推送“空瓶子”的真实命令（加了中文注释，新手也能看懂）： 

# 用 ORAS 工具，向 AWS ECR 推送一个「纯元数据」的 OCI Artifact
# 它不包含任何可执行代码，只用来告诉 Kargo：“这个版本该发什么”
oras push \
  --annotation "dev.payfit.io/artifact-type=frontend" \
  --annotation "dev.payfit.io/s3-bucket=payfit-frontend-prod" \
  --annotation "dev.payfit.io/s3-key=app-v1.2.3.tar.gz" \
  --annotation "dev.payfit.io/version=v1.2.3" \
  123456789.dkr.ecr.eu-west-1.amazonaws.com/payfit/frontend:v1.2.3 \
  /dev/null  # ← 注意：这里传的是空文件！真正的前端包存在 S3 里

💡 小知识：/dev/null 表示“啥都不装”，就像寄快递只贴单不装货——单子（annotation）才是关键。

Kargo 收到这个“空瓶子”后，自动解析所有 --annotation，然后调用对应流程：
– 是 frontend？→ 触发 GitHub Action 下载 S3 包 + 更新 CloudFront
– 是 Lambda？→ 调用 AWS CLI 更新函数代码 + 切别名
– 是 backend？→ 渲染 Helm Chart + kubectl apply

所有动作，都从同一个入口（Kargo Dashboard）发起，用同一套语义（Promote → Dev → Staging → Prod）。

🚦 生产环境不靠人盯，靠「自动安全网」

怕发错？Kargo 不止会“发”，还会“验”：
– 后端服务上线后，自动检查 Kubernetes Pod 是否 ready & liveness probe 通过
– 前端上线后，自动访问 https://app.payfit.com/version.json，确认返回的 "version": "v1.2.3"
– 关键服务更狠：接入 Datadog，实时扫错误率、延迟、异常日志——超标？自动 rollback，不等人发现

这就像给每次发版配了个「自动驾驶质检员」：不靠经验，靠数据；不靠截图，靠 API。

🌟 开发者真正爽在哪？两个“秒级反馈”功能

  1. PR 预览即开即用
    给 PR 打个 deploy-preview 标签 → 几秒后，Kargo 自动在 dev 环境起一个隔离实例 → 你拿到一个专属预览链接（如 pr-456.dev.payfit.com），连本地环境都不用启。

  2. Helm 修改一眼看清
    有人改了 values.yaml？Kargo 自动跑 helm diff，把即将生效的 Kubernetes manifest 变化，直接贴在 PR 评论区：
    “`diff

  3. replicas: 2
  4. replicas: 4
  5. env:
    • name: FEATURE_FLAG_NEW_UI
  7. value: “true”
    “`
    → 配置错没错？影响大不大？不用切 terminal，一眼就懂。

📈 结果说话：不是 PPT，是数字

  • 迁移完成后，Kargo 月均部署量 12,134 次，旧系统只剩 1,543 次
  • 公司 18 个研发团队，17 个主动要求接入（第 18 个在排队）
  • 开发者反馈最频繁的一句话：“现在发版，比刷新网页还快。”

🥗 最后说句实在话：沙拉里还有“籽”（pips）

我们不吹“完美平台”。现实是：
– 90+ 应用 5 个月内全量迁移，团队确实累脱一层皮
– Kargo + ORAS + Datadog + Nx + Helm 的组合，对新人仍有学习曲线
– “水果沙拉”还没完全打匀——有些团队还在用自己写的脚本兜底

但这不重要。重要的是：我们不再花时间帮人修 YAML 缩进，而是腾出手来建预览环境、写自动化巡检、搭 AI 发布护栏。
平台团队，终于从「救火队」变成了「加速器」。

直达网址：https://kargo.dev

作加

微信联系：timidamen

类似文章