jegyzet fordítás: Ez egy nyilvános postmortem fordítása a cég mérnöki blogjáról . Egy Kubernetes-fürtben a conntrack problémáját írja le, amely egyes termelési szolgáltatások részleges leállásához vezetett.
Ez a cikk hasznos lehet azok számára, akik szeretnének egy kicsit többet megtudni a postmortemekről, vagy szeretnének megelőzni néhány lehetséges DNS-problémát a jövőben.
Ez nem DNS
Nem lehet DNS
DNS volt
Egy kicsit a postmortemekről és a Preply folyamatairól
A postmortem egy meghibásodást vagy valamilyen gyártási eseményt ír le. A postmortem tartalmazza az események idővonalát, a felhasználói hatást, a kiváltó okot, a megtett intézkedéseket és a tanulságokat.
A pizzával való heti találkozókon a technikai csapat között különféle információkat osztunk meg. Az ilyen találkozók egyik legfontosabb része a post mortem, amelyet leggyakrabban diavetítéssel és az eset alaposabb elemzésével kísérnek. Annak ellenére, hogy nem tapsolunk az utókor után, megpróbáljuk kialakítani a „nem hibáztatható” kultúrát (). Hiszünk abban, hogy a postmortemek írása és bemutatása segíthet nekünk (és másoknak) megelőzni a hasonló eseményeket a jövőben, ezért megosztjuk azokat.
Az incidensben érintett személyeknek úgy kell érezniük, hogy részletesen meg tudnak beszélni anélkül, hogy félnének a büntetéstől vagy a megtorlástól. Nincs hibáztatás! A postmortem megírása nem büntetés, hanem tanulási lehetőség az egész társaság számára.
Problémák a DNS-sel a Kubernetesben. Halál utáni
időpontja: 28.02.2020
Szerzők: Amet U., Andrey S., Igor K., Alexey P.
Állapot: Befejezett
röviden: A DNS részleges elérhetetlensége (26 perc) a Kubernetes-fürt egyes szolgáltatásainál
Befolyás: 15000 XNUMX esemény elveszett az A, B és C szolgáltatásoknál
Kiváltó ok: A Kube-proxy nem tudott megfelelően eltávolítani egy régi bejegyzést a conntrack táblából, így néhány szolgáltatás még mindig nem létező podokhoz próbált csatlakozni
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: ...Trigger: A Kubernetes-fürtön belüli alacsony terhelés miatt a CoreDNS-autoscaler háromról kettőre csökkentette a telepítésben lévő podok számát.
megoldás: Az alkalmazás következő telepítése új csomópontok létrehozását kezdeményezte, a CoreDNS-autoscaler további podokat adott a fürt kiszolgálásához, ami a conntrack tábla átírását váltotta ki.
Érzékelés: A Prometheus felügyelet nagyszámú 5xx hibát észlelt az A, B és C szolgáltatásoknál, és felhívta az ügyeletes mérnököket
5xx hibák a Kibanában
Tevékenység
hatás
Type
Felelős
Feladat
Az automatikus méretezés letiltása a CoreDNS-hez
megakadályozta
Amet U.
DEVOPS-695
Gyorsítótárazó DNS-kiszolgáló beállítása
csökken
Max V.
DEVOPS-665
Conntrack monitorozás beállítása
megakadályozta
Amet U.
DEVOPS-674
Tanulságok
Ami jól esett:
- A megfigyelés jól működött. A válasz gyors és szervezett volt
- Nem értünk el semmilyen korlátot a csomópontokon
Mi volt a baj:
- Még mindig ismeretlen valódi kiváltó ok, hasonló a in conntrack
- Minden intézkedés csak a következményeket korrigálja, nem a kiváltó okot (hiba)
- Tudtuk, hogy előbb-utóbb gondok adódhatnak a DNS-sel, de nem rangsoroltuk a feladatokat
Ahol szerencsénk volt:
- A következő telepítést a CoreDNS-autoscaler indította el, amely felülírta a conntrack táblát
- Ez a hiba csak néhány szolgáltatást érintett
Idővonal (EET)
Idő
hatás
22:13
A CoreDNS-autoscaler háromról kettőre csökkentette a hüvelyek számát
22:18
Az ügyeletes mérnökök elkezdtek hívásokat fogadni a megfigyelőrendszertől
22:21
Az ügyeletes mérnökök elkezdték kideríteni a hibák okát.
22:39
Az ügyeletes mérnökök megkezdték az egyik legújabb szolgáltatás visszaállítását az előző verzióra
22:40
5xx hiba megszűnt, a helyzet stabilizálódott
- Az észlelés ideje: 4 perc
- A cselekvés előtti idő: 21 perc
- Ideje javítani: 1 perc
további információk
- CoreDNS naplók:
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 - Linkek a Kibana (vágott), Grafana (kivágás)
A CPU-használat minimalizálása érdekében a Linux kernel valami úgynevezett conntrack-et használ. Röviden, ez egy olyan segédprogram, amely egy speciális táblában tárolt NAT rekordok listáját tartalmazza. Amikor a következő csomag ugyanabból a podból ugyanabba a podba érkezik, mint korábban, a végső IP-címet nem számítják újra, hanem a conntrack táblából veszik.
Hogyan működik a conntrack
Eredményei
Ez egy példa volt az egyik poszthalálunkra, néhány hasznos linkkel. Ebben a cikkben olyan információkat osztunk meg, amelyek hasznosak lehetnek más vállalatok számára. Ezért nem félünk hibázni, és ezért tesszük nyilvánossá az egyik postmortemünket. Íme néhány érdekesebb nyilvános postmortem:
- GitLab:
- Dropbox:
- Spotify:
- Sokan másoktól és tárház
- Is nyilvános postmortem az SRE könyvvel
Forrás: will.com