Saltar para o conteúdo principal
Versão Next

Rollback

Este guia descreve os procedimentos para reverter atualizações dos componentes do TDP Kubernetes, tanto via Helm quanto via ArgoCD. O rollback permite restaurar rapidamente uma versão anterior em caso de falhas ou comportamentos inesperados após uma atualização.

Atenção

Antes de realizar qualquer rollback, faça backup dos dados persistentes. Dependendo do componente, um rollback pode causar perda de dados se as migrações de schema forem incompatíveis com versões anteriores.

Backup de Dados antes do Rollback​

Antes de iniciar o rollback, proteja os dados persistentes criando snapshots dos PVCs.

Identificar os PVCs do Componente​

Terminal input
kubectl get pvc -n <namespace> -l app.kubernetes.io/instance=<release>

Criar Snapshots dos Volumes​

Terminal input
kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: <release>-pre-rollback-snapshot
  namespace: tdp-project
spec:
  volumeSnapshotClassName: <snapshot-class>
  source:
    persistentVolumeClaimName: <pvc-name>
EOF

Verificar o Status do Snapshot​

Terminal input
kubectl get volumesnapshot -n <namespace>

Certifique-se de que o snapshot está com status readyToUse: true antes de prosseguir.

Rollback via Helm​

Consultar o Histórico de Revisões​

Utilize o comando helm history para visualizar todas as revisões de um release:

Terminal input
helm history <release> -n <namespace>

A saída exibirá uma tabela com as colunas: REVISION, UPDATED, STATUS, CHART, APP VERSION e DESCRIPTION. Identifique a revisão para a qual deseja reverter.

Exemplo de saída:

REVISION    UPDATED                     STATUS        CHART              APP VERSION    DESCRIPTION
1           2025-01-15 10:30:00         deployed      tdp-kafka-1.0.0    3.5.1          Install complete
2           2025-02-10 14:00:00         superseded    tdp-kafka-1.0.0    3.5.1          Upgrade complete
3           2025-03-01 09:15:00         deployed      tdp-kafka-2.0.0    3.6.0          Upgrade complete

Rollback para uma Revisão Específica​

Para reverter para uma revisão específica:

Terminal input
helm rollback <release> <revisao> -n <namespace>

Por exemplo, para reverter o tdp-kafka para a revisão 2:

Terminal input
helm rollback tdp-kafka 2 -n <namespace>

Rollback para a Revisão Anterior​

Para reverter para a revisão imediatamente anterior (sem especificar o número):

Terminal input
helm rollback <release> -n <namespace>

Rollback com Recriação de Pods​

Em alguns casos, pode ser necessário forçar a recriação de todos os pods durante o rollback:

Terminal input
helm rollback <release> <revisao> -n <namespace> --recreate-pods

Verificar o Resultado do Rollback​

Após o rollback, confirme que o release foi revertido com sucesso:

Terminal input
helm status <release> -n <namespace>
helm history <release> -n <namespace>

A última entrada no histórico deve indicar STATUS: deployed com a descrição Rollback to <revisao>.

Rollback via ArgoCD​

O rollback via ArgoCD consiste em reverter o estado do repositório Git para a versão anterior dos manifestos.

Reverter o Manifesto no Git​

A abordagem recomendada é reverter o commit que introduziu a atualização:

Terminal input
git log --oneline -10  # Identifique o commit da atualização
git revert <commit-hash>
git push origin main

O ArgoCD detectará a alteração no repositório e sincronizará o cluster automaticamente (se a sincronização automática estiver habilitada).

Forçar Sincronização após Reversão​

Se a sincronização automática estiver desabilitada, force a sincronização manualmente:

Terminal input
argocd app sync tdp-kafka

Rollback pelo ArgoCD CLI​

O ArgoCD também permite reverter a última operação de sincronização:

Terminal input
argocd app rollback tdp-kafka
Nota

O rollback pelo ArgoCD CLI reverte apenas o estado do cluster. O repositório Git não é alterado, o que pode causar um novo sync automático restaurando a versão indesejada. Sempre reverta também no Git para garantir consistência.

Verificar o Estado após Rollback​

Terminal input
argocd app get tdp-kafka

O status deve indicar Synced e Healthy após a conclusão do rollback.

Cenários Comuns de Rollback​

Cenário 1: Falha na Inicialização dos Pods​

Sintoma: pods ficam em estado CrashLoopBackOff ou Error após atualização.

Diagnóstico:

Terminal input
kubectl describe pod -n <namespace> -l app.kubernetes.io/instance=<release>
kubectl logs -n <namespace> -l app.kubernetes.io/instance=<release> --previous

Solução: rollback para a versão anterior:

Terminal input
helm rollback <release> -n <namespace>

Cenário 2: Incompatibilidade de Schema da base de dados​

Sintoma: erros de migração de schema nos logs do componente.

Diagnóstico:

Terminal input
kubectl logs -n <namespace> -l app.kubernetes.io/instance=<release> | grep -i "migration\|schema\|database"

Solução:

  1. Restaure o backup da base de dados (snapshot do PVC)

  2. Realize o rollback do release:

    Terminal input
    helm rollback <release> -n <namespace>

  3. Verifique se o componente inicializa corretamente com o banco restaurado

Cenário 3: Problemas de Conectividade entre Componentes​

Sintoma: componentes não conseguem se comunicar após atualização parcial.

Diagnóstico:

Terminal input
kubectl get endpoints -n <namespace>
kubectl get svc -n <namespace>

Solução: verifique se todos os componentes dependentes foram atualizados para versões compatíveis. Se necessário, realize rollback de todos os componentes afetados.

Cenário 4: Degradação de Performance​

Sintoma: latência elevada ou consumo excessivo de recursos após atualização.

Diagnóstico:

Terminal input
kubectl top pods -n <namespace> -l app.kubernetes.io/instance=<release>
kubectl describe pod -n <namespace> -l app.kubernetes.io/instance=<release>

Solução: verifique as diferenças de configuração entre as versões e ajuste os resources no values.yaml. Se o problema persistir, realize rollback.

Rollback Parcial (Componente Individual)​

Em cenários onde apenas um componente apresenta problemas após uma atualização geral, é possível realizar rollback apenas desse componente.

Identificar o Componente Problemático​

Terminal input
kubectl get pods -n <namespace> --field-selector=status.phase!=Running
helm list -n <namespace> --failed

Rollback Individual via Helm​

Terminal input
helm rollback <release-problematico> -n <namespace>

Verificar Compatibilidade​

Após o rollback parcial, verifique se o componente revertido é compatível com as demais versões atualizadas:

Terminal input
kubectl logs -n <namespace> -l app.kubernetes.io/instance=<release-problematico> --tail=50
kubectl get pods -n <namespace>
Atenção

O rollback parcial pode causar incompatibilidades entre componentes se houver dependências de versão. Consulte a matriz de compatibilidade antes de prosseguir.

Boas Práticas de Rollback​

  1. Sempre faça backup dos dados persistentes antes de iniciar o rollback
  2. Documente a causa do rollback para referência futura
  3. Teste em ambiente de staging antes de atualizar produção, reduzindo a necessidade de rollbacks
  4. Monitore os logs após o rollback para confirmar a estabilidade
  5. Mantenha o Git consistente com o estado do cluster -- se usar ArgoCD, sempre reverta no Git
  6. Não pule revisões -- em caso de múltiplos rollbacks, reverta uma revisão de cada vez