GitOps ownership transfer: keep one reconciler authoritative per resource

Last updated: 5 Oct 20266 min read

tutorial

Two GitOps Applications, a Helm release, and a manual operator can all target the same resource identity. They may alternate writes, produce a persistent out-of-sync state, or delete the object when one owner prunes it. A transfer must identify the object, current tracking metadata, field managers, deletion behavior, and intended new owner. Server-side apply can share nonoverlapping fields, but it does not make two controllers safe owners of the same immutable or atomic field.

Operational decision

A platform team moves the shared ingress controller Service from a bootstrap Helm release to a cluster GitOps Application. First enumerate every release and Application that tracks the Service, its live field managers, and the exact desired manifest each renders. Freeze the old release's ability to update or delete that object, then make the new Application observe or adopt it under an agreed ownership policy. Run a sync with collision detection enabled and verify the Service keeps its stable address and selectors. Remove the old template only after checking that its uninstall or prune path will not delete the adopted object. Test the sequence in an isolated cluster with the same tracking mode and chart version. A resource that must remain owned by the bootstrap system should be excluded from the new Application rather than suppressed from the conflict view. Record the handoff commit and live object identity; a green sync from the new owner is not enough if the old release still has a deletion claim over it.

Ingress Service handoff
Identity: core/v1 Service platform/ingress-gateway
Old owner: bootstrap release and deletion behavior
New owner: cluster Application and field scope
Freeze: old owner cannot update or prune during transfer
Verify: address, selectors, tracking, field managers
Exit: old uninstall cannot remove adopted Service

Cost and verification

Inventorying R resources and O owners is O(R + O) when tracking information is indexed, but ownership conflicts can create repeated API writes and a controller hot loop. Measure shared-resource warnings, sync retries, field-manager conflicts, and resources whose deletion outcome is unknown. A temporary freeze adds operational overhead; use a bounded window with a named owner and a clear abort point rather than leaving both reconcilers half-enabled.

Common Mistakes

Do not add a second Application to a shared object and rely on sync order.
Do not remove the old owner before checking its deletion behavior.
Do not mistake a field-level merge for complete resource ownership.

Connected lessons

Practice and check

RabbitMQ operating follow-up

RabbitMQ queue policies: migrate immutable queue type without losing the handoff

devops

gitops