Error: Server-Side Apply field conflict detected on Pulumi Kubernetes resource

Error: resource ... was not successfully created by the Kubernetes API server: Server-Side Apply field conflict detected

TL;DR

You switched providers and Kubernetes will not hand field ownership to the new one silently. Either adopt the resource with pulumi state delete + pulumi import under the new provider, or delete and recreate it.

The error

error: resource "urn:pulumi:preview-pr-107::aphiria-com-infrastructure::kubernetes:batch/v1:Job::db-init-job" was not successfully created by the Kubernetes API server: Server-Side Apply field conflict detected.
The resource managed by field manager "pulumi-kubernetes-9b013652" had an apply conflict: Apply failed with 1 conflict: conflict with "pulumi-kubernetes-4afb3fc3": .spec.template.spec.containers[name="db-init"].args

Fix it

1. Decide: adopt (no downtime) or recreate (downtime). For stateless workloads, recreate is simpler; for stateful ones, adopt.

• Success check: you have picked one path deliberately.

1. To adopt: pulumi state delete "[full URN]" --stack [stack] (removes from state, keeps the live object), then pulumi import [type] [name] [namespace]/[name] --stack [stack] with the new provider configured.

• Success check: pulumi preview shows no changes for the resource.

1. To recreate: kubectl delete [type]/[name] -n [namespace], then pulumi up.

• Success check: the resource is recreated under the new field manager.

1. Re-run pulumi up.

• Success check: no more apply conflicts.

When to use this

You hit this right after adding an explicit Provider resource (or changing provider configuration) on existing Kubernetes resources.

When NOT to use this

Do not use this for RBAC Forbidden errors or webhook failures. Those are permissions and ordering, not field-manager ownership.

Compatibility

Pulumi CLI 3.x, Pulumi Kubernetes provider v4.x, server-side apply enabled.

Variants

• The same conflict naming Deployments, StatefulSets, or Services instead of Jobs
• Apply failed with [n] conflicts listing multiple field paths

Root cause

Each provider instance is a distinct server-side-apply field manager. Kubernetes refuses silent ownership transfer between managers to prevent accidental stomps, so the new manager's apply conflicts with the old one's claimed fields.

Edge cases

• pulumi refresh does not fix ownership; it only syncs observed state.
• Force-applying with --force server-side can stomp the old manager's fields. Prefer the import path for anything stateful.