ArgoCD 同步波次规划器

要解决的问题

ArgoCD 的 Application 里往往同时挂着几十甚至上百个资源：Namespace、CRD、ConfigMap、Secret、Deployment、Service、Ingress……而 Kubernetes 本身并不保证这些资源被创建的先后顺序。于是你会看到 Deployment 因为引用的 ConfigMap 还没落地而卡在 CreateContainerConfigError，或者 CRD 还没注册完就撞上 no matches for kind。

原生的解法是手工给每个资源打 argocd.argoproj.io/sync-wave 注解，再靠 argocd.argoproj.io/sync-options: SyncWaveWait=true 让高波次资源等待低波次就绪。这一套在小项目里还行，一旦应用规模上去，注解散落在各个 YAML 里，谁也说不清某个 Deployment 到底排在第几波、依赖它的资源是否在同一波里被提前拉起。

更大的问题是渐进式发布。当你用 Argo Rollouts 做灰度、蓝绿或金丝雀时，发布的前提是：清单本身是自洽的、目标集群里应用这些资源不会炸。如果在触发 Rollout 之前没有验证过，一次错误的模板渲染就可能把整个生产环境带进故障里。

核心能力

这个技能把上面这些杂事整理成了一条可执行的链路：

• 通过 ArgoCD REST API 读写 Application：直接操作同步波次，而不是在 YAML 里翻找注解。
• 通过 Kubernetes 自定义资源管理：把波次与钩子当作 K8s 层面的一等公民来处理。
• 钩子（hooks）一并管理：PreSync、PostSync 这类需要在同步阶段前后执行的任务，同样纳入波次框架。
• kubectl diff 预览变更：在真正触发发布之前，看清这次改动到底会改掉什么。
• Helm 模板渲染校验：先渲染出最终清单，确认模板变量、条件分支、依赖拼装结果符合预期，而不是等到 ArgoCD 同步时才发现渲染失败。
• Argo Rollouts 触发前的清单验证：渐进式部署的起点是一个可信的清单，而不是一次盲目的应用。

典型流程是：先把 Helm 模板渲染成清单，用 kubectl diff 对照当前集群状态确认没有意料之外的破坏性变更，再校验波次与钩子配置，最后才让 Argo Rollouts 接管发布。

适用边界与注意点

• 它解决的是顺序与预检问题，不是集群容量规划或回滚策略设计。波次设得再合理，也替代不了资源配额与 HPA 的评估。
• kubectl diff 的行为依赖集群版本和 CRD 实现，某些环境里 diff 会缺失或失真，不能把它当作唯一校验手段。
• Helm 模板渲染校验只证明渲染结果正确，不等同于资源在集群里一定能成功 apply；实际生效仍以 ArgoCD 同步结果为准。
• 波次调优需要结合资源的实际依赖关系。把有循环依赖的资源塞进同一个波次，只会让同步卡住而不是变快。
• 钩子任务本身也可能失败并阻断同步，建议给 PreSync 类任务加上幂等性和超时约束。

这类技能真正的价值在于把「先把清单和顺序搞对」变成流程的一部分，而不是发布前临时抱佛脚的一步。