Bemærk. oversættelse: Dette er en oversættelse af en offentlig postmortem fra virksomhedens ingeniørblog . Den beskriver et problem med conntrack i en Kubernetes-klynge, som førte til delvis nedetid for nogle produktionstjenester.
Denne artikel kan være nyttig for dem, der ønsker at lære lidt mere om postmortems eller forhindre nogle potentielle DNS-problemer i fremtiden.
Dette er ikke DNS
Det kan ikke være DNS
Det var DNS
Lidt om obduktion og processer i Preply
En postmortem beskriver en funktionsfejl eller en hændelse i produktionen. Postmortem inkluderer en tidslinje over hændelser, brugerpåvirkning, grundlæggende årsag, truffet handlinger og erfaringer.
Ved ugentlige møder med pizza, blandt det tekniske team, deler vi forskellige informationer. En af de vigtigste dele af sådanne møder er obduktioner, som oftest ledsages af en præsentation med slides og en mere dybdegående analyse af hændelsen. Selvom vi ikke klapper efter obduktioner, forsøger vi at udvikle en kultur med "ingen skyld" (). Vi tror på, at skrivning og præsentation af obduktioner kan hjælpe os (og andre) med at forhindre lignende hændelser i fremtiden, og det er derfor, vi deler dem.
Personer involveret i en hændelse bør føle, at de kan udtale sig i detaljer uden frygt for straf eller gengældelse. Ingen skyld! At skrive en obduktion er ikke en straf, men en læringsmulighed for hele virksomheden.
Problemer med DNS i Kubernetes. Efter døden
Dato: 28.02.2020
Forfattere: Amet U., Andrey S., Igor K., Alexey P.
Status: Færdig
kort: Delvis DNS utilgængelighed (26 min) for nogle tjenester i Kubernetes-klyngen
Indvirkning: 15000 begivenheder tabt for tjenester A, B og C
Hovedårsagen: Kube-proxy var ikke i stand til korrekt at fjerne en gammel post fra conntrack-tabellen, så nogle tjenester forsøgte stadig at oprette forbindelse til ikke-eksisterende 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: ...Udløser: På grund af den lave belastning inde i Kubernetes-klyngen reducerede CoreDNS-autoscaler antallet af pods i udrulningen fra tre til to
opløsning: Den næste implementering af applikationen igangsatte oprettelsen af nye noder, CoreDNS-autoscaler tilføjede flere pods til at betjene klyngen, hvilket provokerede en omskrivning af conntrack-tabellen
Opdagelse: Prometheus-overvågning opdagede et stort antal 5xx-fejl for tjenester A, B og C og indledte et opkald til de vagthavende ingeniører
5xx fejl i Kibana
Aktivitet
effekt
Type
Ansvarlig
Opgave
Deaktiver autoscaler for CoreDNS
forhindret
Amet U.
DEVOPS-695
Konfigurer en caching DNS-server
formindske
Max V.
DEVOPS-665
Konfigurer forbindelsesovervågning
forhindret
Amet U.
DEVOPS-674
Erfaringer
Hvad gik godt:
- Overvågningen fungerede godt. Svaret var hurtigt og organiseret
- Vi ramte ingen grænser for noderne
Hvad var der galt:
- Stadig ukendt reel grundårsag, svarende til i forbindelse
- Alle handlinger retter kun konsekvenserne, ikke hovedårsagen (fejl)
- Vi vidste, at vi før eller siden kunne få problemer med DNS, men vi prioriterede ikke opgaverne
Hvor vi var heldige:
- Den næste implementering blev udløst af CoreDNS-autoscaler, som overskrev conntrack-tabellen
- Denne fejl påvirkede kun nogle tjenester
Tidslinje (EET)
Time
effekt
22:13
CoreDNS-autoscaler reducerede antallet af pods fra tre til to
22:18
Ingeniører på vagt begyndte at modtage opkald fra overvågningssystemet
22:21
De vagthavende ingeniører begyndte at finde ud af årsagen til fejlene.
22:39
Ingeniører på vagt begyndte at rulle en af de nyeste tjenester tilbage til den tidligere version
22:40
5xx fejl holdt op med at vises, situationen er stabiliseret
- Tid til detektion: 4 minutter
- Tid før handling: 21 minutter
- Tid til at rette: 1 minutter
yderligere oplysninger
- CoreDNS-logfiler:
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 til Kibana (cut), Grafana (cut)
For at minimere CPU-brug bruger Linux-kernen noget, der hedder conntrack. Kort sagt er dette et hjælpeprogram, der indeholder en liste over NAT-poster, der er gemt i en speciel tabel. Når den næste pakke ankommer fra den samme pod til den samme pod som før, bliver den endelige IP-adresse ikke genberegnet, men taget fra conntrack-tabellen.
Sådan fungerer forbindelsen
Resultaterne af
Dette var et eksempel på en af vores postmortems med nogle nyttige links. Specifikt i denne artikel deler vi oplysninger, der kan være nyttige for andre virksomheder. Det er derfor, vi ikke er bange for at begå fejl, og det er derfor, vi offentliggør en af vores postmortems. Her er nogle mere interessante offentlige postmortems:
- GitLab:
- Dropbox:
- Spotify:
- Mange andre fra og depot
- Også offentlig postmortem med SRE Book
Kilde: www.habr.com