Compare kubectl create, kubectl replace and kubectl apply for updating a live Kubernetes object, and explain what server-side apply changed about tracking field ownership and conflicts.

## Three verbs, three semantics **create** is imperative: POST the object, fail with AlreadyExists if it is there. Fine for one-shot setup, useless in a pipeline that runs repeatedly. **replace** is a full PUT. The object becomes exactly what you sent, so any field you omitted disappears — including things another component legitimately set. It also requires the current resourceVersion, so it either fails or overwrites whatever changed between your read and your write. Use it when you truly want "the object is now exactly this". **apply** is declarative and idempotent: create if absent, otherwise merge. It is the verb GitOps and CI use because running it twice is a no-op and it does not disturb fields it does not mention. ## Why apply needed a memory Merging alone cannot express deletion. If your manifest no longer mentions a field, did you delete it, or did you never own it? Client-side apply solved this with the `kubectl.kubernetes.io/last-applied-configuration` annotation: kubectl stored the manifest it applied last time and did a three-way merge across previous manifest, current live object, and new manifest. Fields present before and absent now were removed; fields never in your manifest were left alone. The weaknesses were real. The annotation could be absent (object created with create) or stale (someone used replace), merge logic lived in the client so different kubectl versions could disagree, and only kubectl participated — controllers and operators writing to the same object were invisible to the scheme. The annotation also duplicated the whole object, sometimes blowing size limits. ## Server-side apply Server-side apply makes apply a first-class API operation (`PATCH` with content type `application/apply-patch+yaml`). The client sends the manifest it cares about plus a **field manager** identity; the API server does the merge and records ownership in `metadata.managedFields` — a list of entries, one per manager and operation, each holding the set of field paths that manager owns. Consequences: - **Conflicts are explicit.** If manager `argocd` owns `spec.replicas: 3` and you apply `spec.replicas: 5` as manager `kubectl`, you get 409 Conflict naming the field. You can drop the field, pass `--force-conflicts` to take ownership, or change the real owner. Previously that write would have silently won and been silently reverted later. - **Removal is by omission.** Drop a field from your manifest and you release it; if nobody else owns it, it is removed from the object. - **Multiple writers coexist.** An autoscaler can own `spec.replicas` while your manifest owns the pod template, without either fighting the other, provided your manifest omits replicas. - **Lists need merge keys.** Structured merge relies on schema-declared list types (map/set/atomic) so per-item ownership works; atomic fields are owned wholesale. ## Practical guidance Use `kubectl apply --server-side` (and set `--field-manager` to a meaningful name in automation) so ownership is attributable. Do not reflexively pass `--force-conflicts` in CI — a conflict is information: another actor believes it owns that field. Investigate before overriding. If you migrate a long-lived object from client-side to server-side apply, the API server reconciles the old annotation into managedFields on first use, and the annotation stops being authoritative.