Diferenças entre Helm v2 e Helm v3 e soluções de adaptação

Helm v2 pára na versão 2.17.0. Atualmente, o Helm v3 é o padrão na comunidade Helm. Você é aconselhado a mudar seus gráficos para o formato de Helm v3 o mais rápido possível.

Alterações desde Helm v2:

1. Remoção de tiller

   O Helm v3 é mais simples e fácil de usar. Ele remove o timão e se conecta diretamente ao servidor da API usando o kubeconfig, simplificando o modelo de segurança.

2. Estratégia de atualização aprimorada: patches de mesclagem estratégicos de 3 vias

   Helm v2 usou um patch de mesclagem estratégico de duas vias. Durante uma atualização, ele comparou o manifesto do gráfico mais recente com o manifesto do gráfico proposto para determinar quais alterações precisavam ser aplicadas aos recursos no Kubernetes. Se as alterações foram aplicadas ao cluster fora de banda (como durante uma edição kubectl), essas alterações não foram consideradas. Isso resultou na impossibilidade de os recursos reverterem para o estado anterior.

   O Helm v3 usa um patch de mesclagem estratégico de três vias. Helm considera o manifesto antigo, seu estado vivo e o novo manifesto ao gerar um patch. O Helm compara o estado ativo atual com o estado ativo do manifesto antigo, verifica se o novo manifesto foi modificado e complementa automaticamente o novo manifesto para gerar o patch de atualização final.

   Para obter detalhes e exemplos, consulte https://v3.helm.sh/docs/faq/changes_since_helm2.

3. Segredos como o driver de armazenamento padrão

   O Helm v2 usava o ConfigMaps por padrão para armazenar informações de release. No Helm v3, Segredos agora são usados como o driver de armazenamento padrão.

4. Nomes de release agora estão sob escopo para o namespace

   No Helm v2, as informações sobre cada lançamento foram armazenadas no mesmo namespace que Tiller. Na prática, isso significava que, uma vez que um nome fosse usado por um release, nenhum outro release poderia usar o mesmo nome, mesmo que fosse implementado em um namespace diferente. No Helm v3, as informações sobre um release específico agora são armazenadas no mesmo namespace da versão em si. Isso significa que o nome da versão pode ser usado em diferentes namespaces. O namespace da aplicação é o mesmo que o do release.

5. Alteração do modo de verificação

   Helm v3 verifica o formato do gráfico de forma mais rigorosa. Por exemplo, o Helm v3 aumenta a apiVersion em Chart.yaml de v1 para v2. Para o Chart.yaml de v2, apiVersion deve ser definida como v1. Depois de instalar o cliente Helm v3, você pode executar o comando helm lint para verificar se o formato do gráfico está em conformidade com as especificações do Helm v3.

   Solução de adaptação: adapte o gráfico de Helm v3 com base no documento oficial Helm https://helm.sh/docs/topics/charts/. O campo apiVersion é obrigatório.

6. Remoção do hook crd-install

   O hook crd-install foi removido em favor do diretório crds/ no Helm v3. Note que os recursos no diretório crds/ são implementados somente durante a instalação do release e não são atualizados durante a atualização. Quando os recursos são excluídos, os recursos são mantidos no diretório crds/. Se o CRD já existir, ele será ignorado com um aviso durante a instalação repetida.

   Solução de adaptação: de acordo com o documento de Helm, você pode manter seu CRD no diretório crds/ ou em um gráfico separado. Helm não pode atualizar ou excluir o CRD. Portanto, é aconselhável colocar o CRD em um gráfico e, em seguida, colocar quaisquer recursos que usem esse CRD em outro gráfico.

7. Recursos que não são criados usando Helm não são forçosamente atualizados. Releases não são forçosamente atualizados por padrão.

   A lógica de atualização forçada do Helm v3 é alterada. Depois que a atualização falha, o sistema não apaga e recria o Helm v3. Em vez disso, o sistema usa diretamente a lógica put. Portanto, a atualização da versão do CCE usa a lógica de atualização não forçada por padrão. Recursos que não podem ser atualizados por meio de patches tornarão a versão incapaz de ser atualizada. Se uma versão com o mesmo nome existir no ambiente e não tiver a tag inicial app.kubernetes.io/managed-by: Helm of Helm v3, uma mensagem de conflito é exibida.

   Solução de adaptação: exclua recursos relacionados e crie-os usando o Helm.

8. Limite de release de registros históricos

   Somente as versões mais recentes de 10 releases são mantidas por padrão.

Para mais mudanças e detalhes, veja os documentos oficiais do Helm.

• Diferenças entre Helm v2 e Helm v3: https://v3.helm.sh/docs/faq/changes_since_helm2
• Como migrar do Helm v2 para o Helm v3: https://helm.sh/docs/topics/v2_v3_migration