What problem does Server-Side Apply (SSA) solve in Kubernetes?
Quick Answer
A single object like a Deployment has many writers — kubectl, Helm, Argo CD/Flux, an HPA, admission webhooks, and operators. When two of them change the same field, classic apply had no reliable notion of ownership, so writers silently clobbered each other. SSA moves the merge and per-field ownership into the API server so those conflicts become explicit.
Detailed Answer
Kubernetes objects are shared state. The YAML that created a Deployment is only one of several things that legitimately modify it over its lifetime: GitOps controllers reconcile it, an HPA rewrites spec.replicas, mutating webhooks inject defaults, and operators write status. Under classic client-side apply, kubectl merged changes locally with no server-tracked record of which manager owned which field, so a later apply could quietly revert another tool. SSA (GA since Kubernetes 1.22) makes the API server the authority: each writer is a named field manager, ownership is recorded per field, and contested changes are surfaced as conflicts instead of being overwritten in silence.
Code Example
# The many writers of one Deployment: # kubectl, Helm, Argo CD/Flux, HPA, admission webhooks, operators kubectl apply --server-side -f deploy.yaml # server-tracked ownership
Interview Tip
Frame it as a shared-ownership problem first (many writers, one object), then say SSA moved merge + ownership into the API server. That framing shows you understand the *why*.