Differences Between Helm v2 and Helm v3 and Adaptation Solutions

Helm v2 stops at version 2.17.0. Currently, Helm v3 is the standard in the Helm community. You are advised to switch your charts to Helm v3 format as soon as possible.

Changes since Helm v2:

Removal of Tiller
Helm v3 is simpler and easier to use. It removes tiller and directly connects to the API server using kubeconfig, simplifying the security model.
Improved upgrade strategy: 3-way strategic merge patches
Helm v2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart's manifest against the proposed chart's manifest 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 a kubectl edit), those changes were not considered. This resulted in resources being unable to roll back to its previous state.

Helm v3 uses a three-way strategic merge patch. Helm considers the old manifest, its live state, and the new manifest when generating a patch. Helm compares the current live state with the live state of the old manifest, checks whether the new manifest is modified, and automatically supplements the new manifest to generate the final update patch.

For details and examples, see https://v3.helm.sh/docs/faq/changes_since_helm2.
Secrets as the default storage driver
Helm v2 used ConfigMaps by default to store release information. In Helm v3, Secrets are now used as the default storage driver.
Release names are now scoped to the namespace
In Helm v2, the information about each release was stored in the same namespace as Tiller. In practice, this meant that once a name was used by a release, no other release could use that same name, even if it was deployed in a different namespace. In Helm v3, information about a particular release is now stored in the same namespace as the release itself. This means that the release name can be used in different namespaces. The namespace of the application is the same as that of the release.
Verification mode change
Helm v3 verifies the chart format more strictly. For example, Helm v3 bumps the apiVersion in Chart.yaml from v1 to v2. For the Chart.yaml of v2, apiVersion must be set to v1. After installing the Helm v3 client, you can run the helm lint command to check whether the chart format complies with the Helm v3 specifications.

Adaptation solution: Adapt the Helm v3 chart based on the Helm official document https://helm.sh/docs/topics/charts/. The apiVersion field is mandatory.
Removal of the crd-install hook
The crd-install hook has been removed in favor of the crds/ directory in Helm v3. Note that the resources in the crds/ directory are deployed only during the release installation and are not updated during the upgrade. When the resources are deleted, the resources are retained in the crds/ directory. If the CRD already exists, it will be skipped with a warning during the repeated installation.

Adaptation solution: According to the Helm document, you can hold your CRD in the crds/ directory or a separate chart. Helm cannot upgrade or delete the CRD. Therefore, you are advised to put the CRD in one chart, and then put any resources that use that CRD in another chart.
Resources that are not created using Helm are not forcibly updated. Releases are not forcibly upgraded by default.
The forcible upgrade logic of Helm v3 is changed. After the upgrade fails, the system does not delete and rebuild the Helm v3. Instead, the system directly uses the put logic. Therefore, the CCE release upgrade uses the non-forcible update logic by default. Resources that cannot be updated through patches will make the release unable to be upgraded. If a release with the same name exists in the environment and does not have the home tag app.kubernetes.io/managed-by: Helm of Helm v3, a conflict message is displayed.

Adaptation solution: Delete related resources and create them using Helm.
Limit on release historical records
Only the latest 10 release versions are retained by default.