Why do we ever want to modify the deployed Helm release manifest?

Helm always tries to match Kubernetes objects in the manifest by “kind” (e.g. Deployment) and “API version” (e.g. apps/v1). However, the “API version” supported by your Kubernetes cluster could change, e.g. after upgrading the cluster to a higher version or installing a different version CRD (Custom Resource Definitions) for a third-party application (e.g. Cert Manager).

When the “API version” that was used to deploy a Kubernetes object of a “kind” is no longer supported by the cluster, Helm will fail to match the object in the release manifest and report an error:

unable to recognize "": no matches for kind "xxxxx" in version "xxxxx"

You can ask Helm to re-try the upgrade (under some circumstance, you might need this technique to force Helm to retry) but Helm can never recover from this error unless you manually modify the latest release manifest and update the “API version” to the one that is supported by your cluster. Obviously, deleting the Helm release and reinstalling the Helm chart will work — but it will unlikely be an option for most production sites.

#kubernetes #kubernetes-cluster #helm #kubectl