🥇Problemi DNS di Kubernetes. Autopsia pubblica

Nota traduzione: Questa è la traduzione di un'autopsia pubblica dal blog di ingegneria dell'azienda PreplyDescrive un problema con conntrack in un cluster Kubernetes che ha causato tempi di inattività parziali per alcuni servizi di produzione.

Questo articolo può essere utile per chi vuole saperne di più sui postmortem o per prevenire potenziali problemi DNS in futuro.

Questo non è DNS
Non può essere che questo sia DNS
Era DNS

Un po' di informazioni sulle autopsie e sui processi in Preply

Un'analisi post-mortem descrive un guasto o un evento in produzione. Include una cronologia degli eventi, l'impatto sull'utente, la causa principale, le azioni intraprese e le lezioni apprese.
Cerco SRE

Durante le riunioni settimanali dedicate alla pizza, condividiamo informazioni con il team tecnico. Una delle parti più importanti di queste riunioni è l'autopsia, spesso accompagnata da una presentazione di slide e da un'analisi più approfondita dell'incidente verificatosi. Sebbene non applaudiamo dopo le autopsie, cerchiamo di sviluppare una cultura del "nessuna colpa" (comunità irreprensibile). Crediamo che scrivere e presentare autopsie possa aiutare noi (e altri) a prevenire incidenti simili in futuro, ed è per questo che le condividiamo.

Chi è coinvolto nell'incidente dovrebbe sentirsi libero di parlarne senza timore di punizioni o ritorsioni. Nessuna censura! Scrivere un'autopsia non è una punizione, ma un'opportunità di apprendimento per l'intera azienda.
Mantieni la CALMA e DevOps: S sta per condivisione

Problemi DNS in Kubernetes. Autopsia

Дата: 28.02.2020

Autori: Amet U., Andrey S., Igor K., Alexey P.

Titolo: Finito

brevemente: Indisponibilità DNS parziale (26 min) per alcuni servizi nel cluster Kubernetes

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

Causa ultima: 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] 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 basso carico all'interno del cluster Kubernetes, CoreDNS Autoscaler ha ridotto il numero di pod nella distribuzione 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 causato la riscrittura della tabella conntrack

Rilevamento: Il monitoraggio di 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

Disabilitare l'autoscaler per CoreDNS
impedito
Amet W.
DEVOPS-695

Imposta un server DNS di memorizzazione nella cache
diminuire
Massimo V.
DEVOPS-665

Imposta il monitoraggio conntrack
impedito
Amet W.
DEVOPS-674

Lezioni imparate

Cosa è andato bene:

Il monitoraggio ha funzionato bene. La risposta è stata rapida e organizzata.
Non abbiamo raggiunto alcun limite sui nodi

Cosa è andato storto:

La vera causa principale sembra essere ancora sconosciuta bug specifico in conntrack
Tutte le azioni correggono solo le conseguenze, non la causa principale (bug)
Sapevamo che prima o poi avremmo avuto problemi con il DNS, ma non abbiamo dato priorità a queste attività.

Dove siamo stati fortunati:

Un'altra distribuzione ha attivato CoreDNS-autoscaler, che ha riscritto la tabella conntrack
Questo bug ha interessato 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 in servizio hanno iniziato a ricevere chiamate dal sistema di monitoraggio

22:21
Gli ingegneri in servizio hanno iniziato a indagare sulla 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 apparire, la situazione si è stabilizzata

Tempo di rilevamento: minuti 4
Tempo fino all'azione: minuti 21
È ora di risolvere: 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)
Dove Linux conntrack is no longer your friend
Sottigliezze di kube-proxy: debug di un ripristino di connessione intermittente
Timeout di ricerca DNS e di conntrack rapidi

Для минимизации использования процессора, ядро Linux использует такую штуку как conntrack. Если кратко, то это утилита, которая содержит список NAT-записей, которые хранятся в специальной таблице. Когда следующий пакет приходит из того же пода в тот же под что и раньше, конечный IP-адрес не будет рассчитан заново, а будет взят из таблицы conntrack.

Come funziona conntrack?

Risultati di

Questo è un esempio di uno dei nostri postmortem, con alcuni link utili. In questo articolo specifico, condividiamo informazioni che potrebbero essere utili ad altre aziende. Ecco perché non abbiamo paura di commettere errori e abbiamo reso pubblico uno dei nostri postmortem. Ecco altri postmortem pubblici interessanti: