How does classic client-side `kubectl apply` compute a three-way merge, and when does it silently overwrite a field?
Quick Answer
Client-side apply merges three inputs: the last-applied-configuration annotation kubectl stored, the live object from the cluster, and your new YAML. It diffs them locally and sends a strategic merge patch. It breaks when another tool changes a field without updating kubectl annotation — the next apply computes no change for that field and quietly reverts it.
Detailed Answer
The three inputs are: (1) the kubectl.kubernetes.io/last-applied-configuration annotation, kubectl record of what it last applied; (2) the current live object; and (3) the manifest being applied. kubectl compares them to decide what changed and issues a strategic merge patch. The blind spot is that only kubectl maintains that annotation. If an HPA scales replicas from 3 to 5, the live object changes but the annotation still says 3. Your next apply sees your intent as 3, the annotation as 3, and patches replicas back to 3 — with no conflict and no warning. That silent revert is the core failure mode SSA eliminates by tracking ownership on the server instead of in a client-held annotation.
Code Example
# Classic three-way merge inputs # 1) last-applied-configuration (annotation) # 2) live object # 3) your YAML kubectl apply -f deploy.yaml
Interview Tip
Name the three inputs precisely and give the HPA example — interviewers want the concrete failure, not just "it can overwrite things".