DNS arazoak Kubernetes-en. Postmortem publikoa

Ohar itzulpena: Hau konpainiaren ingeniaritza blogaren postmortem publiko baten itzulpena da Aurrez. Kubernetes kluster batean conntrack-ekin arazo bat deskribatzen du, eta horrek ekoizpen zerbitzu batzuen geldialdi partziala eragin zuen.

Artikulu hau erabilgarria izan daiteke postmortems buruz apur bat gehiago ikasi nahi dutenentzat edo etorkizunean DNS arazo potentzial batzuk saihestu nahi dituztenentzat.

Hau ez da DNS
Ezin da DNS izan
DNS zen

Preply-ko autopsia eta prozesuei buruzko apur bat

Postmortem batek matxura bat edo ekoizpeneko gertaeraren bat deskribatzen du. Postmortem-ak gertaeren kronograma, erabiltzailearen eragina, arrazoi nagusia, egindako ekintzak eta ikasitako ikasgaiak biltzen ditu.

SRE bila

Pizzarekin asteko bileretan, talde teknikoaren artean, hainbat informazio partekatzen dugu. Bileren atal garrantzitsuenetako bat autopsiak dira, gehienetan diapositibekin aurkezpenarekin eta gertakariaren azterketa sakonagoarekin batera. Autopsiak egin ondoren txalorik egiten ez badugu ere, "errua ez" kultura garatzen saiatzen gara (kulparik gabeko kultura). Uste dugu autopsiak idazteak eta aurkezteak guri (eta besteei) etorkizunean antzeko gertakariak ekiditen lagundu diezaiekegula, horregatik partekatzen ari gara.

Gertakari batean parte hartzen duten pertsonek zehatz-mehatz hitz egin dezaketela sentitu beharko lukete, zigorrik edo ordainaren beldurrik gabe. Errurik ez! Postmortem bat idaztea ez da zigor bat, enpresa osoarentzat ikasteko aukera bat baizik.

Mantendu CALMS & DevOps: S partekatzeko da

DNS arazoak Kubernetes-en. Mortem ostekoa

data: 28.02.2020

Egileak: Amet U., Andrey S., Igor K., Alexey P.

Egoera: Bukatuta

laburki: DNS partziala erabilgarri eza (26 min) Kubernetes klusterreko zerbitzu batzuentzat

Eragina: 15000 ekitaldi galdu dira A, B eta C zerbitzuetarako

Arrazoi nagusia: Kube-proxy-k ezin izan du sarrera zahar bat behar bezala kendu conntrack taulatik, beraz, zerbitzu batzuk existitzen ez ziren podsetara konektatzen saiatzen ari ziren oraindik.

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: Kubernetes klusterraren barruan dagoen karga baxua dela eta, CoreDNS-autoscaler-ek inplementazioaren lekaren kopurua hirutik bira murriztu zuen.

irtenbidea: Aplikazioaren hurrengo inplementazioak nodo berriak sortzeari ekin zion, CoreDNS-autoscaler-ek pod gehiago gehitu zituen clusterra zerbitzatzeko, eta horrek conntrack taularen berridazketa eragin zuen.

Detekzioa: Prometheus-en monitorizazioak 5xx akats ugari detektatu zituen A, B eta C zerbitzuetarako eta dei bat hasi zuen laneko ingeniariei.

5xx akatsak Kibanan

Jarduera

efektu
Mota
Arduraduna
Task

Desgaitu eskalatzaile automatikoa CoreDNSrako
galarazi
Amet U.
DEVOPS-695

Konfiguratu cachean DNS zerbitzari bat
gutxitu
Max V.
DEVOPS-665

Konfiguratu conttrack monitorizazioa
galarazi
Amet U.
DEVOPS-674

Ikasgaiak

Zer ondo atera zen:

• Jarraipena ondo funtzionatu zuen. Erantzuna azkarra eta antolatua izan zen
• Nodoetan ez genuen mugarik lortu

Zer zegoen gaizki:

• Benetako kausa ezezaguna oraindik, antzekoa akats zehatza kontrakoan
• Ekintza guztiek ondorioak soilik zuzentzen dituzte, ez kausa (akatsa)
• Bagenekien lehenago edo beranduago DNSarekin arazoak izango genituela, baina ez genien zereginei lehentasuna eman.

Non izan genuen zortea:

• Hurrengo inplementazioa CoreDNS-autoscaler-ek abiarazi zuen, conntrack taula gainidatzi zuen
• Akats honek zerbitzu batzuei bakarrik eragin die

Kronograma (EET)

Denbora
efektu

22:13
CoreDNS-autoscaler-ek lek kopurua hirutik bira murriztu zuen

22:18
Laneko ingeniariak monitorizazio sistematik deiak jasotzen hasi ziren

22:21
Zerbitzuan zeuden ingeniariak akatsen zergatia jakiten hasi ziren.

22:39
Zerbitzuan zeuden ingeniariak azken zerbitzuetako bat aurreko bertsiora itzultzen hasi ziren

22:40
5xx akatsak agertzeari utzi zion, egoera egonkortu egin da

• Detektatzeko ordua: 4 minutu
• Ekintzaren aurreko denbora: 21 minutu
• Konpontzeko ordua: 1 minutu

Informazio osagarria

• CoreDNS erregistroak:

  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

• Kibana (moztu), Grafana (moztu) estekak
• Linux conttrack zure laguna ez den lekuan
• kube-proxy Ezaugarriak: Aldizkako konexioa berrezartzea
• Racy conttrack eta DNS bilaketaren denbora-muga

PUZaren erabilera minimizatzeko, Linux nukleoak conntrack izeneko zerbait erabiltzen du. Laburbilduz, taula berezi batean gordetzen diren NAT erregistroen zerrenda duen utilitatea da. Hurrengo paketea ontzi beretik aurreko ontzi berera iristen denean, azken IP helbidea ez da berriro kalkulatuko, baina conntrack taulatik hartuko da.

Contrack-ek nola funtzionatzen duen

Emaitzak

Hau gure postmortem baten adibidea izan zen, esteka erabilgarri batzuekin. Zehazki, artikulu honetan, beste enpresentzat erabilgarria izan daitekeen informazioa partekatzen dugu. Horregatik ez dugu akatsak egiteko beldurrik eta horregatik gure postmortem bat publiko egiten dugu. Hona hemen postmortem publiko interesgarriago batzuk:

• GitLab: Urtarrilaren 31ko datu-basearen etenaldiaren postmortem
• Dropbox: Etenaldia post mortem
• Spotify: Spotify-ren maitasun/gorroto harremana DNSrekin
• Beste asko mamia hau eta biltegia Kubernetes hutsegite istorioak
• Era berean, Adibidez postmortem publikoa SRE Book-ekin

Iturria: www.habr.com