Get best of the week

Problemas com o DNS no Kubernetes. Post-mortem público

Nota perev.: é uma tradução do post-mortem público do blog de engenharia da Preply . Ele descreve um problema conntrack no cluster Kubernetes que levou a algum tempo de inatividade de alguns serviços de produção.

Este artigo pode ser útil para quem deseja aprender um pouco mais sobre o post-mortem ou para evitar possíveis problemas com o DNS no futuro.

imagem

DNS
DNS
DNS

Preply


- . , , , .

Seeking SRE

Em reuniões semanais com pizza, no círculo da equipe técnica, compartilhamos várias informações. Uma das partes mais importantes dessas reuniões é a post-mortem, que geralmente é acompanhada de uma apresentação com slides e uma análise mais profunda do incidente. Apesar de não “bater palmas” após post-mortem, tentamos desenvolver uma cultura “sem culpa ” ( embreagem sem culpa ). Acreditamos que escrever e apresentar post-mortem pode nos ajudar (e não apenas) a prevenir incidentes semelhantes no futuro, e é por isso que os compartilhamos.

As pessoas envolvidas no incidente devem sentir que podem falar em detalhes sobre o assunto, sem medo de punição ou retaliação. Sem censura! Escrever um post-mortem não é um castigo, mas uma oportunidade de aprender para toda a empresa.

Mantenha o CALMS & DevOps: S é para compartilhamento

Problemas com o DNS no Kubernetes. Post mortem


Data: 28/02/2020

Autores: Amet U., Andrei S., Igor K., Aleksey P.

Status:

Resumo concluído : Indisponibilidade parcial do DNS (26 min) para alguns serviços no cluster Kubernetes

Impacto: 15.000 eventos foram perdidos para os serviços A,

Causa raiz B e C : o proxy Kube não pôde excluir corretamente a entrada antiga da tabela conntrack; portanto, alguns serviços ainda tentaram se conectar a envios 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: ...

Trigger: Devido à baixa carga no interior Kubernetes-cluster, CoreDNS-Autoscaler reduziu o número de vagens em deploymenta de três para dois

decisão: Outra aplicativos Implantar iniciou a criação de novos nós, CoreDNS-Autoscaler acrescentou mais plataformas para o serviço de cluster, o que provocou mesa conntrack de substituição

de Detecção : O monitoramento do Prometheus detectou um grande número de erros 5xx nos serviços A, B e C e iniciou uma chamada para os engenheiros de serviço


5xx erros no Kibana

Ações


AjaUm tipoResponsávelTarefa
Desativar autoscaler para CoreDNSimpedidoAmet U.DEVOPS-695
Instalar o servidor DNS em cachediminuirMax V.DEVOPS-665
Configurar o monitoramento conntrackimpedidoAmet U.DEVOPS-674

Lições aprendidas


O que foi bem:

  • O monitoramento funcionou claramente. A reação foi rápida e organizada.


:

  • , conntrack
  • , ()
  • , DNS,

:

  • CoreDNS-autoscaler, conntrack

(EET)


22:13CoreDNS-autoscaler
22:18
22:21
22:39
22:405xx ,

  • Tempo para detecção: 4 min.
  • Tempo para concluir a ação: 21 min.
  • Tempo para correção: 1 min

informação adicional



Para minimizar a utilização do processador, o kernel do Linux usa algo como conntrack. Em resumo, este é um utilitário que contém uma lista de entradas NAT armazenadas em uma tabela especial. Quando o próximo pacote vier 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 o conntrack funciona

Sumário


Este foi um exemplo de um dos nossos post-mortem 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 um de nosso público post-mortem. Aqui estão alguns temas públicos post-mortem mais interessantes:

More articles:


All Articles