Leta 2016 smo pri Bufferju , zdaj pa približno 60 vozlišč (na AWS) in 1500 vsebnikov dela na naši gruči k8s, ki jo upravlja . Vendar smo s poskusi in napakami prešli na mikrostoritve in tudi po nekaj letih dela s k8s se še vedno soočamo z novimi težavami. V tej objavi bomo govorili o procesorske omejitve: zakaj so se nam zdeli dobra praksa in zakaj na koncu niso bili tako dobri.
Omejitve procesorja in dušenje
Tako kot mnogi drugi uporabniki Kubernetesa, . Brez takšne nastavitve lahko vsebniki v vozlišču prevzamejo vso moč procesorja, kar posledično povzroči pomembne procese Kubernetes (npr. kubelet) ne bo več odgovarjal na zahteve. Tako je nastavitev omejitev procesorja dober način za zaščito vaših vozlišč.
Omejitve procesorja nastavijo vsebnik na največji čas procesorja, ki ga lahko uporabi za določeno obdobje (privzeto je 100 ms), vsebnik pa te omejitve ne bo nikoli presegel. V Kubernetesu za dušenje posodo in preprečiti, da bi presegla mejo, se uporabi posebno orodje , vendar te umetne omejitve procesorja na koncu škodijo zmogljivosti in povečajo odzivni čas vaših vsebnikov.
Kaj se lahko zgodi, če ne nastavimo omejitev procesorja?
Žal smo se s to težavo morali soočiti tudi sami. Vsako vozlišče ima proces, odgovoren za upravljanje vsebnikov kubelet, in ni več odgovarjal na zahteve. Ko se to zgodi, bo vozlišče prešlo v stanje NotReady, vsebniki iz njega pa bodo preusmerjeni nekam drugam in ustvarili enake težave na novih vozliščih. Ni idealen scenarij, milo rečeno.
Manifestacija problema dušenja in odziva
Ključna metrika za sledenje kontejnerjem je trottling, prikazuje, kolikokrat je bila vaša posoda dušina. Z zanimanjem smo opazili prisotnost dušenja v nekaterih vsebnikih, ne glede na to, ali je bila obremenitev procesorja ekstremna ali ne. Kot primer si poglejmo enega naših glavnih API-jev:
Kot lahko vidite spodaj, smo omejitev nastavili na 800m (0.8 ali 80% jedra) in najvišje vrednosti pri najboljšem dosegu 200m (20% jedra). Zdi se, da imamo pred dušenjem storitve še vedno dovolj procesorske moči, vendar ...
Morda ste opazili, da tudi ko je obremenitev procesorja pod določenimi mejami - bistveno pod - še vedno prihaja do dušenja.
Ko smo se soočili s tem, smo kmalu odkrili več virov (, , ) o padcu zmogljivosti in odzivnem času storitev zaradi dušenja.
Zakaj vidimo dušenje pri nizki obremenitvi procesorja? Kratka različica je: "v jedru Linuxa je napaka, ki povzroča nepotrebno dušenje vsebnikov z določenimi omejitvami procesorja." Če vas zanima narava problema, si lahko preberete predstavitev ( и možnosti) Dave Chiluk.
Odstranjevanje omejitev procesorja (skrajno previdno)
Po dolgih razpravah smo se odločili odstraniti omejitve procesorja za vse storitve, ki so neposredno ali posredno vplivale na kritično funkcionalnost naših uporabnikov.
Odločitev ni bila lahka, saj zelo cenimo stabilnost našega grozda. V preteklosti smo že eksperimentirali z nestabilnostjo naše gruče in takrat so servisi porabili preveč virov in upočasnili delo celotnega svojega vozlišča. Zdaj je bilo vse nekoliko drugače: imeli smo jasno razumevanje, kaj pričakujemo od naših grozdov, pa tudi dobro strategijo za izvedbo načrtovanih sprememb.
Poslovna korespondenca o perečem vprašanju.
Kako zaščititi svoja vozlišča, ko so omejitve odpravljene?
Izolacija "neomejenih" storitev:
V preteklosti smo že videli nekatera vozlišča preiti v stanje notReady, predvsem zaradi storitev, ki so porabile preveč virov.
Odločili smo se, da bomo takšne storitve postavili v ločena (»označena«) vozlišča, tako da ne motijo »sorodnih« storitev. Posledično smo z označevanjem nekaterih vozlišč in dodajanjem parametra tolerance »nepovezanim« storitvam dosegli večji nadzor nad gručo in lažje smo prepoznali težave z vozlišči. Če želite sami izvajati podobne postopke, se lahko seznanite z .
Dodeljevanje pravilnega procesorja in pomnilniške zahteve:
Naš največji strah je bil, da bi proces porabil preveč virov in bi se vozlišče nehalo odzivati na zahteve. Ker sedaj (zahvaljujoč Datadogu) lahko pregledno spremljamo vse storitve v našem grozdu, sem analiziral večmesečno delovanje tistih, ki smo jih nameravali označiti kot »nepovezane«. Preprosto sem nastavil največjo porabo procesorja z rezervo 20 % in s tem dodelil prostor v vozlišču v primeru, da k8s poskuša vozlišču dodeliti druge storitve.
Kot lahko vidite na grafu, je dosežena največja obremenitev procesorja 242m CPE jedra (0.242 procesorskih jeder). Za zahtevo procesorja je dovolj, da vzamete številko, ki je nekoliko večja od te vrednosti. Upoštevajte, da ker so storitve osredotočene na uporabnika, vrednosti konične obremenitve sovpadajo s prometom.
Enako storite z uporabo pomnilnika in poizvedbami in voila – pripravljeni ste! Za večjo varnost lahko dodate vodoravno samodejno skaliranje podov. Tako bo samodejno skaliranje vsakič, ko je obremenitev virov visoka, ustvarila nove pode, kubernetes pa jih bo razdelil vozliščem s prostim prostorom. V primeru, da v sami gruči ni več prostora, si lahko nastavite opozorilo ali konfigurirate dodajanje novih vozlišč prek njihovega samodejnega skaliranja.
Od minusov velja omeniti, da smo izgubili v "", tj. število vsebnikov, ki se izvajajo na enem vozlišču. Pri nizki gostoti prometa imamo lahko tudi veliko "sprostitev", obstaja pa tudi možnost, da dosežete visoko obremenitev procesorja, a pri slednjem naj bi pomagala vozlišča autoscaling.
Ugotovitve
Z veseljem objavljam te odlične rezultate poskusov v zadnjih nekaj tednih; v vseh spremenjenih storitvah smo že opazili znatne izboljšave odziva:
Najboljše rezultate smo dosegli na domači strani (), tam se je storitev pospešila v dvaindvajsetkrat!
Ali je napaka jedra Linuxa odpravljena?
Da, distribucije različice 4.19 in novejše.
Vendar pa ob branju za drugi september 2020 še vedno naletimo na omembe nekaterih projektov Linuxa s podobno napako. Menim, da imajo nekatere distribucije Linuxa še vedno to napako in jo pravkar poskušajo odpraviti.
Če je vaša različica distribucije nižja od 4.19, priporočam posodobitev na najnovejšo različico, vendar v vsakem primeru poskusite odstraniti omejitve procesorja in preverite, ali se dušenje še vedno pojavlja. Spodaj si lahko ogledate delni seznam storitev upravljanja Kubernetes in distribucij Linuxa:
- Debian: popravek integriran v najnovejšo različico distribucije, , in izgleda precej sveže (). Nekatere prejšnje različice so morda tudi popravljene.
- Ubuntu: popravek vgrajen v najnovejšo različico
- EKS je še dobil popravek . Če je vaša različica nižja od te, posodobite AMI.
- kops: у
kops 1.18+Glavna slika gostitelja bo Ubuntu 20.04. Če je vaša različica kops starejša, boste morda morali počakati na popravek. Sami zdaj čakamo. - GKE (Google Cloud): integriran popravek , vendar obstajajo težave z dušenjem .
Kaj storiti, če je popravek odpravil težavo z dušenjem?
Nisem prepričan, da je težava popolnoma rešena. Ko pridemo do različice jedra s popravkom, bom preizkusil gručo in posodobil objavo. Če je kdo že posodabljal, bi z veseljem prebral vaše rezultate.
Zaključek
- Če delate z vsebniki Docker pod Linuxom (ne glede na Kubernetes, Mesos, Swarm ali druge), lahko vaši vsebniki izgubijo zmogljivost zaradi dušenja;
- Poskusite posodobiti na najnovejšo različico svoje distribucije v upanju, da je napaka že odpravljena;
- Odstranitev omejitev procesorja bo rešila težavo, vendar je to nevarna tehnika, ki jo je treba uporabljati zelo previdno (bolje je, da najprej posodobite jedro in primerjate rezultate);
- Če ste odstranili omejitve procesorja, natančno spremljajte porabo procesorja in pomnilnika ter se prepričajte, da viri procesorja presegajo vašo porabo;
- Varna možnost bi bila samodejna skala podov za ustvarjanje novih podov v primeru velike obremenitve strojne opreme, tako da jih kubernetes dodeli prostim vozliščem.
Upam, da vam bo ta objava pomagala izboljšati učinkovitost vaših kontejnerskih sistemov.
PS avtorica si dopisuje z bralci in komentatorji (v angleščini).
Vir: www.habr.com