Note Iwwersetzung: Dëst ass eng Iwwersetzung vun engem ëffentleche Postmortem vum Ingenieursblog vun der Firma . Et beschreift e Problem mat Conntrack an engem Kubernetes Cluster, deen zu deelweis Ausbroch vun e puer Produktiounsservicer gefouert huet.
Dësen Artikel kann nëtzlech sinn fir déi, déi e bësse méi iwwer Postmortems léiere wëllen oder e puer potenziell DNS Probleemer an der Zukunft verhënneren.
Dëst ass net DNS
Et kann net DNS sinn
Et war DNS
E bëssen iwwer Postmortems a Prozesser am Preply
E Postmortem beschreift eng Feelfunktioun oder en Event an der Produktioun. De Postmortem enthält eng Timeline vun Eventer, Beschreiwung vum Benotzer Impakt, root Ursaach, geholl Aktiounen a Lektioune geléiert.
Op wëchentlechen Treffen mat Pizza, ënnert der technescher Equipe, deele mir verschidden Informatiounen. Ee vun de wichtegsten Deeler vun esou Reuniounen ass d'Post-Mortems, déi meeschtens vun enger Presentatioun mat Rutschen an enger méi déif Analyse vum Tëschefall begleet ginn. Och wa mir no Postmortem net klappen, probéieren mir eng Kultur vun "keng Schold" z'entwéckelen (). Mir gleewen datt d'Schreiwen an d'Presentatioun vun Postmortem eis (an anerer) hëllefe kënnen ähnlech Tëschefäll an Zukunft ze verhënneren, dofir deele mir se.
Eenzelpersounen, déi an engem Tëschefall involvéiert sinn, sollten d'Gefill hunn, datt se am Detail kënne schwätzen ouni Angscht viru Strof oder Retribution. Keng Schold! Eng Postmortem schreiwen ass keng Strof, mee eng Léierméiglechkeet fir déi ganz Firma.
Problemer mat DNS zu Kubernetes. Postmortem
Datum: 28.02.2020
D'Auteuren: Amet U., Andrey S., Igor K., Alexey P.
Status: Fäerdeg
Kuerz: Deelweis DNS Onverfügbarkeet (26 min) fir e puer Servicer am Kubernetes Cluster
Afloss: 15000 Evenementer verluer fir Servicer A, B an C
root Ursaach: Kube-Proxy konnt net en alen Entrée aus der Conntrack Tabelle richteg ewechhuelen, sou datt e puer Servicer nach ëmmer probéiert hunn mat net existente Pods ze verbannen
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: ...Ausléiser: Wéinst der gerénger Belaaschtung am Kubernetes Cluster huet CoreDNS-Autoscaler d'Zuel vun de Pods an der Deployment vun dräi op zwee reduzéiert
Léisung: Déi nächst Deployment vun der Applikatioun huet d'Schafung vun neie Wirbelen initiéiert, CoreDNS-autoscaler huet méi Pods bäigefüügt fir de Cluster ze déngen, wat e Rewrite vun der Conntrack Tabell provozéiert huet
Detektioun: Prometheus Iwwerwachung huet eng grouss Zuel vu 5xx Fehler fir Servicer A, B a C entdeckt an en Uruff un d'Ingenieuren initiéiert
5xx Feeler an Kibana
Actions
Effet
Typ
Responsabel
Objective
Autoscaler fir CoreDNS auszeschalten
verhënnert
Amt U.
DEVOPS-695
Setzt en Cache-DNS-Server op
erofgoen
Max V.
DEVOPS-665
Conntrack Iwwerwaachung opsetzen
verhënnert
Amt U.
DEVOPS-674
Lektioune geléiert
Wat gutt gaang ass:
- D'Iwwerwaachung huet gutt geschafft. D'Äntwert war séier an organiséiert
- Mir hu keng Limiten op den Noden getraff
Wat war falsch:
- Nach onbekannt richteg root Ursaach, ähnlech ze am Zesummenhang
- All Aktiounen korrigéieren nëmmen d'Konsequenzen, net d'Wuerzelursaach (Käfer)
- Mir woussten datt mir fréier oder spéider Probleemer mat DNS hunn, awer mir hunn d'Aufgaben net prioritär gemaach
Wou mir Gléck haten:
- Déi nächst Deployment gouf vum CoreDNS-autoscaler ausgeléist, deen d'Conntrack Tabelle iwwerschriwwen huet
- Dëse Feeler huet nëmmen e puer Servicer beaflosst
Timeline (EET)
Время
Effet
22:13
CoreDNS-Autoscaler huet d'Zuel vun de Pods vun dräi op zwee reduzéiert
22:18
D'Ingenieuren op Flicht hunn ugefaang Uriff aus dem Iwwerwaachungssystem ze kréien
22:21
D'Ingenieuren am Flicht hunn ugefaang d'Ursaach vun de Feeler erauszefannen.
22:39
D'Ingenieuren op Flicht hunn ugefaang ee vun de leschte Servicer op déi viregt Versioun zréckzekréien
22:40
5xx Feeler hunn opgehalen ze schéngen, d'Situatioun ass stabiliséiert
- Zäit fir z'erkennen: 4 min
- Zäit virun der Aktioun: 21 min
- Zäit fir ze fixéieren: 1 min
zousätzlech Informatioune
- CoreDNS Logbicher:
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 - Links zu Kibana (Schnëtt), Grafana (Schnëtt)
Fir d'CPU Benotzung ze minimiséieren, benotzt de Linux Kernel eppes genannt conntrack. Kuerz gesot, dëst ass en Utility deen eng Lëscht vun NAT records enthält déi an enger spezieller Tabelle gespäichert sinn. Wann de nächste Paket vum selwechte Pod an dee selwechte Pod ukomm ass wéi virdrun, gëtt déi lescht IP Adress net nei berechent, awer aus der Conntrack Tabelle geholl.
Wéi funktionéiert Conntrack
Resultater
Dëst war e Beispill vun engem vun eise Postmortems mat e puer nëtzlech Linken. Spezifesch an dësem Artikel deele mir Informatioun déi fir aner Firmen nëtzlech ka sinn. Dofir fäerten mir net Feeler ze maachen an dofir maachen mir eng vun eise Postmortems ëffentlech. Hei sinn e puer méi interessant ëffentlech Postmortems:
- GitLab:
- Dropbox:
- Spotify:
- Vill anerer aus an Repository
- Och ëffentlechen postmortem mat SRE Buch
Source: will.com