flux cd并非实时漂移自愈控制器，其“自愈”本质是定期reconcile+prune+声明重放：开启prune:true后，每次同步自动删除git中已移除但集群残留的资源，配合validation校验与rbac锁死人工干预，才能实现漂移收敛。
FluxCD 本身不是“漂移自愈控制器”，它不主动扫描集群状态并回滚非声明式变更；它只按 Git 中的声明做单向同步。所谓“自愈”，本质是靠定期 reconcile + prune + 检测 drift 后触发重放声明，而非实时检测+修复。
为什么 Flux 的 prune: true 是漂移收敛的关键开关
默认情况下 Flux 不会删除 Git 中已移除的资源，集群里残留的旧 Deployment、ConfigMap 就成了漂移源。开启 prune: true 后，每次 reconcile 都会比对 Git 声明与集群实际资源，自动删掉 Git 里没有但集群里还存在的对象。
- 必须配合
validation: client或validation: server，否则 prune 可能误删正在使用的资源（比如被其他 Kustomization 引用的 Secret） - 如果 Kustomization 的
spec.path下有多个kustomization.yaml（如 overlay 分层），prune 仅作用于该路径下解析出的最终资源集，不会跨路径清理 - 注意：prune 不影响 HelmRelease 管理的资源——Helm 的 release 生命周期由 helm-controller 控制，Flux 不介入其 uninstall 流程
flux reconcile kustomization 触发的是“收敛动作”，不是“漂移检测”
这个命令只是强制 source-controller 拉取最新 Git 提交、kustomize-controller 重新构建并应用，它不比较当前集群状态与 Git 声明的差异。真正的 drift 检测发生在 reconcile 完成后，通过 kubectl get kustomization -n flux-system -o wide 查看 Ready 状态和 Inventory 字段变化——若 Inventory 中资源数量/UID 与上次不同，说明发生了收敛（即修正了漂移）。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 常见误操作：在 CI 中频繁调用
flux reconcile却不检查.status.lastAttemptedRevision是否更新，导致空跑无效果 - 想实现“发现漂移就自动 reconcile”，得自己写一个 cron job 调用
flux get kustomization解析.status.inventory.entries并与 Git commit hash 对比，再决定是否触发 reconcile - 不要依赖
interval字段做“准实时”收敛——默认 5m 间隔意味着漂移可能存留近 5 分钟
Golang 服务如何配合 Flux 实现“可观测的漂移收敛”
Go 应用本身不能直接参与 Flux 的 reconcile 流程，但可以通过暴露健康端点和结构化日志，让外部工具判断是否真已收敛。例如：
- 在 Go HTTP server 中加一个
/healthz?check=flux-sync端点，返回当前加载的 Git commit SHA（从环境变量或挂载的flux-system/gitrevisionConfigMap 读取） - 用
flux get kustomization myapp -n flux-system -o jsonpath='{.status.lastAppliedRevision}'获取 Flux 认为的“已应用版本”，与应用内实际版本比对，不一致即视为未收敛 - 避免在 Go 代码里调用 client-go 去轮询 Kustomization 资源——这会绕过 Flux 的幂等性保障，且易因 RBAC 权限不足失败
真正容易被忽略的点是：Flux 的“自愈”完全依赖 Git 仓库的权威性。如果你允许人工 kubectl apply -f 绕过 Git 直接改集群，那所有 reconcile 和 prune 都只是在擦边球——漂移会反复再生。必须用 RBAC 锁死非 Flux 账户对生产命名空间的 write 权限，这才是自愈的前提。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
