GitOps Operators Field Notes

ArgoCD makes Kubernetes drift visible. It does not decide who owns the drift, when to sync, or whether pruning is safe. Those decisions need to be explicit before teams treat the ArgoCD UI as the deployment control plane. Define Application Ownership Every ArgoCD Application should have an owner who can answer: which repo path declares the workload. which team reviews changes. which namespace and cluster are in scope. whether sync is automatic or manual. whether prune and self-heal are enabled. what emergency live changes are allowed. how live fixes get written back to Git. If the owner is “platform,” but the application team controls the chart values, the ownership model is incomplete. ...

Flux is strongest when reconciliation evidence is easy to read without guessing which controller owns the change. The operator task is to connect Git revision, source artifact, rendered manifests, apply result, and workload health into one story. Follow The Controller Chain A Flux deployment often crosses several controllers: GitRepository or HelmRepository -> Kustomization or HelmRelease -> Kubernetes objects -> workload readiness When a rollout fails, check each link before changing manifests. ...

Drift is a signal. Prune is a deletion engine. Treat them differently. A GitOps controller showing drift tells you declared state and live state differ. It does not automatically prove which side is correct. Classify Drift First Before syncing, classify the difference: expected controller mutation. admission webhook defaulting. Helm-rendered value change. manual incident fix. secret or certificate rotation. generated name or checksum annotation. unmanaged object created outside Git. stale manifest that should be removed. The response depends on the class. Syncing everything is fast, but it can erase the clue that explains the incident. ...