DNS-ongelmat Kubernetesissa. Julkinen post mortem

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.

DNS-ongelmat Kubernetesissa. Julkinen post mortem
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.

Etsitään SRE:tä

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.

Säilytä CALMS & DevOps: S on jakamista varten

DNS-ongelmat Kubernetesissa. Jälkipuinti

Дата: 28.02.2020

Tekijät: Amet U., Andrey S., Igor K., Aleksei P.

Tila: Valmis

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

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: ...

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ä

DNS-ongelmat Kubernetesissa. Julkinen post mortem
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

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.
DNS-ongelmat Kubernetesissa. Julkinen post mortem
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:

Lähde: will.com

Lisää kommentti