{"id":80532,"date":"2020-05-07T01:42:17","date_gmt":"2020-05-06T23:42:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem"},"modified":"2020-05-07T01:42:17","modified_gmt":"2020-05-06T23:42:17","slug":"problemy-s-dns-v-kubernetes-publichnyj-postmortem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/problemy-s-dns-v-kubernetes-publichnyj-postmortem","title":{"rendered":"Problemi di DNS in Kubernetes. Post mortem pubblico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota di traduzione:<\/b> \u00e8 una traduzione di un post mortem pubblico dal blog ingegneristico dell'azienda Preply<\/a><\/noindex>. Descrive un problema con conntrack in un cluster Kubernetes, che ha portato a un parziale downtime di alcuni servizi di produzione.<\/i><\/p>\n

Questo articolo pu\u00f2 essere utile per chi desidera saperne di pi\u00f9 sui post mortem o prevenire potenziali problemi con DNS in futuro.<\/p>\n

\"Problemi
\nNon \u00e8 DNS
\nNon pu\u00f2 essere che sia DNS
\nEra DNS<\/i>
\n<\/a><\/noindex><\/p>\n

Un po' sui post mortem e i processi in Preply<\/h2>\n

<\/p>\n

Il post mortem descrive un guasto o un evento in produzione. Include una cronologia degli eventi, una descrizione dell'impatto sugli utenti, la causa principale, le azioni intraprese e le lezioni apprese.<\/p>\n

Seeking SRE<\/a><\/noindex><\/i><\/p><\/blockquote>\n

\nDurante le riunioni settimanali con la pizza, nel nostro team tecnico, condividiamo diverse informazioni. Una delle parti pi\u00f9 importanti di queste riunioni \u00e8 rappresentata dai post mortem, che sono spesso accompagnati da presentazioni con diapositive e un'analisi pi\u00f9 approfondita dell'incidente accaduto. Anche se non \"applaudiamo\" dopo i post mortem, cerchiamo di promuovere una cultura \"senza colpe\" (cultura senza colpe<\/a><\/noindex>). Crediamo che la scrittura e la presentazione dei post-mortem possano aiutarci (e non solo) a prevenire incidenti simili in futuro, ed \u00e8 proprio per questo che li condividiamo.<\/p>\n

Le persone coinvolte nell'incidente devono sentirsi a loro agio nel raccontare i dettagli senza temere punizioni o ritorsioni. Niente biasimo! Scrivere un post-mortem non \u00e8 una punizione, ma un'opportunit\u00e0 di apprendimento per tutta l'azienda.<\/p>\n

Keep CALMS & DevOps: S stands for Sharing<\/a><\/noindex><\/i><\/p><\/blockquote>\n

<\/p>\n

Problemi DNS in Kubernetes. Post-mortem<\/h2>\n

\nData:<\/b> 28.02.2020<\/p>\n

Autori:<\/b> Amet U., Andrey S., Igor K., Alexey P.<\/p>\n

Stato:<\/b> Completato<\/p>\n

In breve:<\/b> Parziale inattivit\u00e0 DNS (26 min) per alcuni servizi nel cluster Kubernetes<\/p>\n

Impatto:<\/b> 15000 eventi persi per i servizi A, B e C<\/p>\n

Causa principale:<\/b> Kube-proxy non \u00e8 riuscito a rimuovere correttamente la vecchia voce dalla tabella conntrack, quindi alcuni servizi continuavano a provare a connettersi a pod inesistenti<\/p>\n

E0228 20:13:53.795782       1 proxier.go:610] Impossibile eliminare le connessioni degli endpoint kube-system\/kube-dns:dns, errore: errore nell'eliminazione delle voci conntrack per il peer UDP {100.64.0.10, 100.110.33.231}, errore: comando conntrack restiutito: ...<\/code><\/pre>\n
\nTrigger:<\/b> A causa del carico ridotto nel cluster Kubernetes, il CoreDNS-autoscaler ha ridotto il numero di pod nel deployment da tre a due<\/p>\n
Soluzione:<\/b> Un altro deployment dell'applicazione ha innescato la creazione di nuovi nodi, il CoreDNS-autoscaler ha aggiunto pi\u00f9 pod per gestire il cluster, provocando la riscrittura della tabella conntrack<\/p>\n
Rilevamento:<\/b> Il monitoraggio di Prometheus ha rilevato un elevato numero di errori 5xx per i servizi A, B e C e ha attivato una chiamata agli ingegneri di guardia<\/p>\n
\"Problemi
\nErrori 5xx in Kibana<\/i><\/p>\n
Azioni<\/h3>\n
<\/p>\n
Azione
\nTipo
\nResponsabile
\nCompito<\/p>\n
Disabilitare l'autoscaler per CoreDNS
\nprevenire
\nAmet U.
\nDEVOPS-695<\/p>\n
Installare un server DNS cache
\nridurre
\nMax V.
\nDEVOPS-665<\/p>\n
Configurare il monitoraggio conntrack
\nprevenire
\nAmet U.
\nDEVOPS-674<\/p>\n
<\/p>\n
Lezioni apprese<\/h3>\n
\nCosa \u00e8 andato bene:<\/b><\/p>\n