Plataformas & Tecnologias
Cloud Computing AWS Microsoft Oracle Kubernetes IA
Governança & Operação
FinOps Compliance Redes
Recursos & Ferramentas
Comparativos Cloud por setor Calculadoras Whitepapers
Início » Conteúdos » O que é Helm e por que facilita tanto o Kubernetes

O que é Helm e por que facilita tanto o Kubernetes

Helm é para Kubernetes o que apt é para Ubuntu ou pip é para Python — um gerenciador de pacotes. Em vez de aplicar dezenas de arquivos YAML manualmente cada vez que precisa instalar uma aplicação, você escreve helm install e o Helm cuida de tudo, incluindo upgrade e rollback.

O problema que o Helm resolve

Imagine que você quer instalar o Prometheus no seu cluster Kubernetes. O Prometheus completo — com o servidor, o AlertManager e o Grafana — exige dezenas de objetos Kubernetes: Deployments, Services, ConfigMaps, RBAC, PersistentVolumeClaims, Ingress, ServiceMonitors.

Sem Helm, você gerencia esses arquivos YAML manualmente. Quando a versão muda, você compara os arquivos novos com os antigos, aplica as diferenças, reza para não ter esquecido nada.

Com Helm, você faz:

helm install prometheus prometheus-community/kube-prometheus-stack

E toda aquela complexidade é gerenciada para você.

O que é um Chart Helm

Um Chart é o pacote de distribuição do Helm — equivalente a um .deb no Debian ou a um pacote npm. Ele contém:

  • Templates: os manifestos Kubernetes (YAML), mas com variáveis parametrizáveis usando a sintaxe Go template
  • values.yaml: os valores padrão para as variáveis. É aqui que você ajusta o comportamento do Chart sem modificar os templates
  • Chart.yaml: metadados do Chart (nome, versão, descrição, dependências)
  • charts/: subpastas com charts de dependência (um Chart pode depender de outros)

A parametrização é o poder do Helm. O mesmo Chart do Prometheus pode ser instalado em desenvolvimento (com 1 réplica, sem persistência) e em produção (com 3 réplicas, com PVC de 100 GB) usando diferentes arquivos de values — sem duplicar os templates.

Como instalar uma aplicação com Helm

O fluxo básico:

1. Adicionar um repositório de Charts:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

2. Inspecionar os valores disponíveis:

helm show values prometheus-community/kube-prometheus-stack > valores-custom.yaml

3. Instalar com valores customizados:

helm install meu-prometheus prometheus-community/kube-prometheus-stack 
  --namespace monitoring 
  --values valores-custom.yaml

A diferença com aplicar YAML manualmente é significativa: o Helm registra tudo que foi instalado como uma “release”. Você pode listar releases (helm list), ver o histórico de versões e fazer rollback se algo der errado.

Helm Repository: onde ficam os Charts

O repositório público central é o ArtifactHub (artifacthub.io) — o equivalente ao Docker Hub para Charts Helm. Lá você encontra Charts oficiais e da comunidade para praticamente qualquer aplicação: bancos de dados, ferramentas de monitoramento, ingress controllers, cert-managers e mais.

Para ambientes corporativos, o ideal é ter um repositório privado de Charts. As opções mais comuns são:

  • Harbor: registry de containers que também serve Charts Helm
  • ChartMuseum: servidor de repositório Helm dedicado, open source
  • Nexus Repository: solução corporativa que suporta Helm entre outros formatos
  • OCI Registry: Helm 3 suporta armazenar Charts em qualquer registry compatível com OCI (como o ECR da AWS ou o Harbor)

Helm vs Kustomize

Essa é uma comparação frequente. Ambas resolvem o problema de customizar manifestos Kubernetes, mas com abordagens diferentes:

Aspecto Helm Kustomize
Abordagem Templates com lógica (Go template) Patches e overlays sobre YAML base
Curva de aprendizado Maior (sintaxe de template) Menor (só YAML)
Distribuição de pacotes Nativo (Charts, repositórios) Não tem conceito de “pacote”
Lifecycle (upgrade/rollback) Nativo com versionamento de release Não gerencia — você aplica kubectl
Complexidade para customização Depende do Chart — pode ser limitante Mais flexível para patches granulares
Integração com GitOps (ArgoCD, Flux) Suportado nativamente Suportado nativamente

Na prática, a escolha depende do contexto:

  • Helm é melhor quando você distribui software para terceiros (você cria o Chart) ou quando quer usar aplicações de terceiros com uma instalação gerenciada
  • Kustomize é melhor quando você tem um conjunto de manifestos próprios que precisa adaptar para diferentes ambientes (dev, staging, prod) sem a overhead de um Chart completo

Muitas equipes usam os dois: Helm para instalar aplicações de terceiros (Prometheus, cert-manager, nginx-ingress), Kustomize para gerenciar os manifestos das próprias aplicações.

Helm upgrade e rollback

Um dos maiores valores do Helm é o gerenciamento de ciclo de vida:

Upgrade: quando uma nova versão do Chart está disponível ou você quer mudar os values:

helm upgrade meu-prometheus prometheus-community/kube-prometheus-stack 
  --values valores-custom.yaml

O Helm aplica as mudanças de forma inteligente, modificando apenas o que mudou.

Rollback: se o upgrade causou problemas:

helm rollback meu-prometheus 1

O 1 é o número da revisão anterior. O Helm mantém o histórico de revisões de cada release, o que permite voltar para qualquer versão anterior rapidamente.

Uninstall: para remover tudo que o Helm instalou:

helm uninstall meu-prometheus --namespace monitoring

O Helm remove todos os objetos que criou — uma operação que manualmente exigiria identificar e deletar cada recurso um por um.


Precisa de suporte para implementar Helm em um ambiente Kubernetes em cloud privada? Fale com um arquiteto Adentro.

Nesta página