代码拉取完成，页面将自动刷新
Helm v3 plugin which migrates and cleans up Helm v2 configuration and releases in-place to Helm v3
One of the most important aspects of upgrading to a new major release of Helm is the
migration of data. This is especially true of Helm v2 to v3 considering the architectural
changes between the releases. The 2to3 plugin helps with this migration by supporting:
WARNING: All data migrations carry a level of risk. Helm v2 migration is no different. You should be aware of any risks specific to your environment and prepare a data migration strategy for your needs.
Here are some suggestions to mitigate against potential risks during migration:
helm, kubectl or other tools could lead to data loss and an indeterminate
state for the release(s).Note: A Helm v2 client:
This means that you have to cognisant 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. Clean up should only be run once all migration for a Helm v2 client is complete.
2to3 plugin installed on the same systemkubectl access using kubeconfig files.
The --kubeconfig and --kube-context flags can be used with the convert and cleanup commands to set the kubeconfig path and context to override the environment configuration.tiller namespace for required RBAC roles. If Tillerless setup, then a service account with the proper cluster wide RBAC roles will need to be used. If not used, forbidden errors will be thrown when trying to access restricted resources.Based on the version in plugin.yaml, release binary will be downloaded from GitHub:
$ helm plugin install https://github.com/helm/helm-2to3.git
Downloading and installing helm-2to3 v0.1.3 ...
https://github.com/helm/helm-2to3/releases/download/v0.1.3/helm-2to3_0.1.3_darwin_amd64.tar.gz
Installed plugin: 2to3
Helm's plugin install hook system relies on /bin/sh, regardless of the operating system present. Windows users can work around this by using Helm under WSL.
$ wget https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz
$ tar xzf helm-v3.0.0-linux-amd64.tar.gz
$ ./linux-amd64/helm plugin install https://github.com/helm/helm-2to3
Migrate Helm v2 configuration in-place to Helm v3:
$ helm 2to3 move config [flags]
Flags:
--dry-run simulate a command
-h, --help help for move
It will migrate:
Note:
move config command will create the Helm v3 config and data folders if they don't exist, and will override the repositories.yaml file if it does exist.HELM_V2_HOME, HELM_V3_CONFIG and HELM_V3_DATA:$ export HELM_V2_HOME=$PWD/.helm2
$ export HELM_V3_CONFIG=$PWD/.helm3
$ export HELM_V3_DATA=$PWD/.helm3
$ helm 2to3 move config
<helm3> plugin remove) and
re-add (<helm3> plugin install) it as required.repositories.yaml is copied to Helm v3 which contains references to repositories added in Helm v2. Local respoitories are not copied to Helm v3.
You should remove all local repositories from Helm v3 using <helm3> repo remove and re-add where necessary using <helm3> repo add. This is a necessary refresh to align references
for Helm v3.<helm3> repo update. This cleans up any Helm v2 cache references from Helm v3.Migrate Helm v2 releases in-place to Helm v3
$ helm 2to3 convert [flags] RELEASE
Flags:
--delete-v2-releases v2 release versions are deleted after migration. By default, the v2 release versions are retained
--dry-run simulate a command
-h, --help help for convert
--kube-context string name of the kubeconfig context to use
--kubeconfig string path to the kubeconfig file
-l, --label string label to select Tiller resources by (default "OWNER=TILLER")
-s, --release-storage string v2 release storage type/object. It can be 'secrets' or 'configmaps'. This is only used with the 'tiller-out-cluster' flag (default "secrets")
--release-versions-max int limit the maximum number of versions converted per release. Use 0 for no limit (default 10)
-t, --tiller-ns string namespace of Tiller (default "kube-system")
--tiller-out-cluster when Tiller is not running in the cluster e.g. Tillerless
Note: There is a limit set on the number of versions/revisions of a release that are converted. It is defaulted to 10 but can be configured with the --release-versions-max flag.
When the limit set is less that the actual number of versions then only the latest release versions up to the limit will be converted. Older release versions with not be converted.
If --delete-v2-releases is set, thes older versions will remain in Helm v2 storage but will no longer be visible to Helm v2 commands like helm list. Clean up
will remove them from storage.
Clean up Helm v2 configuration, release data and Tiller deployment:
$ helm 2to3 cleanup [flags]
Flags:
--config-cleanup if set, configuration cleanup performed
--dry-run simulate a command
-h, --help help for cleanup
--kube-context string name of the kubeconfig context to use
--kubeconfig string path to the kubeconfig file
-l, --label string label to select Tiller resources by (default "OWNER=TILLER")
--name string the release name. When it is specified, the named release and its versions will be removed only. Should not be used with other cleanup operations
--release-cleanup if set, release data cleanup performed
-s, --release-storage string v2 release storage type/object. It can be 'secrets' or 'configmaps'. This is only used with the 'tiller-out-cluster' flag (default "secrets")
--tiller-cleanup if set, Tiller cleanup performed
-t, --tiller-ns string namespace of Tiller (default "kube-system")
--tiller-out-cluster when Tiller is not running in the cluster e.g. Tillerless
It will clean:
Clean up can be done individually also, by setting one or all of the following flags: --config-cleanup, --release-cleanup and --tiller-cleanup.
Cleanup of a release and its versions is done by setting --name flag. This is a singular operation and is not to be used with the other cleanup operations.
If none of these flag are set, then all cleanup is performed.
For cleanup it uses the default Helm v2 home folder.
To override this folder you need to set the environment variable HELM_V2_HOME:
$ export HELM_V2_HOME=$PWD/.helm2
$ helm 2to3 cleanup
Warning: The cleanup command will remove the Helm v2 Configuration, Release Data and Tiller Deployment.
It cleans up all releases managed by Helm v2. It will not be possible to restore them if you haven't made a backup of the releases.
Helm v2 will not be usable afterwards. Cleanup should only be run once all migration (clusters and Tiller instances) for a Helm v2 client instance is complete.
Q. I get an error when I try to do a chart dependency update in Helm v3 after configuration migration
Error might be similar to the following:
$ helm dep update chrt-1/
Hang tight while we grab the latest from your chart repositories...
...Unable to get an update from the "local" chart repository (http://127.0.0.1:8879/charts):
Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0.0.1:8879: connect: connection refused
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Error: open /home/usr1/.cache/helm/repository/local-index.yaml: no such file or directory
A. Local respoitories are not copied to Helm v3. You therefore need to remove all local repositories from Helm v3 using <helm3> repo remove and re-add where
required using <helm3> repo add. This is a necessary refresh to align references for Helm v3 and remove the conflict. It is worthwhile to also refresh the
repository list afterwards: <helm3> repo update. You should then be able to run the chart dependency update command successfully.
Q. How do you perform Helm v2 release migration as a batch operation?
A. You can perform batch migration of releases using a command as follows:
$ kubectl get [configmap|secret] -n <tiller_namespace> \
-l "OWNER=TILLER" | awk '{print $1}' | grep -v NAME | cut -d '.' -f1 | uniq | xargs -n1 helm 2to3 convert
An example of migrating releases which are stored as ConfigMaps in Tiller namespace kube-system:
$ kubectl get configmap -n kube-system -l "OWNER=TILLER" \
| awk '{print $1}' | grep -v NAME | cut -d '.' -f1 | uniq | xargs -n1 helm 2to3 convert
If you would like to handle the build yourself, this is the recommended way to do it.
You must first have Go v1.13 installed, and then you run:
$ mkdir -p ${GOPATH}/src/github.com/helm
$ cd $_
$ git clone git@github.com:helm/helm-2to3.git
$ cd helm-2to3
$ make build
$ helm plugin install <your_path>/helm-2to3
That last command will use the binary that you built.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。