Server-Side Apply solved the "last writer wins" problem by tracking which manager owns which field. But that only pushed the problem down a level: what happens when two managers claim ownership of the same field? Someone still has to win, and pretending otherwise leads to silent overwrites, flapping resources, and 3 AM pages.

Kubernetes handles conflicts with three explicit strategies, and picking the wrong one is a common production mistake:

• Reject (default): The API server returns a 409 Conflict listing every disputed field and its current owner. Your controller must decide what to do — usually log and skip.
• Force ownership: Pass force: true and you steal the field. The previous owner is removed from managedFields for that path. Loud, explicit, auditable.
• Shared ownership: Two managers can co-own a field only if they submit identical values. The moment they disagree, the conflict resurfaces.

Real-world example: A team runs HPA (autoscales spec.replicas) alongside ArgoCD (syncs the Git manifest, which also sets replicas: 3). Every sync, ArgoCD tries to reset replicas to 3, HPA scales back up, and the deployment flaps every 30 seconds. The fix isn't "force" from either side — it's telling ArgoCD to ignore spec.replicas entirely via ignoreDifferences. HPA becomes the sole owner, and the conflict evaporates.

Rule of thumb for controller authors: if your controller manages a field that a human might edit with kubectl edit, never use force: true unconditionally. Instead, check the conflict response — if the other owner is kubectl-edit or another controller with legitimate claim, requeue with backoff and surface a warning event. Force is for reclaiming fields from known managers you're intentionally replacing (e.g., migrating from client-side to server-side apply).

The subtle trap: sub-field granularity. Ownership tracks individual list entries and map keys, not whole objects. Two controllers can both own spec.containers if they manage different containers by name. But if they both set spec.containers[name=app].image, that's a conflict. Reading managedFields to understand who owns what is tedious but essential — kubectl get pod foo -o yaml --show-managed-fields is your friend during incidents.

The meta-lesson: conflicts aren't failures to eliminate — they're signals that your ownership model is wrong. Every force: true in your codebase is a comment saying "I know better than the other manager." Sometimes that's true. Usually it's a bug waiting to happen.