Error from server (Conflict): The object was modified between reading it and writing it back

the object has been modified; please apply your changes to the latest version and try again is optimistic concurrency working correctly. Someone else wrote first, and your update was based on stale data.

Applies to: All Kubernetes versions

What it means

Every Kubernetes object carries a resourceVersion. An update includes the version the client read, and the API server rejects it if the object has changed since. This prevents lost updates: without it, two controllers reading and writing the same object would silently overwrite each other. A conflict is therefore not a fault — it is the mechanism doing its job, and the correct response is always the same: re-read, re-apply the change, retry. Controllers do this automatically and conflicts are routine in their logs. The error only reaches a person when a manual edit races a controller, or when a hand-written client omits the retry loop.

Most common causes

• A controller updating the object at the same time — extremely common on status fields.
• Two people editing the same object simultaneously.
• A client that reads once and retries the write without re-reading.
• A kubectl edit session left open while a controller reconciled the object.
• Two controllers both claiming ownership of the same field.
• A high-frequency reconciliation loop writing to an object more often than a client can read and update it.

How to diagnose it

1. Determine whether it is occasional or constant. Occasional conflicts are normal; constant ones mean two writers are fighting.
2. Check what else manages the object: kubectl get RESOURCE NAME -o yaml --show-managed-fields shows which manager owns which field.
3. Look for a controller reconciling in a tight loop by watching the object's resourceVersion change.
4. For your own client, confirm it re-reads inside the retry rather than reusing the original object.

How to fix it

1. Retry with a fresh read. Use the official client libraries' retry-on-conflict helpers rather than writing the loop by hand.
2. Use kubectl apply, which handles this correctly, instead of read-modify-write with replace.
3. Use Server-Side Apply for controllers, so field ownership is explicit and two managers touching different fields do not conflict at all.
4. Patch only the field you care about rather than sending the whole object, which narrows the window for conflict.
5. Resolve genuine ownership disputes between controllers rather than retrying through them.

Notes

Server-Side Apply is the structural answer to repeated conflicts. It tracks which manager owns which field, so two controllers writing different parts of the same object coexist instead of overwriting each other and generating conflicts indefinitely.

Related

• Error from server (AlreadyExists) — An object with that name already exists
• Error from server (NotFound) — The named object does not exist

Sources

• Kubernetes documentation — Kubernetes API Concepts: concurrency control
• Kubernetes documentation — Server-Side Apply