A county deploys metrics-server and must raise replicas and resource requests without forking upstream YAML by hand each time. Which Kustomize approach fits cluster-component customization?
Select an answer to reveal the explanation.
Short Explanation
Kustomize overlays are like sticky notes on the vendor instructions—same base, your local tweaks for replicas and CPU. You keep upstream readable and your county’s patches in one place. Hand-editing production every quarter is how configs drift into folklore.
Full Explanation
A county deploying metrics-server should raise replicas and resource requests with a Kustomize overlay that patches those fields onto the base manifests—without forking upstream YAML by hand each time. Sticky notes on the vendor instructions keep the base readable and the county’s tweaks reviewable. Editing live objects only with kubectl edit leaves desired replica count unrecorded and prone to drift. Replacing metrics-server with an in-house aggregation layer is out of scope for a simple replica/resources tweak. Storing replica counts in etcd via etcdctl put bypasses Kubernetes object management and Kustomize entirely. Exam caveat: Overlays capture intent for audits and upgrades better than untracked live edits. Operational check: Maintain base+overlay in git, kubectl apply -k, verify metrics-server replicas/resources, and re-apply after upstream base bumps. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team.