An HPA scales a Deployment from 3 to 5 replicas, then a routine `kubectl apply -f` drops it back to 3. Explain the bug and how Server-Side Apply prevents it.
Quick Answer
The manifest and kubectl last-applied annotation both say replicas: 3, but the HPA changed only the live object. Classic apply sees no change it should make and patches replicas back to 3, silently fighting the autoscaler. With SSA, replicas is owned by the HPA, so your apply either yields (if you omit replicas) or raises an explicit conflict instead of reverting.
Detailed Answer
This is the canonical SSA motivating example. Under client-side apply the autoscaler never updates kubectl annotation, so the annotation and your YAML still say 3 while the live value is 5. kubectl reconciles toward 3 and reverts the scale-up with no warning — a production incident waiting to happen during traffic spikes. Server-side apply fixes it structurally: the HPA becomes the field manager that owns spec.replicas. If your Git manifest still declares replicas, applying it produces a conflict naming the HPA as owner, so you notice; the correct fix is to remove replicas from the manifest entirely so the HPA owns it cleanly. Either way the silent revert is gone.
Code Example
# Correct manifest when an HPA owns scaling: omit replicas
apiVersion: apps/v1
kind: Deployment
spec:
# no replicas here — the HPA owns it
template: {}
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscalerInterview Tip
Say the fix is to remove replicas from Git (let the HPA own it), not just to add --server-side — that is the senior answer.