Migrating Helm v2 to v3

    The full list of changes from Helm 2 to 3 are documented in the FAQ section. The following is a summary of some of those changes that a user should be aware of before and during migration:

    1. Removal of Tiller:
      • Replaces client/server with client/library architecture ( binary only)
      • Security is now on per user basis (delegated to Kubernetes user cluster security)
      • Releases are now stored as in-cluster secrets and the release object metadata has changed
      • Releases are persisted on a release namespace basis and not in the Tiller namespace anymore
    2. Chart repository updated:
      • helm search now supports both local repository searches and making search queries against Artifact Hub
    3. Chart apiVersion bumped to “v2” for following specification changes:
      • Dynamically linked chart dependencies moved to Chart.yaml (requirements.yaml removed and requirements —> dependencies)
      • Library charts (helper/common charts) can now be added as dynamically linked chart dependencies
      • Charts have a type metadata field to define the chart to be of an application or library chart. It is application by default which means it is renderable and installable
      • Helm 2 charts (apiVersion=v1) are still installable
    4. XDG directory specification added:
      • Helm home removed and replaced with XDG directory specification for storing configuration files
      • No longer need to initialize Helm
      • helm init and helm home removed
      • This use case applies when you want Helm v3 to manage existing Helm v2 releases
      • It should be noted that a Helm v2 client:
        • can manage 1 to many Kubernetes clusters
        • can connect to 1 to many Tiller instances for a cluster
      • This means that you have to be aware of this when migrating as releases are deployed into clusters by Tiller and its namespace. You have to therefore be aware of migrating for each cluster and each Tiller instance that is managed by the Helm v2 client instance
      • The recommended data migration path is as follows:
        1. Backup v2 data
        2. Migrate Helm v2 configuration
        3. Migrate Helm v2 releases
        4. When confident that Helm v3 is managing all Helm v2 data (for all clusters and Tiller instances of the Helm v2 client instance) as expected, then clean up Helm v2 data
      • The migration process is automated by the Helm v3 plugin
    • Blog post explaining 2to3 plugin usage with examples