Nota traduzione: Questa è la traduzione di un'autopsia pubblica dal blog tecnico dell'azienda . Descrive un problema con conntrack in un cluster Kubernetes, che ha portato a tempi di inattività parziali di alcuni servizi di produzione.
Questo articolo può essere utile per coloro che desiderano saperne di più sulle autopsie o prevenire alcuni potenziali problemi DNS in futuro.
Questo non è DNS
Non può essere DNS
Era DNS
Un po' di autopsie e processi in Preply
Un'autopsia descrive un malfunzionamento o qualche evento nella produzione. L'autopsia include una sequenza temporale di eventi, impatto sugli utenti, causa principale, azioni intraprese e lezioni apprese.
Negli incontri settimanali con la pizza, all'interno del team tecnico, condividiamo varie informazioni. Una delle parti più importanti di tali incontri sono le autopsie, che molto spesso sono accompagnate da una presentazione con diapositive e da un'analisi più approfondita dell'incidente. Anche se non applaudiamo dopo l'autopsia, cerchiamo di sviluppare una cultura di "nessuna colpa" (). Crediamo che scrivere e presentare autopsie possa aiutare noi (e altri) a prevenire incidenti simili in futuro, motivo per cui li condividiamo.
Le persone coinvolte in un incidente dovrebbero sentire di poter parlare dettagliatamente senza timore di punizioni o ritorsioni. Nessuna colpa! Scrivere un'autopsia non è una punizione, ma un'opportunità di apprendimento per l'intera azienda.
Problemi con DNS in Kubernetes. Post-mortem
Дата: 28.02.2020
Autori: Amet U., Andrey S., Igor K., Alexey P.
Titolo: Finito
brevemente: Indisponibilità DNS parziale (26 minuti) per alcuni servizi nel cluster Kubernetes
Influenza: 15000 eventi persi per i servizi A, B e C
Causa ultima: Kube-proxy non è stato in grado di rimuovere correttamente una vecchia voce dalla tabella conntrack, quindi alcuni servizi stavano ancora tentando di connettersi a pod inesistenti
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: ...Grilletto: A causa del carico ridotto all'interno del cluster Kubernetes, l'autoscaler CoreDNS ha ridotto il numero di pod nella distribuzione da tre a due
soluzione: La successiva distribuzione dell'applicazione ha avviato la creazione di nuovi nodi, CoreDNS-autoscaler ha aggiunto più pod per servire il cluster, il che ha provocato una riscrittura della tabella conntrack
Rilevamento: Il monitoraggio Prometheus ha rilevato un gran numero di errori 5xx per i servizi A, B e C e ha avviato una chiamata ai tecnici in servizio
Errori 5xx in Kibana
Attività
Azione
tipo
Responsabile
Compito
Disabilita il ridimensionamento automatico per CoreDNS
prevenuto
Amet U.
DEVOPS-695
Configura un server DNS di memorizzazione nella cache
diminuire
Massimo V.
DEVOPS-665
Configura il monitoraggio del collegamento
prevenuto
Amet U.
DEVOPS-674
Lezioni imparate
Cosa è andato bene:
- Il monitoraggio ha funzionato bene. La risposta è stata veloce e organizzata
- Non abbiamo raggiunto alcun limite sui nodi
Cosa era sbagliato:
- La vera causa principale è ancora sconosciuta, simile a in collegamento
- Tutte le azioni correggono solo le conseguenze, non la causa principale (bug)
- Sapevamo che prima o poi avremmo potuto avere problemi con i DNS, ma non abbiamo dato priorità ai compiti
Dove abbiamo avuto fortuna:
- La distribuzione successiva è stata attivata da CoreDNS-autoscaler, che ha sovrascritto la tabella conntrack
- Questo bug ha interessato solo alcuni servizi
Cronologia (EET)
Tempo
Azione
22:13
Il ridimensionamento automatico CoreDNS ha ridotto il numero di pod da tre a due
22:18
Gli ingegneri in servizio iniziarono a ricevere chiamate dal sistema di monitoraggio
22:21
Gli ingegneri in servizio hanno iniziato a scoprire la causa degli errori.
22:39
Gli ingegneri in servizio hanno iniziato a ripristinare uno degli ultimi servizi alla versione precedente
22:40
Gli errori 5xx hanno smesso di comparire, la situazione si è stabilizzata
- Tempo per il rilevamento: minuti 4
- Tempo prima dell'azione: minuti 21
- È ora di sistemare: minuti 1
ulteriori informazioni
- Registri 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 - Link a Kibana (tagliato), Grafana (tagliato)
Per ridurre al minimo l'utilizzo della CPU, il kernel Linux utilizza qualcosa chiamato conntrack. In breve, si tratta di un'utilità che contiene un elenco di record NAT archiviati in una tabella speciale. Quando il pacchetto successivo arriverà dallo stesso pod allo stesso pod di prima, l'indirizzo IP finale non verrà ricalcolato, ma verrà preso dalla tabella conntrack.
Come funziona Conntrack
Risultati di
Questo era un esempio di una delle nostre autopsie con alcuni collegamenti utili. Nello specifico in questo articolo condividiamo informazioni che potrebbero essere utili ad altre aziende. Ecco perché non abbiamo paura di commettere errori ed è per questo che rendiamo pubblica una delle nostre autopsie. Ecco alcune autopsie pubbliche più interessanti:
- GitLab:
- Dropbox:
- Spotify:
- Molti altri da e deposito
- anche autopsia pubblica con SRE Book
Fonte: habr.com