Helm Charts no Kubernetes em 2026: Empacotamento, Deploy e Perguntas de Entrevista

Os Helm Charts do Kubernetes simplificam o deploy de aplicacoes ao empacotar todos os recursos do Kubernetes em um unico artefato versionado. O Helm 3, a versao estavel atual, elimina a necessidade do Tiller e introduz suporte a registros OCI, tornando a distribuicao de charts mais segura e padronizada. Este tutorial aborda a criacao de charts, templating, estrategias de deploy e as perguntas de entrevista mais comuns feitas por equipes de contratacao.

Entendendo a Estrutura e Componentes de um Helm Chart

Um Helm chart e um diretorio com uma estrutura predefinida. O nome do chart se torna o nome do diretorio, e cada arquivo serve a um proposito especifico no processo de empacotamento e deploy.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

O campo apiVersion: v2 indica compatibilidade com o Helm 3. O campo version rastreia mudancas no chart, enquanto appVersion reflete a versao da aplicacao implantada. As dependencias declaram outros charts que este chart requer, com condicoes opcionais para habilita-las ou desabilita-las.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Os values definem configuracoes padrao que os usuarios podem sobrescrever durante a instalacao. Aninhar valores sob chaves significativas mantem as configuracoes organizadas e autodocumentadas.

Criando Deployments do Kubernetes com Templates do Helm

Os templates do Helm utilizam templating Go com funcoes Sprig para gerar manifestos do Kubernetes dinamicamente. O objeto {{ .Values }} fornece acesso ao conteudo do values.yaml, enquanto {{ .Release }} contem metadados do deploy.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

A funcao nindent adiciona nova linha e indentacao, elemento critico para a geracao de YAML. O uso de include com templates nomeados (definidos em _helpers.tpl) mantem os templates DRY e mantenivelis.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Os templates helper padronizam as convencoes de nomenclatura e labels em todos os recursos, garantindo conformidade com os labels recomendados pelo Kubernetes.

Dependencias e Subcharts do Helm

Aplicacoes complexas frequentemente dependem de bancos de dados, caches ou filas de mensagens. As dependencias do Helm permitem incorporar esses elementos como subcharts, gerenciados automaticamente durante a instalacao.

# Atualizar dependencias antes do empacotamento
helm dependency update ./my-application

# Construir dependencias (cria o diretorio charts/)
helm dependency build ./my-application

O comando helm dependency update baixa as dependencias para o diretorio charts/. Dependencias condicionais usam values para alternar sua inclusao:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Esse padrao permite configuracoes especificas por ambiente, onde producao usa servicos gerenciados enquanto desenvolvimento usa bancos de dados dentro do cluster.

Deploy de Helm Charts com Gerenciamento de Releases

O Helm rastreia deploys como releases, habilitando rollbacks e atualizacoes versionadas. Cada release mantem historico para auditoria e recuperacao.

# Instalar um chart com valores personalizados
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Atualizar uma release existente
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

A flag --atomic garante que atualizacoes com falha sejam revertidas automaticamente. A flag --timeout define quanto tempo o Helm espera ate que os recursos estejam prontos antes de declarar falha.

# Ver historico de releases
helm history my-release -n production

# Rollback para revisao anterior
helm rollback my-release 2 -n production

# Desinstalar uma release
helm uninstall my-release -n production --keep-history

A flag --keep-history preserva os registros de release mesmo apos a desinstalacao, util para conformidade e depuracao.

Estrategias de Teste e Validacao de Helm Charts

Testar Helm charts antes do deploy detecta erros de template e problemas de configuracao antecipadamente. O Helm fornece ferramentas integradas para linting e testes dry-run.

# Verificar chart por erros e melhores praticas
helm lint ./my-application

# Renderizar templates localmente sem fazer deploy
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run contra a API do cluster
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

O comando helm template renderiza manifestos localmente, util para pipelines de CI que validam o YAML gerado. A flag --dry-run envia manifestos ao servidor da API do Kubernetes para validacao sem criar recursos.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Hooks do Helm com helm.sh/hook: test sao executados apos helm test my-release, validando que os deploys funcionam corretamente pos-instalacao.

Tecnicas Avancadas de Templating no Helm

Charts de producao requerem logica condicional, loops e transformacao de dados. As funcoes Sprig estendem os templates Go com utilitarios para manipulacao de strings, codificacao e controle de fluxo.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

A funcao range itera sobre maps e listas. A funcao b64enc codifica valores em base64 para secrets do Kubernetes. Os operadores pipe encadeiam funcoes para transformacao de dados.

Perguntas e Respostas de Entrevista sobre Helm Charts

Entrevistas tecnicas frequentemente avaliam conhecimentos de Helm atraves de perguntas conceituais e praticas. A secao seguinte aborda os topicos mais frequentemente questionados.

Qual e a diferenca entre helm install e helm upgrade --install?

helm install cria uma nova release e falha se a release ja existe. helm upgrade --install (com a flag --install) cria uma nova release se nao existe, ou a atualiza se existe. Pipelines de CI/CD tipicamente usam helm upgrade --install para deploys idempotentes.

Como passar dados sensiveis para Helm charts?

Existem tres abordagens: gerenciadores de secrets externos (Vault, AWS Secrets Manager), arquivos values criptografados (SOPS, sealed-secrets), ou secrets do Kubernetes criados fora do Helm e referenciados nos templates. Deve-se evitar armazenar secrets em arquivos values.yaml em texto puro commitados no controle de versao.

O que sao hooks do Helm e quando devem ser usados?

Hooks sao executados em pontos especificos do ciclo de vida de uma release: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback e test. Usos comuns incluem migracoes de banco de dados antes de atualizacoes, envio de notificacoes apos deploys, ou execucao de testes de integracao.

Como gerenciar o versionamento de charts?

O campo version no Chart.yaml rastreia mudancas do chart usando versionamento semantico. O campo appVersion rastreia a versao da aplicacao implantada. O campo version deve ser incrementado para qualquer modificacao do chart, mesmo se a versao da aplicacao permanece igual.

Qual e o proposito do .helmignore?

Similar ao .gitignore, o .helmignore exclui arquivos do empacotamento do chart. Entradas tipicas incluem *.tgz (evitar empacotar builds anteriores), .git/, documentacao *.md nao necessaria em runtime, e arquivos de configuracao de CI.

Para aprofundar a preparacao para entrevistas de Kubernetes, e possivel explorar os modulos de perguntas Kubernetes Basics e Kubernetes Advanced no SharpSkill.

Conclusao

Pontos-chave para trabalhar com Helm charts:

• Estruturar charts com separacao clara entre metadados Chart.yaml, valores padrao values.yaml e diretorio templates contendo manifestos Kubernetes
• Usar templates helper em _helpers.tpl para padronizar nomenclatura e labels em todos os recursos
• Gerenciar dependencias via Chart.yaml com habilitacao condicional para configuracoes especificas por ambiente
• Testar charts com helm lint, helm template e helm install --dry-run antes de fazer deploy em producao
• Rastrear releases com nomes significativos e usar a flag --atomic para rollback automatico em falhas
• Armazenar secrets em gerenciadores externos em vez de arquivos values em texto puro