Desafio 8: Troubleshooting - Drift, Sync Failure e Health Degraded

Diagnosticar e resolver três cenários reais de falha no ArgoCD EKS Capabilities: drift manual no cluster, sync failure por permissão insuficiente, e aplicação com health degraded.

O ArgoCD detecta e corrige automaticamente desvios entre o estado desejado (Git) e o estado real (cluster). Mas quando algo falha, saber onde olhar é a diferença entre resolver em 5 minutos ou passar horas no escuro.

No EKS Capabilities, algumas ferramentas de debug do self-managed não estão disponíveis - você não tem acesso direto aos logs do ArgoCD controller, não pode editar argocd-cm, e o sync timeout é fixo em 120 segundos. O debug é feito via UI do EKS Console, kubectl no cluster alvo, e os eventos do Kubernetes.

Os três cenários abaixo são independentes. Tente resolver cada um antes de abrir a solução.

Situação: Uma aplicação está Synced e Healthy. Um desenvolvedor faz uma mudança manual direta no cluster (kubectl edit deployment). O que acontece e como reverter?

Dica: O ArgoCD EKS Capability faz polling a cada 6 minutos por padrão. Se você configurou webhook no desafio anterior, a detecção é imediata.

# Forçar sync para reverter ao estado do Git
argocd app sync minha-app --force

syncPolicy:
  automated:
    prune: true
    selfHeal: true

Situação: Você cria uma Application que tenta criar um ClusterRole. O sync falha com erro de permissão. O AppProject está configurado com clusterResourceWhitelist vazio.

Dica: A mensagem de erro exata aparece na UI do ArgoCD ao expandir o recurso com falha em Sync Status.

# Ver eventos de sync
kubectl get events -n argocd --sort-by='.lastTimestamp'

# Ver detalhes da application
kubectl describe application minha-app -n argocd

spec:
  clusterResourceWhitelist:
  - group: "rbac.authorization.k8s.io"
    kind: "ClusterRole"
  - group: "rbac.authorization.k8s.io"
    kind: "ClusterRoleBinding"

kubectl apply -f project-corrigido.yaml
argocd app sync minha-app

Situação: Uma Application está Synced mas Degraded. O deployment foi aplicado mas os pods não sobem. Como diagnosticar via ArgoCD e via kubectl?

Dica: Synced significa que o ArgoCD aplicou o manifesto com sucesso. Degraded significa que o Kubernetes não conseguiu subir os pods - são problemas diferentes.

kubectl get pods -n meu-namespace
kubectl describe pod NOME_DO_POD -n meu-namespace
kubectl logs NOME_DO_POD -n meu-namespace --previous

• Implementar health checks customizados para CRDs e recursos não-padrão
• Integrar CloudTrail com CloudWatch para alertas em sync failures recorrentes
• Explorar o desafio de Fleet Management para ver como troubleshooting escala em ambientes multi-cluster