A public-health platform team debates one-off kubectl apply of raw YAML versus packaging cluster addons. Why do teams commonly prefer Helm or Kustomize for repeatable addon installs?
Select an answer to reveal the explanation.
Short Explanation
One-off kubectl apply is like taping handwritten sticky notes on each clinic server—easy once, painful the tenth time. Helm charts and Kustomize overlays give you a repeatable, versioned recipe for the same addon. They do not replace the API server or turn off RBAC.
Full Explanation
Public-health teams prefer Helm or Kustomize for repeatable addon installs because packaging improves repeatability—versioned charts or overlays beat sprawling one-off kubectl apply copies taped like sticky notes on each clinic server. Packaging does not replace the API server or disable RBAC. Packaging does not replace the need for an API server or etcd in the cluster. Raw YAML apply does not automatically version, roll back, and parameterize every install without tooling. Helm and Kustomize do not disable RBAC so addons install without review. Exam caveat: Repeatability and reviewability are the operational win over ad-hoc apply sprawl. Operational check: Install a canary addon via chart/overlay in staging, upgrade once, roll back once, and compare drift against a hand-copied YAML workflow. 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. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.