An open-data cluster needs a sustained operational change to kube-proxy’s ConfigMap as part of lifecycle maintenance. What does this illustrate about cluster lifecycle work?
Select an answer to reveal the explanation.
Short Explanation
Keeping a cluster healthy isn’t only version bumps—it’s also tending the little system services that make networking and DNS tick. Editing kube-proxy’s ConfigMap (carefully) is normal ops, same family as CoreDNS tweaks. Treat addons like living machinery, not museum pieces.
Full Explanation
An open-data cluster making a sustained operational change to kube-proxy’s ConfigMap illustrates that lifecycle management includes safely updating core addon configuration—not only binary upgrades. Keeping a cluster healthy means tending the system services that make networking tick, treating addons as living municipal machinery. Core addons are not immutable after kubeadm init; kube-proxy and CoreDNS are routinely reconfigured with care. kube-proxy ConfigMaps are cluster ops concerns, not owned exclusively by each application Deployment. Changing kube-proxy settings does not require replacing etcd with a new empty data directory. Exam caveat: Addon ConfigMap edits are lifecycle work—validate cluster-wide blast radius. Operational check: Backup the ConfigMap, apply the intentional kube-proxy change, restart/roll kube-proxy Pods if required, and verify Service ClusterIP reachability for a canary civic app. 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.