Merk oversettelse: Dette er en oversettelse av en offentlig postmortem fra selskapets ingeniørblogg . Den beskriver et problem med conntrack i en Kubernetes-klynge, som førte til delvis nedetid for enkelte produksjonstjenester.
Denne artikkelen kan være nyttig for de som ønsker å lære litt mer om postmortem eller forhindre noen potensielle DNS-problemer i fremtiden.
Dette er ikke DNS
Det kan ikke være DNS
Det var DNS
Litt om postmortem og prosesser i Preply
En postmortem beskriver en funksjonsfeil eller en hendelse i produksjonen. Postmortem inkluderer en tidslinje med hendelser, brukerpåvirkning, rotårsak, handlinger som er utført og lærdom.
På ukentlige møter med pizza, blant teknisk team, deler vi forskjellig informasjon. En av de viktigste delene av slike møter er obduksjoner, som oftest ledsages av en presentasjon med lysbilder og en mer dyptgående analyse av hendelsen. Selv om vi ikke klapper etter obduksjon, prøver vi å utvikle en kultur med "ingen skyld" (). Vi tror at å skrive og presentere postmortem kan hjelpe oss (og andre) med å forhindre lignende hendelser i fremtiden, og det er derfor vi deler dem.
Personer som er involvert i en hendelse bør føle at de kan si fra i detalj uten frykt for straff eller gjengjeldelse. Ingen skyld! Å skrive postmortem er ikke en straff, men en læringsmulighet for hele selskapet.
Problemer med DNS i Kubernetes. Etter døden
Дата: 28.02.2020
Forfattere: Amet U., Andrey S., Igor K., Alexey P.
Status: Ferdig
kort: Delvis DNS utilgjengelighet (26 min) for enkelte tjenester i Kubernetes-klyngen
Innvirkning: 15000 XNUMX hendelser tapt for tjenestene A, B og C
Opprinnelig årsak: Kube-proxy kunne ikke fjerne en gammel oppføring fra conntrack-tabellen på riktig måte, så noen tjenester prøvde fortsatt å koble 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: ...Avtrekker: På grunn av den lave belastningen inne i Kubernetes-klyngen, reduserte CoreDNS-autoscaler antallet pods i utplasseringen fra tre til to
løsning: Den neste distribusjonen av applikasjonen startet opprettelsen av nye noder, CoreDNS-autoscaler la til flere pods for å betjene klyngen, noe som provoserte en omskriving av conntrack-tabellen
Gjenkjenning: Prometheus-overvåking oppdaget et stort antall 5xx-feil for tjenestene A, B og C og startet en samtale til vakthavende ingeniører
5xx feil i Kibana
Aktivitet
effekt
Type
Ansvarlig
Oppgave
Deaktiver autoscaler for CoreDNS
forhindret
Amet U.
DEVOPS-695
Sett opp en caching DNS-server
avta
Max V.
DEVOPS-665
Sett opp tilkoblingsovervåking
forhindret
Amet U.
DEVOPS-674
Lærdom
Hva gikk bra:
- Overvåkingen fungerte bra. Responsen var rask og organisert
- Vi traff ingen grenser for nodene
Hva var galt:
- Fortsatt ukjent reell grunnårsak, lik i forbindelse
- Alle handlinger korrigerer bare konsekvensene, ikke rotårsaken (feil)
- Vi visste at vi før eller siden kunne få problemer med DNS, men vi prioriterte ikke oppgavene
Hvor vi var heldige:
- Den neste distribusjonen ble utløst av CoreDNS-autoscaler, som overskrev conntrack-tabellen
- Denne feilen påvirket bare noen tjenester
Tidslinje (EET)
tid
effekt
22:13
CoreDNS-autoscaler reduserte antall pods fra tre til to
22:18
Ingeniører på vakt begynte å motta anrop fra overvåkingssystemet
22:21
Vakthavende ingeniører begynte å finne ut årsaken til feilene.
22:39
Ingeniører på vakt begynte å rulle tilbake en av de nyeste tjenestene til den forrige versjonen
22:40
5xx-feil sluttet å vises, situasjonen har stabilisert seg
- Tid til deteksjon: 4 minutter
- Tid før handling: 21 minutter
- På tide å fikse: 1 minutter
mer informasjon
- CoreDNS-logger:
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 - Lenker til Kibana (cut), Grafana (cut)
For å minimere CPU-bruken bruker Linux-kjernen noe som heter conntrack. Kort fortalt er dette et verktøy som inneholder en liste over NAT-poster som er lagret i en spesiell tabell. Når neste pakke kommer fra samme pod til samme pod som før, vil den endelige IP-adressen ikke bli beregnet på nytt, men hentet fra conntrack-tabellen.
Hvordan tilkobling fungerer
Resultater av
Dette var et eksempel på en av våre postmortems med noen nyttige linker. Spesielt i denne artikkelen deler vi informasjon som kan være nyttig for andre selskaper. Det er derfor vi ikke er redde for å gjøre feil, og det er derfor vi offentliggjør en av våre postmortems. Her er noen mer interessante offentlige postmortems:
- GitLab:
- Dropbox:
- Spotify:
- Mange andre fra og depot
- også offentlig postmortem med SRE Book
Kilde: www.habr.com