Opmerking. vertaling: Dit is een vertaling van een openbare autopsie van de technische blog van het bedrijf . Het beschrijft een probleem met conntrack in een Kubernetes-cluster, wat leidde tot gedeeltelijke downtime van sommige productiediensten.
Dit artikel kan nuttig zijn voor degenen die wat meer willen leren over postmortems of een aantal potentiële DNS-problemen in de toekomst willen voorkomen.
Dit is geen DNS
Het kan geen DNS zijn
Het was DNS
Iets over postmortems en processen in Preply
Een autopsie beschrijft een storing of een gebeurtenis in de productie. Het postmortem omvat een tijdlijn van gebeurtenissen, de impact van de gebruiker, de hoofdoorzaak, de ondernomen acties en de geleerde lessen.
Tijdens wekelijkse bijeenkomsten met pizza delen we binnen het technische team verschillende informatie. Een van de belangrijkste onderdelen van dergelijke bijeenkomsten zijn post-mortems, die meestal gepaard gaan met een presentatie met dia's en een diepgaandere analyse van het incident. Ook al klappen we niet na de autopsie, we proberen een cultuur te ontwikkelen van ‘geen schuld’ (). Wij geloven dat het schrijven en presenteren van postmortems ons (en anderen) kan helpen soortgelijke incidenten in de toekomst te voorkomen, en daarom delen we ze.
Individuen die betrokken zijn bij een incident moeten het gevoel hebben dat zij zich tot in detail kunnen uitspreken zonder angst voor straf of vergelding. Geen schuld! Het schrijven van een postmortem is geen straf, maar een leermoment voor het hele bedrijf.
Problemen met DNS in Kubernetes. Postmortaal
datum: 28.02.2020
Auteurs: Amet U., Andrey S., Igor K., Alexey P.
Toestand: Afgerond
in het kort: Gedeeltelijke DNS-onbeschikbaarheid (26 min.) voor sommige services in het Kubernetes-cluster
Invloed hebben: 15000 verloren evenementen voor services A, B en C
Oorzaak: Kube-proxy kon een oud item niet correct verwijderen uit de conntrack-tabel, dus sommige services probeerden nog steeds verbinding te maken met niet-bestaande 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: ...Trekker: Vanwege de lage belasting binnen het Kubernetes-cluster heeft CoreDNS-autoscaler het aantal pods in de implementatie teruggebracht van drie naar twee
oplossing: De volgende implementatie van de applicatie startte de creatie van nieuwe knooppunten, CoreDNS-autoscaler voegde meer pods toe om het cluster te bedienen, wat een herschrijving van de conntrack-tabel veroorzaakte
Detectie: Prometheus-monitoring ontdekte een groot aantal 5xx-fouten voor services A, B en C en startte een oproep naar de dienstdoende technici
5xx-fouten in Kibana
acties
effect
Type
Verantwoordelijk
Taak
Schakel autoscaler uit voor CoreDNS
verhinderd
Amet U.
DEVOPS-695
Zet een cache-DNS-server op
afname
Max V.
DEVOPS-665
Conntrack-monitoring instellen
verhinderd
Amet U.
DEVOPS-674
Les geleerd
Wat ging goed:
- De monitoring werkte goed. De respons was snel en georganiseerd
- We hebben geen limieten op de knooppunten bereikt
Wat was er mis:
- Nog steeds onbekende echte oorzaak, vergelijkbaar met in verbinding
- Alle acties corrigeren alleen de gevolgen, niet de hoofdoorzaak (bug)
- We wisten dat we vroeg of laat problemen zouden kunnen krijgen met DNS, maar we hebben geen prioriteit gegeven aan de taken
Waar we geluk hadden:
- De volgende implementatie werd geactiveerd door CoreDNS-autoscaler, die de conntrack-tabel overschreef
- Deze bug had slechts betrekking op enkele services
Tijdlijn (EET)
tijd
effect
22:13
CoreDNS-autoscaler heeft het aantal peulen teruggebracht van drie naar twee
22:18
Ingenieurs van dienst begonnen oproepen te ontvangen van het monitoringsysteem
22:21
De dienstdoende ingenieurs begonnen de oorzaak van de fouten te achterhalen.
22:39
Technici van dienst begonnen een van de nieuwste services terug te draaien naar de vorige versie
22:40
5xx-fouten verschenen niet meer, de situatie is gestabiliseerd
- Tijd tot detectie: 4 minuten
- Tijd vóór actie: 21 minuten
- Tijd om te repareren: 1 minuten
aanvullende informatie
- CoreDNS-logboeken:
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 naar Kibana (geknipt), Grafana (geknipt)
Om het CPU-gebruik te minimaliseren, gebruikt de Linux-kernel iets dat conntrack wordt genoemd. Kort gezegd is dit een hulpprogramma dat een lijst met NAT-records bevat die in een speciale tabel zijn opgeslagen. Wanneer het volgende pakket arriveert van dezelfde pod naar dezelfde pod als voorheen, wordt het uiteindelijke IP-adres niet opnieuw berekend, maar wordt het uit de conntrack-tabel gehaald.
Hoe Contrack werkt
Resultaten van
Dit was een voorbeeld van een van onze postmortems met enkele nuttige links. Specifiek in dit artikel delen we informatie die nuttig kan zijn voor andere bedrijven. Daarom zijn we niet bang om fouten te maken en daarom maken we een van onze postmortems openbaar. Hier zijn enkele interessantere openbare postmortems:
- GitLab:
- Dropbox:
- Spotify:
- Vele anderen van en repository
- Ook openbare autopsie met SRE Book
Bron: www.habr.com