一、云原生流水线关注可追溯

云原生 CI/CD 不只是把代码打成镜像再部署到 Kubernetes。它要保证从提交、构建、测试、扫描、制品、部署到回滚都有记录。每个线上版本都应该能回答：来自哪个 commit，经过哪些检查，使用哪个镜像，谁批准，部署到哪个环境。

制品标签建议使用 commit sha 或构建号，不要用 latest。不可追溯的镜像会让事故定位变慢。

二、流水线的基础结构

典型流程是 PR 阶段跑单测和静态检查，合并主分支后构建镜像并推送仓库，再更新部署仓库中的 Kubernetes manifests 或 Helm values。

name: ci
on:
  push:
    branches: [main]

jobs:
  image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t registry.example.com/api:${{ github.sha }} .
      - run: docker push registry.example.com/api:${{ github.sha }}

生产环境还应加入依赖缓存、镜像扫描、SBOM、签名和环境审批。流水线中的密钥要放在平台 secrets 或专用密钥系统，权限按仓库和环境拆分。

三、GitOps如何工作

GitOps 的核心是把部署期望状态放在 Git 中，由控制器持续对比 Git 与集群实际状态，并自动收敛。常见工具包括 Argo CD 和 Flux。应用仓库负责产出镜像，部署仓库负责声明环境版本。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
spec:
  template:
    spec:
      containers:
        - name: order-api
          image: registry.example.com/api:8f3a9c1

升级版本时提交一笔变更，把镜像 tag 从旧 sha 改成新 sha。所有发布都变成 Git 记录，回滚就是回退部署仓库提交。这样比手工 kubectl set image 更容易审计和复现。

四、灰度、回滚与治理

GitOps 不等于自动把所有变更直接推到生产。高风险环境仍然需要审批、灰度和指标观察。可以使用 Argo Rollouts、Ingress 权重或服务网格做渐进式发布。

kubectl rollout status deploy/order-api -n prod
kubectl rollout undo deploy/order-api -n prod

实践建议：应用配置与密钥分离，环境差异通过 values 或 kustomize 管理；发布前做冒烟测试，发布后观察错误率、延迟和资源使用；回滚流程定期演练。云原生 CI/CD 的成熟标志不是工具多，而是变更小、验证快、发布可审计、失败能快速回到已知稳定状态。

组织层面还要明确职责边界。应用团队负责代码质量、镜像和运行配置，平台团队负责集群、基础流水线模板和准入策略。策略可以通过代码扫描、镜像签名、部署审批和集群准入控制落地，但规则必须透明，不能只靠人工口头提醒。GitOps 把期望状态放进 Git，也把变更责任放进审查流程。持续交付的核心，是让每一次变更都小到可理解、快到可验证、失败时可恢复。

度量同样重要。可以跟踪部署频率、变更前置时间、失败率和恢复时间，用数据判断流水线是否真的改善交付，而不是只增加步骤。

📌 本文是《工程化交付实战》系列，持续更新，关注不迷路。
👉 下一篇：《灰度发布出问题，如何在5分钟内回滚止血》，讲指标异常时如何快速切流并恢复到稳定版本。
💬 你在实际项目里遇到过 GitOps 状态已同步但线上指标持续恶化的问题吗？评论区聊聊。
（觉得有用点个赞+收藏，方便回头查阅）
🔧 相关可运行源码/资料已整理成资源包，可在我主页的资源里自取。
☁️ 本文示例需要一台云服务器，新用户可通过此链接领取优惠自用：https://cloud.tencent.com/act/cps/redirect?redirect=2446&cps_key=49a769c067bd9c9f53fcb1bdf9feaf23&from=console&cps_promotion_id=102832