O Kubernetes já se cura sozinho, até certo ponto. Ele reinicia um container que morreu, recria um pod que sumiu e tira tráfego de uma réplica que não responde. Isso resolve a falha mecânica. O que ele não faz é entender por que a falha aconteceu, e é aí que a maioria dos incidentes reais mora.
O que o cluster já cura, e o que não cura
O self-healing nativo do Kubernetes é poderoso e deve ser bem configurado antes de qualquer coisa: liveness e readiness probes reiniciam e despriorizam pods doentes, o scheduler recoloca workloads quando um nó cai, e o autoscaling acompanha a carga. Tudo isso é reação a sintomas conhecidos.
O que escapa: um deploy com imagem ou variável errada que entra em crashloop, uma dependência externa fora do ar, uma degradação lenta que não derruba o probe mas estoura a latência, um vazamento de memória que só aparece horas depois. Reiniciar o pod não conserta nada disso, só adia. Falta diagnóstico.
Onde entra um agente como o kagent
O kagent é um framework open source, do ecossistema cloud native, para colocar agentes de IA operando dentro do Kubernetes. Em vez de só reagir a um probe, o agente observa o quadro completo (eventos, logs e métricas), correlaciona os sinais, forma uma hipótese da causa e executa uma ação corretiva, com as ferramentas e os limites que você definir.
Na prática, é levar o raciocínio que um SRE de plantão faria para dentro do cluster: olhar o que mudou, cruzar com o que está quebrando e agir, só que em segundos e sem acordar ninguém.
Um fluxo de self-healing, passo a passo
Imagine um serviço que entra em crashloop logo após um deploy. Em vez do pod reiniciar em loop até alguém perceber, o agente: lê os eventos e vê o CrashLoopBackOff; abre os logs e identifica um erro de configuração introduzido no último release; correlaciona com o rollout recente; aplica o rollback para a revisão anterior; e confirma a recuperação pelos readiness probes e pelo SLO. O incidente se resolve antes de virar chamado.
Sem guardrails, não é confiável
Um agente que pode agir no cluster precisa de freios claros, e é isso que separa um experimento de algo que você confia em produção:
- Escopo de ações: o que o agente pode fazer sozinho (rollback, restart) e o que exige aprovação (apagar recursos, escalar custo).
- Permissões mínimas: RBAC restrito, por namespace, nada de acesso amplo "por garantia".
- Auditoria: todo diagnóstico e toda ação registrados, para o time saber exatamente o que o agente fez e por quê.
- Escalonamento: quando a confiança é baixa ou a ação falha, o agente chama o humano em vez de insistir.
Confiança em automação não vem de dar poder ao agente, vem de dar escopo e visibilidade. Um agente auditável que age dentro de limites estreitos rende muito mais do que um "piloto automático" que ninguém entende.
É exatamente esse tipo de operação que estruturamos nos projetos de SRE e AIOps: self-healing de verdade, com guardrails e auditoria, e o time entendendo o sistema o suficiente para confiar nele e mantê-lo. Se a sua operação ainda depende de gente acordando de madrugada, vamos conversar.