Helm
Hard
Concepts
How do Helm 3 and Helm 4 apply changes to the cluster during an install or upgrade?
Select your answer:
Show answer and explanation
Answer: Helm 3 does a three-way merge; Helm 4 uses server-side apply for new releases
Explanation
Helm 3 builds each patch from three inputs: the manifest from the previous release, the object in the cluster, and the newly rendered manifest. Helm 4 installs new releases with Kubernetes server-side apply, which tracks field ownership on the API server. On upgrade or rollback, Helm 4 keeps the release's previous apply method, so releases created by Helm 3 stay on client-side apply unless you pass --server-side.
More hard Helm questions
- Where does Helm 3 store release information by default?
- A chart has a pre-upgrade Job hook with no helm.sh/hook-delete-policy annotation. What happens to the Job left from the previous upgrade when the hook runs again?
- What does the annotation helm.sh/resource-policy: keep do on a resource in a chart?
- Which values from the parent chart can a subchart named 'redis' read?
- values.yaml contains host: "{{ .Release.Name }}.example.com". What do you write in a template so the output contains the release name instead of the literal braces?
- What is the purpose of the 'helm verify' command?