A city installs ingress-nginx as a shared cluster component. Which packaging approach matches CKA-style cluster-component management with Helm?
Select an answer to reveal the explanation.
Short Explanation
Cluster addons like ingress-nginx are perfect Helm citizens—chart in, release tracked, upgrade/rollback without folklore tarballs. That’s admin work on shared platform pieces, not app-dev homework. Treat the Ingress controller like a product you version, not a one-off scp.
Full Explanation
Installing ingress-nginx as a shared city component matches CKA-style management by installing and upgrading it as a Helm release so the addon is versioned and rollback-friendly. Treat the Ingress controller like a product you version—not a folklore tarball scp’d onto hosts. Hand-copying static Pod YAML into /etc/kubernetes/manifests on every worker is brittle and conflates addon lifecycle with static control-plane pods. Baking ingress-nginx into the kube-apiserver image is not a packaging approach and couples unrelated components. docker run on the control plane is not reserved-as-only-for-CKAD folklore—the point is Helm is appropriate for cluster addons in CKA scope. Exam caveat: Helm releases give history/upgrade/rollback that imperative host runs lack. Operational check: helm install/upgrade ingress-nginx with reviewed values, helm history, test an Ingress for a civic app, and practice helm rollback in staging. 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.