Apply failed with conflicts: Server-Side Apply refused because another manager owns the fields you are setting

Server-Side Apply tracks which manager owns each field. A conflict means you are trying to change a field owned by something else — a controller, a webhook, or a different tool — and it wants that stated explicitly.

Applies to: Kubernetes 1.18 and later

What it means

Server-Side Apply records a field manager for every field of an object. When an apply would change a field owned by a different manager, it fails with a conflict listing the fields and their owners rather than silently overwriting. This is a deliberate improvement over client-side apply, where two systems managing one object simply fight and the last writer wins. The error is therefore usually informative rather than obstructive: it is telling you that something else is actively managing this field, which is worth knowing before you take it over.

Most common causes

• A controller or operator managing the same field, such as a replica count owned by an autoscaler.
• A mutating webhook setting fields, which then owns them.
• Two deployment tools applying the same object.
• A previous client-side apply whose ownership was migrated to a manager name that differs from the current one.
• A field set by hand with kubectl edit, which claims ownership under a different manager.

How to diagnose it

1. Read the conflict message — it names each field and its current owner.
2. Inspect ownership: kubectl get RESOURCE NAME --show-managed-fields -o yaml.
3. Determine whether the other owner is a controller doing its job, which changes the correct response entirely.
4. Check whether two pipelines are applying the same object with different field manager names.

How to fix it

1. Remove the contested field from your manifest if another manager should own it. An autoscaler owning replicas is the canonical example — leaving it out of the manifest is the correct fix, not forcing it.
2. Use --force-conflicts to take ownership deliberately, when you genuinely are the right owner.
3. Use a consistent field manager name across a pipeline so it does not conflict with itself.
4. Resolve genuine ownership disputes between two tools at the process level rather than by forcing on every run.

Notes

Forcing conflicts on every apply as a matter of habit discards the entire benefit of the mechanism. The conflict is information: something else believes it owns this field, and that is worth resolving once rather than overriding continuously.

Related

• Error from server (Conflict) — The object was modified by someone else
• metadata.annotations: Too long — The stored configuration annotation exceeded its limit

Sources

• Kubernetes documentation — Server-Side Apply
• Kubernetes documentation — Kubernetes API Concepts
• Kubernetes documentation — Horizontal Pod Autoscaling