O Helm v2 chegou ao fim de sua vida útil em novembro de 2020 e não recebe mais patches de segurança ou correções de bugs. O plugin de migração helm-2to3 também está arquivado. Recomendamos fortemente que você conclua a migração para o Helm v3 o mais rápido possível. Para novos clusters, instale o Helm v3 diretamente em vez de seguir este procedimento de migração.
Para eliminar os possíveis riscos de segurança associados ao servidor Tiller do Helm v2, recomendamos que você migre do Helm v2 para o Helm v3. Caso contrário, invasores podem usar o Tiller para instalar aplicativos não autorizados no seu cluster e explorar outros recursos do Helm sem autorização. Este tópico descreve como migrar do Helm v2 para o Helm v3.
Pré-requisitos
Antes de iniciar a migração, verifique se você atende às seguintes condições:
O cliente Helm v2 está instalado e atualmente gerencia releases no seu cluster.
Você tem acesso ao cluster via kubectl e pode se conectar ao servidor de API do Kubernetes.
É necessário que você tenha as permissões RBAC para acessar o namespace do Tiller e gerencie ConfigMaps ou Secrets que armazenam dados de release.
Se o seu cluster executar o Kubernetes 1.22 ou posterior, atualize as versões de API dos seus recursos gerenciados pelo Helm para versões compatíveis antes de migrar. Para mais informações, consulte Update the API version of a Kubernetes resource using helm-mapkubeapis to perform an in-place upgrade.
Faça backup dos dados do Helm v2
Antes de iniciar a migração, faça backup dos seus dados do Helm v2 para que você possa restaurá-los caso a migração falhe.
-
Execute o seguinte comando para fazer backup do diretório home do Helm v2:
cp -r ~/.helm ~/.helm.backup -
Execute o seguinte comando para fazer backup dos dados de release armazenados no namespace do Tiller. Por padrão, o Helm v2 armazena os dados de release como ConfigMaps no namespace
kube-system.kubectl get configmaps -n kube-system -l "OWNER=TILLER" -o yaml > helm2-releases-backup.yaml
Etapas de migração
Esta seção usa o Helm v3.3.0 como exemplo para demonstrar como migrar do Helm v2 para o Helm v3. Para mais informações sobre as versões do Helm, consulte Helm.
Se for possível reinstalar o aplicativo, exclua-o e reinstale-o. Para mais informações, consulte Helm v2 Tiller upgrade announcement.
Etapa 1: Instale o Helm v3
Instale o Helm v3 executando os seguintes comandos:
wget https://get.helm.sh/helm-v3.3.0-linux-amd64.tar.gz
tar -xzvf helm-v3.3.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm
helm versionSaída esperada:
version.BuildInfo{Version:"v3.3.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a****", GitTreeState:"clean", GoVersion:"go1.13.4"}Etapa 2: Instale o plugin Helm 2to3
Instale o plugin Helm 2to3 executando os seguintes comandos. Os exemplos neste tópico usam o chart ack-node-local-dns para demonstrar o processo de migração.
git clone https://github.com/helm/helm-2to3.git
helm plugin install ./helm-2to3Etapa 3: Migrar a configuração do Helm v2
Migre a sua configuração do Helm v2, incluindo repositórios, plugins e modelos iniciais de charts (starters), para o Helm v3 executando os seguintes comandos. Recomendamos que você execute primeiro uma simulação (dry run) para visualizar as alterações.
-
Execute uma simulação para visualizar a migração da configuração:
helm 2to3 move config --dry-run -
Se a saída da simulação parecer correta, execute a migração real:
helm 2to3 move config -
Verifique se a migração da configuração foi concluída com sucesso:
helm repo list
Etapa 4: Converter releases para o Helm v3
Antes de converter uma release, execute uma simulação para verificar se a conversão será bem-sucedida sem fazer nenhuma alteração:
helm 2to3 convert ack-node-local-dns --dry-runSe a saída da simulação não mostrar erros, execute o seguinte comando para converter o chart ack-node-local-dns para o Helm v3:
helm 2to3 convert ack-node-local-dns --delete-v2-releasesSaída esperada:
2022/12/27 17:12:50 Release "ack-node-local-dns" will be converted from Helm v2 to Helm v3.
2022/12/27 17:12:50 [Helm 3] Release "ack-node-local-dns" will be created.
2022/12/27 17:12:50 [Helm 3] ReleaseVersion "ack-node-local-dns.v1" will be created.
2022/12/27 17:12:50 [Helm 3] ReleaseVersion "ack-node-local-dns.v1" created.
2022/12/27 17:12:50 [Helm 3] Release "ack-node-local-dns" created.
2022/12/27 17:12:50 [Helm 2] Release "ack-node-local-dns" will be deleted.
2022/12/27 17:12:50 [Helm 2] ReleaseVersion "ack-node-local-dns.v1" will be deleted.
2022/12/27 17:12:50 [Helm 2] ReleaseVersion "ack-node-local-dns.v1" deleted.
2022/12/27 17:12:50 [Helm 2] Release "ack-node-local-dns" deleted.
2022/12/27 17:12:50 Release "ack-node-local-dns" was converted successfully from Helm v2 to Helm v3.Após a conclusão da conversão, verifique se o Helm v3 agora gerencia a release:
helm list -n kube-systemRepita esta etapa para cada release do Helm v2 que deseja migrar. Observe que, após a migração, as releases do Helm v3 têm escopo de namespace. Para listar releases em todos os namespaces, execute helm list --all-namespaces.
Etapa 5: Limpar os dados do Helm v2
Após confirmar que a migração de todas as releases foi concluída com sucesso, limpe a configuração restante do Helm v2 e os recursos do Tiller. Esta etapa remove o Tiller do seu cluster, o que elimina o risco de segurança associado ao Helm v2.
-
Execute uma simulação para visualizar a limpeza:
helm 2to3 cleanup --dry-run -
Se a saída da simulação parecer correta, execute a limpeza real:
helm 2to3 cleanup
Após a limpeza, não será mais possível usar o Helm v2 neste cluster. Certifique-se de que a migração e a verificação de todas as releases foram concluídas antes de prosseguir.
Perguntas frequentes
Erro "Resource already exists" devido a apiVersion inconsistente
Problema
Após atualizar o seu cluster, o sistema exibe a mensagem rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: MutatingWebhookConfiguration, namespace: , name: mse-pilot-ack-mse-pilot ao migrar do Helm v2.
Causa
Clusters cuja versão do Kubernetes é 1.22 ou posterior não suportam mais a v1beta1. Versões anteriores do Kubernetes ainda suportam a v1beta1. O sistema pode retornar o erro anterior após a atualização do seu cluster.
Solução
Atualize a versão da API do recurso. Para mais informações, consulte Update the API version of a Kubernetes resource using helm-mapkubeapis to perform an in-place upgrade.
Para evitar esse erro, recomendamos que você atualize as versões de API dos seus recursos antes de migrar do Helm v2 para o Helm v3. Consulte a seção Pré-requisitos.
Erro ao atualizar um chart após migrar do Helm v2 para o Helm v3
Problema
Após migrar do Helm v2 para o v3, ocorre um erro ao atualizar a versão de um chart, por exemplo, da v1.3.5 para a v1.5.3: err: rendered manifests contain a resource that already exists. Unable to continue with update: MutatingWebhookConfiguration "ack-node-local-dns-admission-controller" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "ack-node-local-dns".
Causa
O chart não possui os metadados de propriedade do Helm. Para corrigir, defina os metadados de propriedade.
Soluções
Use um dos seguintes métodos para resolver este problema:
-
Método 1: Atribua o recurso à release correspondente do Helm.
-
Para continuar, edite o arquivo de configuração executando o seguinte comando.
kubectl edit MutatingWebhookConfiguration ack-node-local-dns-admission-controller -
Adicione as seguintes
annotationselabelsà release.annotations: meta.helm.sh/release-name: ack-node-local-dns meta.helm.sh/release-namespace: kube-system labels: app.kubernetes.io/managed-by: Helm
-
-
Método 2: Exclua o recurso executando o seguinte comando.
kubectl delete MutatingWebhookConfiguration ack-node-local-dns-admission-controller