Notera översättning: Detta är en översättning av en offentlig postmortem från företagets ingenjörsblogg . Den beskriver ett problem med conntrack i ett Kubernetes-kluster, vilket ledde till delvis stillestånd för vissa produktionstjänster.
Den här artikeln kan vara användbar för dem som vill lära sig lite mer om obduktion eller förhindra vissa potentiella DNS-problem i framtiden.
Detta är inte DNS
Det kan inte vara DNS
Det var DNS
Lite om obduktioner och processer i Preply
En obduktion beskriver ett fel eller någon händelse i produktionen. Obduktionen inkluderar en tidslinje med händelser, användarpåverkan, grundorsaken, vidtagna åtgärder och lärdomar.
Vid veckomöten med pizza, bland tekniska teamet, delar vi olika information. En av de viktigaste delarna av sådana möten är obduktioner, som oftast åtföljs av en presentation med diabilder och en mer djupgående analys av händelsen. Även om vi inte klappar efter obduktioner, försöker vi utveckla en kultur av "ingen skuld" (). Vi tror att att skriva och presentera obduktioner kan hjälpa oss (och andra) att förhindra liknande incidenter i framtiden, och det är därför vi delar dem.
Individer som är inblandade i en incident ska känna att de kan tala ut i detalj utan rädsla för straff eller vedergällning. Ingen skuld! Att skriva en obduktion är inte ett straff, utan ett läromedel för hela företaget.
Problem med DNS i Kubernetes. Obduktion
Datum: 28.02.2020
Författare: Amet U., Andrey S., Igor K., Alexey P.
Status: Färdiga
kort: Partiell DNS otillgänglighet (26 min) för vissa tjänster i Kubernetes-klustret
Inflytande: 15000 XNUMX evenemang förlorade för tjänsterna A, B och C
Grundorsak: Kube-proxy kunde inte korrekt ta bort en gammal post från conntrack-tabellen, så vissa tjänster försökte fortfarande ansluta till icke-existerande pods
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: ...Utlösare: På grund av den låga belastningen inuti Kubernetes-klustret, minskade CoreDNS-autoscaler antalet pods i distributionen från tre till två
lösning: Nästa implementering av applikationen initierade skapandet av nya noder, CoreDNS-autoscaler la till fler pods för att tjäna klustret, vilket provocerade fram en omskrivning av conntrack-tabellen
Upptäckt: Prometheus-övervakning upptäckte ett stort antal 5xx-fel för tjänster A, B och C och initierade ett samtal till de jourhavande ingenjörerna
5xx-fel i Kibana
Aktivitet
effekt
Typ
Ansvarig
Uppgift
Inaktivera autoscaler för CoreDNS
förhindras
Amet U.
DEVOPS-695
Konfigurera en cachande DNS-server
minska
Max V.
DEVOPS-665
Konfigurera övervakning av förbindelser
förhindras
Amet U.
DEVOPS-674
Lärdomar
Vad gick bra:
- Övervakningen fungerade bra. Responsen var snabb och organiserad
- Vi träffade inga gränser för noderna
Vad var fel:
- Fortfarande okänd verklig grundorsak, liknande i förbindelse
- Alla åtgärder korrigerar endast konsekvenserna, inte grundorsaken (bugg)
- Vi visste att vi förr eller senare kunde få problem med DNS, men vi prioriterade inte uppgifterna
Där vi hade tur:
- Nästa distribution utlöstes av CoreDNS-autoscaler, som skrev över conntrack-tabellen
- Denna bugg påverkade endast vissa tjänster
Tidslinje (EET)
Tid
effekt
22:13
CoreDNS-autoscaler minskade antalet pods från tre till två
22:18
Ingenjörer i tjänst började ta emot samtal från övervakningssystemet
22:21
Jourhavande ingenjörer började ta reda på orsaken till felen.
22:39
Ingenjörer i tjänst började återställa en av de senaste tjänsterna till den tidigare versionen
22:40
5xx-fel slutade visas, situationen har stabiliserats
- Tid till upptäckt: 4 minuter
- Tid före åtgärd: 21 minuter
- Dags att fixa: 1 minuter
ytterligare information
- CoreDNS-loggar:
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 - Länkar till Kibana (cut), Grafana (cut)
För att minimera CPU-användningen använder Linux-kärnan något som kallas conntrack. Kort sagt, detta är ett verktyg som innehåller en lista över NAT-poster som lagras i en speciell tabell. När nästa paket kommer från samma pod till samma pod som tidigare, kommer den slutliga IP-adressen inte att räknas om, utan tas från conntrack-tabellen.
Hur conntrack fungerar
Resultat av
Det här var ett exempel på en av våra obduktioner med några användbara länkar. Specifikt i den här artikeln delar vi information som kan vara användbar för andra företag. Det är därför vi inte är rädda för att göra misstag och det är därför vi offentliggör en av våra obduktioner. Här är några mer intressanta offentliga obduktioner:
- GitLab:
- Dropbox:
- Spotify:
- Många andra från och förvar
- också offentlig obduktion med SRE Book
Källa: will.com