When running helm upgrade, does helm reinstall all manifests in the chart, or only the manifests that have been changed?
I cannot seem to find any documentation regarding this. Any reference or documentation is welcome.
Thanks in advance.
Depends on a resource type of objects which you updating.
Helm itself never make any decision about what should be updated. It just generates objects from templates based on your configuration and apply them to a Kubernetes.
Now, let's talk about how Kubernetes working with objects. Each object has parameters which can be updated in-place and which cannot.
For example, in a Deployment you can update it's annotations or labels, but if you will update the same values in a spec (which is actually a template for a ReplicSet), it will create new RS with that values and that new RS will create new Pods.
So, if you call helm upgrade and, for example, one resulting object has some new values which cannot be updated on existing object (in-place), then Kubernetes will create a new object to replace the old one.
That is independent process for each object you are creating during upgrade process, so some of objects will be replaced (re-created) and some - no.
There is no difference between those things. Kubernetes is a convergent system.
Helm only sends Kubernetes manifests for things it thinks have changed.
There's some discussion of this in the Helm 3 upgrade notes, and more specifically Improved Upgrade Strategy: 3-way Strategic Merge Patches:
Helm 2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart's manifest against the proposed chart's manifest (the one supplied during
helm upgrade). It compared the differences between these two charts to determine what changes needed to be applied to the resources in Kubernetes. If changes were applied to the cluster out-of-band (such as during akubectl edit), those changes were not considered. [...]In Helm 3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, and the new manifest when generating a patch.
This means if you do things like kubectl scale deployment or kubectl edit deployment, particularly if you're using Helm 2, that might result in things getting "lost" from Helm's point of view: since the old Helm-managed content and the proposed Helm-managed content are the same, it won't send an update, even though the live cluster state is different. There are some concrete examples in the upgrade notes linked above.
In practice I've found this means two things:
For almost all settings, try to manage them via Helm if you can. Don't make manual changes to Helm-managed resources using kubectl edit. (kubectl scale is probably fine, depending on how involved your deployment process is; things like the HorizontalPodAutoscaler will also directly change replicas:.)
If Helm (version 2 at least) gets confused, you might need to helm del --purge an existing release before reinstalling it.