Kubernetes para Quem Precisa Executá-lo

Os tutoriais de Kubernetes ensinam você a fazer deploy de um pod. Ninguém ensina o que fazer quando um node silenciosamente sai do estado Ready às 3 da manhã e seu telefone de on-call não para de tocar. Isto é sobre a segunda parte.

Resource requests e limits não são opcionais

Se você pular resources.requests e resources.limits nos seus containers, o scheduler está adivinhando, e o kubelet não tem ideia do que remover primeiro quando um node fica com pouca memória. Configure requests para o que o container realmente usa sob carga normal, não para o que você espera que use. Configure memory limits próximos aos requests já que pods com OOM-killed reiniciam limpo, mas CPU limits devem geralmente ser mais soltos ou ausentes a menos que você esteja lutando contra vizinhos barulhentos, porque CPU throttling sob um hard limit causa picos de latência que são miseráveis para debugar. Execute kubectl top pods -n your-namespace regularmente e compare com o que você declarou. Incompatibilidades se acumulam rapidamente em clusters com mais que um punhado de serviços.

etcd é o cluster inteiro, trate assim

Tudo o que Kubernetes conhece vive em etcd. Perder etcd e você perde o estado do seu cluster, não apenas alguns metadados. Execute etcdctl snapshot save /backup/etcd-snapshot.db em um cronograma, e realmente teste restaurar em um cluster scratch pelo menos uma vez. Já vi times com backups noturnos que se mostraram corrompidos por três meses porque ninguém verificou. Se você está em um control plane gerenciado (EKS, GKE, AKS), você não gerencia etcd diretamente, mas você ainda deve conhecer a história de backup e restore do seu provider antes de precisar, não durante um incidente.

Liveness e readiness probes precisam discordar às vezes

Um erro comum é usar o mesmo endpoint para ambas as probes de liveness e readiness. Liveness deve responder