Observação tradução: Esta é uma tradução de um post-mortem público do blog de engenharia da empresa . Ele descreve um problema com o conntrack em um cluster Kubernetes, que levou à inatividade parcial de alguns serviços de produção.
Este artigo pode ser útil para quem deseja aprender um pouco mais sobre postmortems ou prevenir alguns possíveis problemas de DNS no futuro.
Isso não é DNS
Não pode ser DNS
Era o DNS
Um pouco sobre postmortems e processos na Preply
Uma autópsia descreve um mau funcionamento ou algum evento na produção. A postmortem inclui uma linha do tempo de eventos, impacto no usuário, causa raiz, ações tomadas e lições aprendidas.
Nas reuniões semanais com pizza, entre a equipe técnica, compartilhamos diversas informações. Uma das partes mais importantes dessas reuniões são as autópsias, que na maioria das vezes são acompanhadas por uma apresentação com slides e uma análise mais aprofundada do incidente. Embora não batamos palmas após as autópsias, tentamos desenvolver uma cultura de “não culpa” (). Acreditamos que escrever e apresentar postmortems pode ajudar a nós (e a outros) a prevenir incidentes semelhantes no futuro, e é por isso que os estamos compartilhando.
Os indivíduos envolvidos num incidente devem sentir que podem falar detalhadamente sem medo de punição ou retribuição. Sem culpa! Escrever uma autópsia não é um castigo, mas uma oportunidade de aprendizado para toda a empresa.
Problemas com DNS no Kubernetes. Pós-morte
Дата: 28.02.2020
Autores: Amet U., Andrey S., Igor K., Alexey P.
Título: Finalizado
Em resumo: Indisponibilidade parcial de DNS (26 min) para alguns serviços no cluster Kubernetes
Influência: 15000 eventos perdidos para os serviços A, B e C
Causa raiz: O Kube-proxy não conseguiu remover corretamente uma entrada antiga da tabela conntrack, então alguns serviços ainda estavam tentando se conectar a pods inexistentes
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...Acionar: Devido à baixa carga dentro do cluster Kubernetes, o CoreDNS-autoscaler reduziu o número de pods na implantação de três para dois
solução: A próxima implantação do aplicativo iniciou a criação de novos nós, o CoreDNS-autoscaler adicionou mais pods para atender o cluster, o que provocou uma reescrita da tabela conntrack
Detecção: O monitoramento do Prometheus detectou um grande número de erros 5xx para os serviços A, B e C e iniciou uma chamada para os engenheiros de plantão
Erros 5xx no Kibana
Atividade
Ação
tipo
Responsável
Tarefa
Desative o escalonador automático para CoreDNS
impedido
Amet U.
DEVOPS-695
Configure um servidor DNS de cache
diminuir
Máximo V.
DEVOPS-665
Configurar monitoramento conntrack
impedido
Amet U.
DEVOPS-674
Lições aprendidas
O que foi bem:
- O monitoramento funcionou bem. A resposta foi rápida e organizada
- Não atingimos nenhum limite nos nós
O que estava errado:
- Causa raiz real ainda desconhecida, semelhante a em conexão
- Todas as ações corrigem apenas as consequências, não a causa raiz (bug)
- Sabíamos que mais cedo ou mais tarde poderíamos ter problemas com DNS, mas não priorizamos as tarefas
Onde tivemos sorte:
- A próxima implantação foi acionada pelo CoreDNS-autoscaler, que substituiu a tabela conntrack
- Este bug afetou apenas alguns serviços
Linha do tempo (EET)
tempo
Ação
22:13
O autoescalador CoreDNS reduziu o número de pods de três para dois
22:18
Engenheiros de plantão passaram a receber ligações do sistema de monitoramento
22:21
Os engenheiros de plantão começaram a descobrir a causa dos erros.
22:39
Os engenheiros de plantão começaram a reverter um dos serviços mais recentes para a versão anterior
22:40
Os erros 5xx pararam de aparecer, a situação se estabilizou
- Hora de detecção: 4 min
- Tempo antes da ação: 21 min
- Hora de consertar: 1 min
informação adicional
- Registros do CoreDNS:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Links para Kibana (corte), Grafana (corte)
Para minimizar o uso da CPU, o kernel do Linux usa algo chamado conntrack. Resumindo, este é um utilitário que contém uma lista de registros NAT armazenados em uma tabela especial. Quando o próximo pacote chegar do mesmo pod para o mesmo pod de antes, o endereço IP final não será recalculado, mas será retirado da tabela conntrack.
Como funciona o contrack
Resultados de
Este foi um exemplo de uma de nossas autópsias com alguns links úteis. Especificamente neste artigo compartilhamos informações que podem ser úteis para outras empresas. É por isso que não temos medo de cometer erros e é por isso que tornamos pública uma de nossas autópsias. Aqui estão algumas postmortems públicas mais interessantes:
- GitLab:
- Dropbox:
- Spotify:
- Muitos outros de e repositório
- Também postmortem público com livro SRE
Fonte: habr.com