Teste o escalonamento automático da mesma forma que você testa seu aplicativo. Faça testes de carga, quebre e veja o que acontece após um incidente. Caso contrário, você encontrará os limites quando mais doer.
A observabilidade não importa, a menos que responda a perguntas
O Kubernetes possui montanhas de dados. Coisas como logs, métricas, rastreamentos, eventos, auditorias, histórico de implantação, reinicializações de contêineres, ruído do plano de controle, entre outros. O verdadeiro desafio não é coletar informações, mas sim entendê-las. O CNCF e outros possuem práticas recomendadas para registro e telemetria, como centralizar registros e não vazar segredos. Isso é importante, mas no final das contas, os engenheiros precisam de respostas, não apenas de dados. Quando algo quebra, ninguém pergunta: “O Kubernetes está vivo?” Eles querem saber o que mudou. Aconteceu alguma coisa? Um pod caiu? O escalonamento automático disparou tarde demais? Um nó estava íntegro, um segredo foi girado, uma política de rede muito rígida, um banco de dados downstream obstruído?
A observabilidade deve estar alinhada com questões operacionais reais e não apenas com caixas de seleção para registros ou métricas. Os painéis precisam corresponder à propriedade do serviço. Os alertas precisam significar algo para os usuários finais. A telemetria deve conectar-se a implantações e incidentes. Meça a rapidez com que os engenheiros identificam a causa raiz, e não apenas se você tem os dados em algum lugar.
