🥇Problemi con DNS in Kubernetes. Post mortem pubblico

Nota del traduttore: questo è un resoconto pubblico tradotto dal blog tecnico dell'azienda Preply. Descrive un problema con conntrack nel cluster Kubernetes, che ha portato a un'interruzione parziale di alcuni servizi in produzione.

Questo articolo può essere utile a chi desidera saperne di più sui resoconti o prevenire alcuni problemi potenziali con il DNS in futuro.

Non è DNS
Non può essere DNS
Era DNS

Un po' sui resoconti e i processi in Preply

Il resoconto descrive un guasto o un evento in produzione. Il resoconto include una cronologia degli eventi, una descrizione dell'impatto sugli utenti, la causa principale, le azioni intraprese e le lezioni apprese.
Seeking SRE

Durante le riunioni settimanali con pizza, nel nostro gruppo tecnico, condividiamo varie informazioni. Una delle parti più importanti di queste riunioni sono i resoconti, che di solito sono accompagnati da presentazioni con diapositive e un'analisi più approfondita dell'incidente avvenuto. Anche se non 'applaudiamo' dopo i resoconti, cerchiamo di promuovere una cultura 'senza colpe' (blameless culture). Crediamo che la stesura e la presentazione dei resoconti possano aiutarci (e non solo) a prevenire incidenti simili in futuro, ed è per questo che li condividiamo.

Le persone coinvolte nell'incidente devono sentirsi in grado di raccontare tutto nei dettagli, senza temere punizioni o ritorsioni. Niente biasimo! Scrivere un resoconto non è una punizione, ma un'opportunità di apprendimento per tutta l'azienda.
Keep CALMS & DevOps: S is for Sharing

Problemi di DNS in Kubernetes. Resoconto

Data: 28.02.2020

Autori: Amet U., Andrei S., Igor K., Aleksei P.

Stato: Completato

In breve: Parziale indisponibilità di DNS (26 min) per alcuni servizi nel cluster Kubernetes

Impatto: 15000 eventi persi per i servizi A, B e C

Causa principale: Kube-proxy non è riuscito a rimuovere correttamente la vecchia voce dalla tabella conntrack, quindi alcuni servizi continuavano a tentare di connettersi a pod inesistenti.

E0228 20:13:53.795782       1 proxier.go:610] Impossibile eliminare le connessioni di endpoint kube-system/kube-dns:dns, errore: errore durante l'eliminazione delle voci di conntrack per il peer UDP {100.64.0.10, 100.110.33.231}, errore: il comando conntrack ha restituito: ...

Attivatore: A causa del carico ridotto all'interno del cluster Kubernetes, il CoreDNS-autoscaler ha ridotto il numero di pod nel deployment da tre a due.

Soluzione: Un'altra distribuzione dell'applicazione ha avviato la creazione di nuovi nodi, CoreDNS-autoscaler ha aggiunto più pod per servire il cluster, il che ha provocato la riscrittura della tabella conntrack

Rilevamento: Il monitoraggio di Prometheus ha rilevato un grande numero di errori 5xx per i servizi A, B e C e ha avviato una chiamata agli ingegneri di turno

Errori 5xx in Kibana

Azioni

Azione
Tipo
Responsabile
Compito

Disabilita l'autoscaler per CoreDNS
prevenire
Amet U.
DEVOPS-695

Imposta un server DNS cache
ridurre
Max V.
DEVOPS-665

Configura il monitoraggio conntrack
prevenire
Amet U.
DEVOPS-674

Lezioni apprese

Cosa è andato bene:

Il monitoraggio ha funzionato bene. La reazione è stata rapida e organizzata
Non ci siamo imbattuti in limiti nei nodi

Cosa non è andato bene:

La causa reale rimane sconosciuta, sembra un bug specifico in conntrack
Tutte le azioni risolvono solo le conseguenze, non la causa principale (bug)
Sapevamo che prima o poi avremmo potuto avere problemi con DNS, ma non abbiamo prioritizzato i compiti

Dove siamo stati fortunati:

Un'altra distribuzione ha attivato CoreDNS-autoscaler, che ha riscritto la tabella conntrack
Questo bug ha colpito solo alcuni servizi

Cronologia (EET)

Tempo
Azione

22:13
CoreDNS-autoscaler ha ridotto il numero di pod da tre a due

22:18
Gli ingegneri di turno hanno iniziato a ricevere chiamate dal sistema di monitoraggio

22:21
Gli ingegneri di turno hanno iniziato a indagare sulla causa degli errori

22:39
Gli ingegneri di turno hanno iniziato a ripristinare uno degli ultimi servizi alla versione precedente

22:40
Gli errori 5xx hanno smesso di apparire, la situazione si è stabilizzata

Tempo fino alla rilevazione: 4 min
Tempo fino all'azione: 21 min
Tempo fino alla correzione: 1 min

Informazioni aggiuntive

Log di 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' Ridotto il replica set coredns-6cbb6646c9 a 2

Collegamenti a Kibana (ritagliato), Grafana (ritagliato)
Dove Linux conntrack non è più amico tuo
Sottigliezze di kube-proxy: debug di un reset di connessione intermittente
Conntrack instabile e timeout di ricerca DNS

Per minimizzare l'uso della CPU, il nucleo Linux utilizza una cosa chiamata conntrack. In breve, è un'utilità che contiene un elenco di registrazioni NAT, che sono memorizzate in una tabella speciale. Quando il pacchetto successivo arriva dallo stesso pod allo stesso pod di prima, l'indirizzo IP finale non verrà ricalcolato, ma verrà preso dalla tabella conntrack.

Come funziona conntrack

Conclusioni

Questo è stato un esempio di uno dei nostri post mortem con alcuni collegamenti utili. In questo articolo ci concentriamo su informazioni che possono essere utili ad altre aziende. Ecco perché non temiamo di commettere errori e perché abbiamo reso pubblico uno dei nostri post mortem. Ecco alcuni altri post mortem pubblici interessanti: