Definir limites seguros para a autorrecuperação

Recupere uma condição conhecida

A autorrecuperação deteta automaticamente uma falha definida e tenta uma ação de recuperação autorizada. Reiniciar um processo falhado ou substituir uma instância com problemas são exemplos possíveis. A ação tem de ser adequada à falha e ao modelo de estado do serviço.

O Kubernetes pode substituir instâncias de workloads que falharam e reconciliar o estado declarado. Isto não corrige lógica defeituosa da aplicação nem todas as falhas de armazenamento. A recuperação da infraestrutura e a correção do software exigem verificações diferentes. Autorrecuperação no Kubernetes.

Defina o objetivo antes do mecanismo. Recuperar um export significa que o trabalho elegível é concluído corretamente. Um contentor em execução é apenas uma pré-condição.

Separe três tipos de alteração

Um agente pode propor uma correção após a recuperação. Essa proposta é uma nova alteração de software. Não pode herdar autoridade ilimitada do controlador de recuperação.

O controlador também não pode editar os próprios critérios de sucesso quando uma verificação falha. Caso contrário, o sistema pode comunicar uma melhoria sem melhorar o serviço.

Escreva a política de recuperação antes de a ativar

A política seguinte é fictícia. Os números ilustram escolhas de conceção; não são valores predefinidos recomendados.

Use uma identidade com o mínimo de privilégios. Registe nos logs a versão da política, as evidências da ativação, a ação, o recurso e o resultado. Disponibilize uma forma independente de desativar o controlador. Defina a pessoa responsável que recebe o escalamento.

Teste as falhas e a recuperação bem-sucedida

Uma nova tentativa pode repetir um efeito secundário. Um worker pode guardar um ficheiro e parar antes de confirmar o job. Verifique a idempotência antes de permitir outra execução. Consulte o exemplo de falha cloud native.

As novas tentativas também podem agravar a sobrecarga de uma dependência. Use tentativas limitadas, timeouts e backoff adequado. Evite novas tentativas sincronizadas em todas as instâncias. A AWS explica como o backoff e o jitter ajudam a reduzir esta amplificação. Orientações sobre novas tentativas.

Teste a política fictícia com três casos. Um único worker parado deve recuperar. Uma indisponibilidade da base de dados deve impedir substituições repetidas. Uma falha de integridade incerta deve parar a automação e pedir uma decisão de resposta.

Verifique também a falta de telemetria. A ausência de heartbeat pode significar um worker falhado ou uma falha no caminho de recolha. O controlador precisa de evidências suficientes para a sua ação, não de confiança numa explicação da IA.

Meça se a política ajuda

Registe recuperações verificadas, tentativas sem sucesso, escalamentos, trabalho duplicado e tempo com impacto nos utilizadores. Compare estes dados com o método operacional anterior em condições semelhantes.

Mantenha o defeito subjacente como trabalho de engenharia. Reiniciar repetidamente um processo com fuga de memória pode reduzir o impacto imediato enquanto a fuga continua. Continue com a melhoria autónoma para ligar a observação a uma correção duradoura.