Huomautus käännös: Tämä on käännös julkisesta postmortemista yrityksen suunnittelublogista Valmistele. Se kuvaa Kubernetes-klusterin conntrack-ongelmaa, joka johti joidenkin tuotantopalvelujen osittaiseen seisokkiin.
Tämä artikkeli voi olla hyödyllinen niille, jotka haluavat oppia hieman enemmän postmortemista tai ehkäistä mahdollisia DNS-ongelmia tulevaisuudessa.
Tämä ei ole DNS
Se ei voi olla DNS
Se oli DNS
Hieman kuolemanjälkeisistä tapahtumista ja prosesseista Preplyssä
Postmortem kuvaa toimintahäiriötä tai jotakin tapahtumaa tuotannossa. Postmortem sisältää tapahtumien aikajanan, vaikutuksen käyttäjiin, perimmäisen syyn, suoritetut toimet ja opitut asiat.
Viikoittaisissa pizzatapaamisissa teknisen tiimin kesken jaamme erilaisia tietoja. Yksi tällaisten tapaamisten tärkeimmistä osista on ruumiinavaukset, joihin liittyy useimmiten esitys diaesineen ja tapauksen syvempää analyysiä. Vaikka emme taputtaa kuoleman jälkeen, yritämme kehittää "ei syyllistämisen" kulttuuria (moitteeton kulttuuri). Uskomme, että postmortemien kirjoittaminen ja esittäminen voi auttaa meitä (ja muita) estämään vastaavia tapauksia tulevaisuudessa, minkä vuoksi jaamme ne.
Tapaukseen osallistuneiden tulisi tuntea, että he voivat puhua yksityiskohtaisesti ilman pelkoa rangaistuksesta tai kostosta. Ei syytä! Postmortemin kirjoittaminen ei ole rangaistus, vaan oppimismahdollisuus koko yritykselle.
lyhyesti: DNS osittainen poissaolo (26 min) joissakin Kubernetes-klusterin palveluissa
Vaikutus: Palveluissa A, B ja C menetettiin 15000 XNUMX tapahtumaa
Pohjimmainen syy: Kube-proxy ei pystynyt poistamaan vanhaa merkintää oikein conntrack-taulukosta, joten jotkut palvelut yrittivät edelleen muodostaa yhteyttä olemattomiin podeihin
Laukaista: Kubernetes-klusterin alhaisen kuormituksen vuoksi CoreDNS-autoscaler vähensi käyttöönoton podien lukumäärän kolmesta kahteen.
ratkaisu: Sovelluksen seuraava käyttöönotto aloitti uusien solmujen luomisen, CoreDNS-autoscaler lisäsi lisää podeja palvelemaan klusteria, mikä aiheutti conntrack-taulukon uudelleenkirjoituksen.
Tunnistus: Prometheus-valvonta havaitsi suuren määrän 5xx-virheitä palveluissa A, B ja C ja soitti päivystäviä insinöörejä
5xx virheitä Kibanassa
Aktiivisuus
Действие
Tyyppi
vastuullinen
Tehtävä
Poista CoreDNS:n automaattinen skaalaus käytöstä
estetty
Amet U.
DEVOPS-695
Aseta välimuistiin tallennettu DNS-palvelin
vähentää
Max V.
DEVOPS-665
Määritä yhteysvalvonta
estetty
Amet U.
DEVOPS-674
Opittua
Mikä meni hyvin:
Valvonta toimi hyvin. Vastaus oli nopeaa ja organisoitua
Emme saavuttaneet solmujen rajoja
Mikä oli vialla:
Vielä tuntematon todellinen perimmäinen syy, samanlainen kuin tietty bugi vastaan
Kaikki toimet korjaavat vain seuraukset, eivät perimmäistä syytä (vikaa)
Tiesimme, että ennemmin tai myöhemmin meillä saattaa olla ongelmia DNS:n kanssa, mutta emme priorisoineet tehtäviä
Missä meillä kävi tuuri:
Seuraavan käyttöönoton käynnisti CoreDNS-autoscaler, joka ylikirjoitti conntrack-taulukon
Tämä virhe vaikutti vain joihinkin palveluihin
Aikajana (EET)
aika
Действие
22:13
CoreDNS-autoscaler vähensi podien lukumäärän kolmesta kahteen
22:18
Päivystävät insinöörit alkoivat saada soittoja valvontajärjestelmästä
22:21
Päivystävät insinöörit alkoivat selvittää virheiden syytä.
22:39
Päivystävät insinöörit aloittivat yhden uusimman palvelun palauttamisen edelliseen versioon
22:40
5xx-virheitä lakkasi ilmestymästä, tilanne on vakiintunut
Aika havaita: 4 minuuttia
Aika ennen toimintaa: 21 minuuttia
Aika korjata: 1 minuuttia
lisätiedot
CoreDNS-lokit:
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
Suorittimen käytön minimoimiseksi Linux-ydin käyttää jotain nimeltä conntrack. Lyhyesti sanottuna tämä on apuohjelma, joka sisältää luettelon NAT-tietueista, jotka on tallennettu erityiseen taulukkoon. Kun seuraava paketti saapuu samasta podista samaan podiin kuin ennenkin, lopullista IP-osoitetta ei lasketa uudelleen, vaan se otetaan conntrack-taulukosta.
Miten conntrack toimii
Tulokset
Tämä oli esimerkki yhdestä postmortemistamme, jossa oli hyödyllisiä linkkejä. Erityisesti tässä artikkelissa jaamme tietoja, joista voi olla hyötyä muille yrityksille. Siksi emme pelkää tehdä virheitä ja siksi teemme yhdestä postmortemistamme julkisen. Tässä on mielenkiintoisempia julkisia postmortemia: