ArgoCD 多环境镜像升级：基于 GitOps 的安全 Promotion 实践

1. 项目概述为什么一张图在开发、测试、生产环境里总“长”得不一样ArgoCD 这个词现在几乎成了 Kubernetes 生产环境的标配工具但真正把它用稳、用透、用出效率的团队其实不多。我见过太多团队——开发在本地改完一个镜像 tag提 PR 后 CI 推送新镜像到仓库然后等着 ArgoCD 自动同步结果一刷新 UI发现 dev 环境更新了staging 环境卡在旧版本不动prod 环境压根没反应。更糟的是某天凌晨告警响了排查两小时才发现staging 部署的镜像是v2.3.1-rc.2而 prod 实际运行的是v2.3.1两者差了一个关键的数据库迁移补丁——但它们的 Helm values 文件里镜像字段明明都写着{{ .Values.image.tag }}看起来完全一致。这就是典型的“Image Promotion Challenge”同一张容器镜像在多环境dev/staging/prod中无法被安全、可追溯、可验证地逐级提升promote。它不是 ArgoCD 的 Bug而是对 GitOps 模式下“声明即事实”这一原则的深度考验。Promotion 不是简单地把 tag 从dev改成staging它背后是一整套环境治理逻辑谁有权限触发是否通过了自动化测试镜像是否经过签名和漏洞扫描变更是否已人工审批历史版本能否一键回滚这些需求ArgoCD 原生不提供但它的设计哲学——以 Git 为唯一事实源、以声明式配置驱动集群状态——恰恰为构建一套轻量、可靠、审计友好的 promotion 流程提供了最干净的土壤。这篇文章讲的就是我们团队过去一年在三个不同规模 Kubernetes 集群50 节点金融中台、200 节点电商 SaaS、8节点内部工具平台上如何仅用 ArgoCD 原生能力不引入 Flux、不写自定义 Operator、不依赖外部 CI/CD 引擎调度把 image promotion 从“手动改 YAML 提交”升级为“自动校验 人工确认 Git 原子提交 状态可溯”的工业级流程。核心关键词是ArgoCD ApplicationSet、Git Submodule、Semantic Versioning、Image Signature Verification、Promotion Gate、Environment-Specific Values Overlay。如果你正被“镜像版本混乱”、“上线前不敢信 Git 里写的到底是不是线上跑的”、“每次发布都要截图发钉钉确认”这些问题困扰这篇就是为你写的。它不讲概念只讲我们每天怎么操作、为什么这么选、踩过哪些坑、以及怎么让新人三天内就能独立完成一次跨环境 promotion。2. 整体架构设计为什么不用 CI 触发 ArgoCD而要用 Git 作为唯一调度器2.1 核心矛盾CI 是“推”GitOps 是“拉”强行混合会破坏一致性很多团队第一反应是“让 Jenkins/GitLab CI 在构建完镜像后调用 ArgoCD API 更新 Application 的 image 字段”。这看似直觉实则埋下三颗雷第一颗雷Git 与集群状态脱节CI 修改了 ArgoCD 的 Application CRD但没同步更新 Git 仓库里的 YAML。下次 ArgoCD 自动 sync默认3分钟一次它会发现“集群状态 ≠ Git 声明”于是把集群强行拉回旧版本——你看到的现象就是CI 显示部署成功但 ArgoCD UI 上 Application 状态立刻变红提示OutOfSync。这是 GitOps 最根本的反模式Git 必须是唯一事实源任何绕过 Git 的变更都是不可接受的。第二颗雷promotion 缺乏原子性与可追溯性CI 脚本里写kubectl patch application my-app -p {spec:{source:{helm:{valuesObject:{image:{tag:v2.4.0}}}}}}这条命令执行成功但你无法回答这个 patch 是谁在什么时间、基于什么理由、通过什么审批流程发起的Git 里没有 commit 记录ArgoCD audit log 只有 API 调用痕迹没有业务上下文。一旦出问题复盘成本极高。第三颗雷环境间依赖关系难以表达staging 环境 promotion 必须等 dev 环境稳定运行 24 小时且所有 E2E 测试通过。CI 脚本要自己去轮询 dev 环境的健康状态、解析测试报告、判断阈值——这本质上是在重复造一个轻量版的 ArgoCD Rollout且极易出错。我们最终选择的方案是彻底拥抱 ArgoCD 的“拉模型”本质所有 promotion 动作必须由一次 Git commit 触发所有环境状态必须能从 Git commit history 中完整还原。这意味着promotion 不是“CI 发起的一个动作”而是“开发者向 Git 仓库提交的一份环境升级声明”。2.2 我们的三层 Git 结构App Repo Env Repo Promotion Repo我们拆分了三个独立 Git 仓库各司其职物理隔离关注点App Repo应用源码库存放 Helm Chartchart/ 目录、Dockerfile、应用代码。Chart 的values.yaml中image.tag字段留空或设为占位符如PLACEHOLDER_TAG。这里不存任何环境相关配置只定义应用自身的结构。Env Repo环境配置库按环境划分目录environments/dev/,environments/staging/,environments/prod/。每个目录下是该环境专用的values.yaml覆盖镜像 tag、资源限制、密钥引用等以及 ArgoCD Application CRDapplication.yaml。关键点application.yaml的spec.source.path指向 App Repo 的 chart 目录spec.source.repoURL是 App Repo 地址spec.source.targetRevision固定为main或stable分支——环境配置库不管理应用代码版本只管理环境参数。Promotion Repo发布控制库这是整个流程的“大脑”。结构极简只有一个promotions/目录里面按时间戳命名的文件如2024-06-15-v2.4.0.yaml。每个文件是一个 Promotion CRDCustom Resource Definition内容如下apiVersion: argoproj.io/v1alpha1 kind: Promotion metadata: name: v2.4.0 spec: image: repository: registry.example.com/myapp tag: v2.4.0 digest: sha256:abc123... # 镜像 SHA256 digest非 tag fromEnvironment: dev toEnvironments: [staging, prod] approvedBy: [ops-team, security-review] requiredTests: [e2e-smoke, security-scan-passed]这个 CRD 本身不是 Kubernetes 原生资源而是我们用 ArgoCD 的ApplicationSet和Generators机制在 Env Repo 中动态生成 Application 的“输入数据”。Promotion Repo 是唯一的、人工可读可审的发布决策记录。2.3 关键设计用 ApplicationSet 替代硬编码 ApplicationArgoCD 原生 Application 是静态的一个 Application 对应一个固定的 Git 路径。但 promotion 要求“同一个应用在不同环境使用不同镜像 tag”如果为每个环境写死一个 Application那每次 promotion 都要手动修改 N 个文件违背自动化初衷。我们采用ApplicationSet的GitFileGenerator让 ArgoCD 主动扫描 Promotion Repo 中的.yaml文件并为每个Promotion资源生成一组 Application# 在 Env Repo 的 root 目录下applicationset.yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: myapp-promotions spec: generators: - gitFile: repoURL: https://git.example.com/promotion-repo.git files: - path: promotions/*.yaml template: metadata: name: myapp-{{.promotion.spec.fromEnvironment}}-to-{{.promotion.spec.toEnvironments}} spec: project: default source: repoURL: https://git.example.com/app-repo.git targetRevision: main path: chart/ helm: valueFiles: - environments/{{.promotion.spec.fromEnvironment}}/values.yaml # 注意这里用 fromEnvironment因为 values.yaml 是环境专属的 destination: server: https://kubernetes.default.svc namespace: myapp-{{.promotion.spec.fromEnvironment}} syncPolicy: automated: prune: true selfHeal: true提示GitFileGenerator会将每个匹配的 YAML 文件解析为一个{{.}}对象其中{{.promotion}}是文件内容反序列化后的结构。这样一个2024-06-15-v2.4.0.yaml文件就能驱动 ArgoCD 为dev、staging、prod三个环境分别创建 Application且每个 Application 的helm.valuesObject.image.tag都被注入为v2.4.0。这个设计的精妙之处在于Promotion Repo 是“发布意图”Env Repo 是“环境定义”App Repo 是“应用结构”三者解耦各自演进互不影响。运维改环境参数只动 Env Repo开发升级应用功能只动 App Repo发布经理决定上线只往 Promotion Repo 提交一个 YAML——职责清晰权限可控审计日志天然完整。3. 核心细节解析镜像签名、语义化版本、环境门禁一个都不能少3.1 镜像签名验证为什么tag是危险的digest才是真相Dockertag是可变的。registry.example.com/myapp:v2.4.0今天指向sha256:abc123明天可能被docker push --force覆盖为sha256:def456。如果 promotion 流程只认 tag就等于把信任建立在随时可能被篡改的字符串上。我们的解决方案是所有 promotion 必须指定镜像的完整 SHA256 digest并在 ArgoCD sync 前强制校验。实现分三步构建阶段生成并推送签名CI 构建完镜像后用cosign签名cosign sign --key cosign.key registry.example.com/myappsha256:abc123...签名存储在 OCI registry 的同一路径下可通过cosign verify --key cosign.pub registry.example.com/myappsha256:abc123...验证。Promotion Repo 中的 CRD 必须包含 digest如前文所示Promotion.spec.image.digest是必填字段。我们用 Git pre-commit hook 强制校验提交promotions/*.yaml时脚本自动调用cosign verify若失败则拒绝提交。ArgoCD sync 前注入 digest 校验逻辑我们不修改 ArgoCD 源码而是利用其plugin机制。在 Env Repo 的environments/*/目录下放置一个verify-image.sh脚本#!/bin/sh # 从 Helm values 中提取 image.repository 和 image.digest REPO$(yq e .image.repository /tmp/values.yaml) DIGEST$(yq e .image.digest /tmp/values.yaml) # 调用 cosign verify if ! cosign verify --key /etc/cosign/pubkey.pub $REPO$DIGEST; then echo Image signature verification failed for $REPO$DIGEST exit 1 fi然后在application.yaml的spec.syncPolicy.syncOptions中启用Validate: true并配置pluginplugin: name: image-verifier env: - name: VALUES_FILE value: /tmp/values.yaml注意cosign verify成功只证明镜像未被篡改且由可信密钥签名不保证无漏洞。我们额外要求requiredTests中的security-scan-passed由 CI 在构建时调用 Trivy 扫描结果存入 Promotion CRD 的 annotationArgoCD plugin 会读取并校验。3.2 语义化版本SemVer驱动的 promotion 门禁v2.4.0和v2.4.0-rc.1看似相似但对 production 环境意义天壤之别。我们用 SemVer 规则定义 promotion 门禁dev → staging允许prerelease版本如v2.4.0-rc.1,v2.4.0-beta.2staging → prod仅允许stable版本无-后缀如v2.4.0,v2.5.0prod → prod热修复允许patch级别更新v2.4.1,v2.4.2但禁止minor或majorv2.5.0,v3.0.0这个规则不是写在文档里而是嵌入PromotionCRD 的 validation webhook。我们用 Kyverno 编写策略apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: promotion-semver-check spec: validationFailureAction: enforce rules: - name: check-prod-promotion match: resources: kinds: - Promotion selector: matchLabels: toEnvironments: prod validate: message: Production promotion only allows stable SemVer (no prerelease suffix) pattern: spec: image: tag: !*-* # 不匹配含 - 的字符串同时在 CI 构建脚本中我们用semverCLI 工具校验 tag 合法性# 构建前检查 if ! semver valid $IMAGE_TAG; then echo Invalid SemVer: $IMAGE_TAG exit 1 fi # 若目标是 prod则进一步检查 if [[ $TARGET_ENV prod ]]; then if semver prerelease $IMAGE_TAG; then echo Prerelease tag not allowed for prod: $IMAGE_TAG exit 1 fi fi3.3 环境门禁Promotion Gate让机器做检查人只做决策Promotion 不是“一键上线”而是“机器检查通过 人工确认”。我们定义了两类门禁自动门禁Automated Gates由系统自动执行失败则阻断 promotione2e-smoke: 在 staging 环境部署后自动运行 10 个核心 API 的 smoke test成功率需 ≥99%security-scan-passed: Trivy 扫描结果中CRITICAL漏洞数 0HIGH漏洞数 ≤ 3resource-stability: 新版本 pod 在 staging 运行 15 分钟后CPU/Memory 使用率波动 10%无 CrashLoopBackOff人工门禁Manual Gates需指定角色在 Promotion CRD 上添加 approval annotationmetadata: annotations: gate.ops-team/approved: 2024-06-15T14:22:00Z gate.security-review/approved: 2024-06-15T14:25:00ZArgoCD 的ApplicationSet本身不支持 gate但我们用一个轻量级 controller约 200 行 Go 代码监听 Promotion CRD 的变化。当检测到新 Promotion 提交它克隆 Env Repo生成 staging 环境的临时 Application带--dry-run参数调用 ArgoCD API 创建该 Application并等待其status.sync.status变为Synced触发自动门禁检查调用测试服务 API、查询 Prometheus 指标、解析 Trivy 报告若全部通过controller 自动给 Promotion CRD 添加gate.automatic/passed: trueannotation此时Promotion CRD 的status.phase变为ReadyForApprovalSlack 机器人推送消息“Promotion v2.4.0 已通过自动门禁请 ops-team 审批”实操心得人工审批环节我们强制要求审批人点击 Slack 消息中的按钮而非手动编辑 YAML按钮背后是调用 controller 的/approve接口该接口会校验审批人是否在approvedBy列表中并自动添加 timestamped annotation。这避免了手误、确保了审计追踪且比 GitHub PR review 更快——因为审批人不需要 checkout 代码、不需要理解 YAML 结构只需看一眼 Slack 消息里的版本号和测试摘要。4. 实操过程详解从提交 Promotion 到 prod 环境生效每一步都在做什么4.1 第一步开发者提交 Promotion CRDGit 操作假设开发完成v2.4.0版本CI 已构建并推送镜像registry.example.com/myappsha256:abc123...且cosign签名成功。开发者在本地执行# 1. 进入 Promotion Repo cd ~/git/promotion-repo # 2. 创建新 promotion 文件模板已预置 cp templates/promotion.yaml promotions/2024-06-15-v2.4.0.yaml # 3. 编辑文件填入必要信息 vim promotions/2024-06-15-v2.4.0.yaml # 内容如下关键字段已填充 apiVersion: argoproj.io/v1alpha1 kind: Promotion metadata: name: v2.4.0 spec: image: repository: registry.example.com/myapp tag: v2.4.0 digest: sha256:abc123def456... # 从 CI 日志复制 fromEnvironment: dev toEnvironments: [staging, prod] approvedBy: [ops-team, security-review] requiredTests: [e2e-smoke, security-scan-passed]注意fromEnvironment: dev并非表示从 dev 环境“复制”配置而是指本次 promotion 的基准环境是 dev即 dev 环境已稳定运行此镜像 24 小时。toEnvironments是目标环境列表。保存后执行 Git 提交git add promotions/2024-06-15-v2.4.0.yaml git commit -m chore(promotion): promote myapp v2.4.0 to staging and prod git push origin main此时发生了什么Git hook 触发cosign verify校验sha256:abc123...签名有效提交成功。Promotion Repo 的 webhook 通知我们的 Promotion Controller。Controller 检测到新文件解析为 Promotion CRD初始化status.phase: Pending。4.2 第二步Controller 启动自动门禁检查约 8 分钟Controller 开始执行以下流水线步骤操作耗时输出1. 生成 staging Application克隆 Env Repo渲染environments/staging/application.yaml注入image.digest30s临时 Application 名myapp-staging-v2.4.0-temp2. 部署 staging调用 ArgoCD API 创建 Application等待status.sync.status Synced2minPod RunningService 可访问3. 运行 smoke test调用内部测试服务 API发送 10 个请求收集响应时间、状态码1.5min成功率 100%P95 延迟 120ms4. 查询稳定性指标查询 Prometheus检查过去 15 分钟 CPU 使用率标准差30s标准差 2.3% 10% 门限5. 解析安全扫描报告从 S3 下载 Trivy 报告 JSON提取Critical和High数量20sCritical0, High1所有检查通过后Controller 更新 Promotion CRDstatus: phase: ReadyForApproval automaticGates: e2e-smoke: {passed: true, timestamp: 2024-06-15T14:20:00Z} security-scan-passed: {passed: true, timestamp: 2024-06-15T14:20:20Z}Slack 机器人收到事件推送消息[Promotion v2.4.0] Ready for manual approval! - Environment: staging → prod - Image: registry.example.com/myappsha256:abc123... - Auto-gates passed: ✅ e2e-smoke, ✅ security-scan-passed - Approve now: [APPROVE OPS] [APPROVE SECURITY]4.3 第三步人工审批与 prod 部署2 分钟内完成Ops Team 成员点击[APPROVE OPS]按钮Slack App 调用 Controller 的/approve接口传入{ promotionName: v2.4.0, approver: ops-team, role: ops-team }Controller 校验promotion.spec.approvedBy包含ops-team✔️当前status.phase是ReadyForApproval✔️未被同一角色重复审批 ✔️校验通过Controller 添加 annotationmetadata: annotations: gate.ops-team/approved: 2024-06-15T14:22:00Z同理Security Reviewer 点击[APPROVE SECURITY]添加gate.security-review/approved: 2024-06-15T14:25:00Z当所有approvedBy列表中的角色都完成审批Controller 检测到条件满足执行最终动作生成 prod Application克隆 Env Repo渲染environments/prod/application.yaml注入相同image.digest提交 GitController 以 bot 用户身份向 Env Repo 的main分支提交一个 commit内容是更新后的environments/prod/application.yaml# environments/prod/application.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-prod spec: source: helm: valuesObject: image: repository: registry.example.com/myapp tag: v2.4.0 digest: sha256:abc123def456... # 与 staging 完全一致触发 ArgoCD syncEnv Repo 的 webhook 通知 ArgoCD它检测到environments/prod/application.yaml变更开始 sync。此时prod 环境的 Application 状态会经历OutOfSync→Syncing→Synced约 90 秒ArgoCD UI 上myapp-prod的SYNC STATUS变绿HEALTH STATUS变为HealthyREVISION显示为sha256:abc123...。4.4 第四步验证与归档1 分钟部署完成后Controller 自动执行更新 Promotion CRDstatus.phase: Completed将本次 promotion 的所有关键日志staging 测试结果、prod sync 时间、审批人列表存入内部审计数据库向企业微信发送终态通知✅ Promotion v2.4.0 completed at 2024-06-15 14:27:33 - Staging deployed: 14:20:00 - Prod deployed: 14:27:33 - Approved by: ops-team (14:22), security-review (14:25) - Full audit log: https://audit.example.com/promotion/v2.4.0实操心得我们刻意让 prod 部署延迟在 staging 之后至少 15 分钟这是为了给人工审批留出缓冲。即使审批人正在开会staging 已经稳定运行prod 部署也不会自动发生。这个“延迟窗口”是我们用 GitOps 实现“安全自动化”的关键设计——机器永远不替人做高风险决策只做可逆、可验证的执行。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 问题Promotion CRD 提交后ApplicationSet 没有生成任何 Application现象Promotion Repo 提交了2024-06-15-v2.4.0.yaml但 ArgoCD UI 中看不到myapp-staging-v2.4.0-temp这样的临时 Application。排查步骤检查 ApplicationSet 状态kubectl get appset myapp-promotions -n argocd -o wide看STATUS是否为Generated。如果不是说明GitFileGenerator扫描失败。检查 ArgoCD 日志kubectl logs -n argocd deploy/argocd-applicationset-controller | grep myapp-promotions常见错误是failed to list files in repo: repository not found意味着 ApplicationSet 的spec.generators.gitFile.repoURL指向的 Promotion Repo 地址错误或 ArgoCD 没有该仓库的 read 权限。手动触发扫描kubectl patch appset myapp-promotions -n argocd -p {spec:{generators:[{gitFile:{repoURL:https://git.example.com/promotion-repo.git,files:[promotions/*.yaml]}}]}} --typemerge强制刷新 generator。根本原因与解决我们曾遇到过因 Promotion Repo 启用了私有 Git 仓库的 SSH key 认证但 ApplicationSet 的repoURL写的是 HTTPS 地址https://git.example.com/...导致 ArgoCD 无法 clone。正确做法是统一使用 HTTPS Personal Access Token并将 token 存入 ArgoCD 的RepositoryCRD 中apiVersion: argoproj.io/v1alpha1 kind: Repository metadata: name: promotion-repo spec: type: git name: promotion-repo url: https://tokengit.example.com/promotion-repo.git然后在 ApplicationSet 中引用该 Repository 名称而非直接写 URL。5.2 问题staging 环境部署成功但 smoke test 总是失败报 “connection refused”现象ApplicationSet 生成的myapp-staging-v2.4.0-tempApplication 状态是Synced但 Controller 的 smoke test 日志显示curl: (7) Failed to connect to myapp-staging port 80: Connection refused。排查步骤确认 Service 是否就绪kubectl get svc -n myapp-staging检查myapp-stagingService 的CLUSTER-IP是否非none。如果是none说明 Helm chart 的service.type被错误设为ClusterIP但测试脚本尝试从集群外访问。检查 Ingress 配置kubectl get ingress -n myapp-staging确认host字段是否匹配测试脚本中硬编码的域名如myapp-staging.example.com。我们曾因忘记在environments/staging/values.yaml中覆盖ingress.hosts[0].host导致 Ingress 未创建。验证网络策略kubectl get networkpolicy -n myapp-staging确认没有deny-all策略阻止测试服务的 Pod 访问 staging 命名空间。根本原因与解决这个问题的根源在于Helm values 的继承链混乱。我们的environments/staging/values.yaml继承自environments/base/values.yaml而base中ingress.enabled默认为false。开发在 staging 的 values 中只写了ingress.hosts: [...]忘了打开ingress.enabled: true。教训所有 boolean 类型的开关必须显式声明不能依赖默认值。我们在 CI 的 lint 阶段加入了helm lint --strict并自定义 rule若ingress.hosts非空则ingress.enabled必须为true。5.3 问题prod 环境部署后Application 状态是Synced但实际 pod 仍是旧版本现象kubectl get pods -n myapp-prod显示 pod 的 image 是v2.3.1而argocd app get myapp-prod显示REVISION是sha256:abc123...。排查步骤检查 pod 的 actual imagekubectl get pod pod-name -n myapp-prod -o jsonpath{.spec.containers[0].image}确认是否真的是旧镜像。检查 Deployment 的 image 字段kubectl get deploy myapp-prod -n myapp-prod -o jsonpath{.spec.template.spec.containers[0].image}如果这里还是旧值说明 Helm 渲染没生效。检查 Helm values 注入kubectl get app myapp-prod -n argocd -o jsonpath{.spec.source.helm.valuesObject}确认image.digest字段存在且正确。根本原因与解决这是 Helm 的经典陷阱——Deployment 的imagePullPolicy被设为IfNotPresent。当集群节点上已有v2.3.1镜像Kubernetes 就不会去 registry 拉取sha256:abc123...即使 manifest 里写了。永久解决方案在 Helm chart 的deployment.yaml中强制设置imagePullPolicy: Always。我们还加了一层保险在environments/prod/values.yaml中覆盖global.imagePullPolicy: Always确保所有容器都遵守。5.4 问题Promotion Controller 报错 “failed to update promotion status: Operation cannot be fulfilled on promotions.argoproj.io ... the object has been modified”现象Controller 日志频繁出现 optimistic lock conflict 错误导致 promotion 卡在Pending状态。原因分析多个 Controller 实例如做了 HA 部署同时监听同一个 Promotion CRD都试图更新其status字段。Kubernetes 的 etcd 要求 update 操作必须基于最新resourceVersion否则报错。解决方法我们放弃多实例改为单实例部署并添加 leader electionmgr, err : ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{ Scheme: scheme, MetricsBindAddress: metricsAddr, Port: 9443, LeaderElection: enableLeaderElection, LeaderElectionID: promotion-controller-leader-election-helper, })同时在 RBAC 中授予coordination.k8s.io/v1的leases权限。这样即使部署多个副本也只有一个实例能获得 leader lease其他副本进入 standby 状态彻底避免并发冲突。5.5 问题安全扫描通过但 prod 上线后发现有 0day 漏洞现象Trivy 扫描报告显示HIGH漏洞数为 1低于门禁阈值 3但上线后 CVE 数据库新增了该组件的CRITICAL漏洞。反思与改进这暴露了静态扫描的局限性。我们的应对策略是双引擎扫描除了 TrivyCI 中并行运行grypeAnchore两个引擎结果取并集提高检出率。CVE 实时订阅用开源工具cve-bin-tool每日扫描所有已上线镜像发现新 CVE 立即触发紧急 promotion跳过 staging直接 hotfix prod。镜像生命周期管理在 Promotion CRD 中增加expiresAt字段所有镜像默认 90 天过期过期前 7 天自动邮件提醒维护者升级。最后分享一个小技巧我们把PromotionCRD 的status.phase字段通过 ArgoCD 的Resource Customization功能映射到 UI 的 Application health status。这样在 ArgoCD UI 的 Applications 列表页你能直接看到myapp-prod的 Health 列显示为Progressing (v2.4.0)或Healthy (v2.4.0)而不是笼统的Healthy。这个小改动让整个团队对当前 promotion 状态一目了然再也不用翻 Git 历史查版本。