Reen en 2016 ni ĉe Buffer , kaj nun ĉirkaŭ 60 nodoj (sur AWS) kaj 1500 ujoj laboras sur nia k8s-areto administrita de . Tamen ni transiris al mikroservoj per provo kaj eraro, kaj eĉ post pluraj jaroj da laborado kun k8s ni ankoraŭ alfrontas novajn problemojn. En ĉi tiu afiŝo ni parolos pri limigoj de procesoro: kial ni pensis, ke ili estas bona praktiko kaj kial ili finfine ne estis tiel bonaj.
Procesoraj limigoj kaj estrangilo
Kiel multaj aliaj uzantoj de Kubernetes, . Sen tia agordo, ujoj en nodo povas preni la tutan procesoran potencon, kiu siavice kaŭzas gravajn procezojn de Kubernetes (ekzemple kubelet) ĉesos respondi al petoj. Tiel, fiksi CPU-limojn estas bona maniero protekti viajn nodojn.
Procesoraj limoj fiksas ujon al la maksimuma CPU-tempo, kiun ĝi povas uzi por specifa periodo (defaŭlte estas 100ms), kaj la ujo neniam superos ĉi tiun limon. En Kubernetes por strangling ujo kaj malhelpi ĝin superi la limon, speciala ilo estas uzata , sed ĉi tiuj artefaritaj CPU-limoj finas damaĝi la rendimenton kaj pliigante la respondtempon de viaj ujoj.
Kio povas okazi se ni ne fiksas procesorajn limojn?
Bedaŭrinde, ni mem devis alfronti ĉi tiun problemon. Ĉiu nodo havas procezon respondecan pri administrado de ujoj kubelet, kaj li ĉesis respondi al petoj. La nodo, kiam ĉi tio okazos, iros en la ŝtaton NotReady, kaj ujoj de ĝi estos redirektitaj aliloken kaj kreos la samajn problemojn sur novaj nodoj. Ne ideala scenaro, por diri almenaŭ.
Manifestiĝo de la problemo de strollado kaj respondo
La ŝlosila metriko por kontenera spurado estas trottling, ĝi montras kiom da fojoj via ujo estis strekita. Ni rimarkis kun intereso la ĉeeston de estrango en iuj ujoj, sendepende de ĉu la procesoro-ŝarĝo estis ekstrema aŭ ne. Ekzemple, ni rigardu unu el niaj ĉefaj API-oj:
Kiel vi povas vidi sube, ni starigis la limon al 800m (0.8 aŭ 80% kerno), kaj maksimumaj valoroj plej bone atingas 200m (20% kerno). Ŝajnus, ke antaŭ ol streĉi la servon ni ankoraŭ havas multe da procesora potenco, tamen...
Vi eble rimarkis, ke eĉ kiam la procesoro-ŝarĝo estas sub la specifitaj limoj - signife malsupre - trompilo ankoraŭ okazas.
Fronte al tio, ni baldaŭ malkovris plurajn rimedojn (, , ) pri la falo en rendimento kaj respondtempo de servoj pro strolling.
Kial ni vidas trompi ĉe malalta CPU-ŝarĝo? La mallonga versio estas: "estas cimo en la Linukso-kerno, kiu kaŭzas nenecesan streĉon de ujoj kun specifitaj procesoraj limoj." Se vi interesiĝas pri la naturo de la problemo, vi povas legi la prezenton ( и opcioj) de Dave Chiluk.
Forigante CPU-limigojn (kun ekstrema singardo)
Post longaj diskutoj, ni decidis forigi procesorajn limigojn de ĉiuj servoj, kiuj rekte aŭ nerekte influis kritikan funkciecon por niaj uzantoj.
La decido ne estis facila ĉar ni alte taksas la stabilecon de nia areto. En la pasinteco, ni jam eksperimentis kun la malstabileco de nia areto, kaj tiam la servoj konsumis tro da rimedoj kaj malrapidigis la laboron de sia tuta nodo. Nun ĉio estis iom malsama: ni havis klaran komprenon pri tio, kion ni atendis de niaj aretoj, kaj ankaŭ bonan strategion por efektivigi la planitajn ŝanĝojn.
Komerca korespondado pri urĝa afero.
Kiel protekti viajn nodojn kiam limigoj estas nuligitaj?
Izoliĝo de "senrestriktitaj" servoj:
En la pasinteco, ni jam vidis iujn nodojn eniri en staton notReady, ĉefe pro servoj kiuj konsumis tro da resursoj.
Ni decidis meti tiajn servojn en apartajn ("etikeditajn") nodojn por ke ili ne malhelpu "rilatajn" servojn. Kiel rezulto, markante iujn nodojn kaj aldonante la tolereman parametron al "senrilataj" servoj, ni atingis pli grandan kontrolon super la areto, kaj fariĝis pli facile por ni identigi problemojn kun nodoj. Por efektivigi similajn procezojn mem, vi povas konatiĝi .
Asignante ĝustan procesoron kaj memorpeton:
Nia plej granda timo estis, ke la procezo konsumus tro da rimedoj kaj la nodo ĉesos respondi al petoj. Ĉar nun (danke al Datadog) ni povis klare kontroli ĉiujn servojn en nia areto, mi analizis plurajn monatojn de funkciado de tiuj, kiujn ni planis nomi kiel "senrilataj". Mi simple fiksis la maksimuman uzadon de CPU kun marĝeno de 20%, kaj tiel asignis spacon en la nodo, se k8s provas asigni aliajn servojn al la nodo.
Kiel vi povas vidi en la grafikaĵo, la maksimuma ŝarĝo sur la procesoro atingis 242m CPU-kernoj (0.242 procesoraj kernoj). Por procesora peto, sufiĉas preni nombron iomete pli grandan ol ĉi tiu valoro. Bonvolu noti, ke ĉar la servoj centras la uzantulojn, maksimumaj ŝarĝaj valoroj koincidas kun trafiko.
Faru la samon kun memoruzo kaj demandoj, kaj voila - vi ĉiuj estas aranĝitaj! Por pli granda sekureco, vi povas aldoni horizontalan podan aŭtoskalon. Tiel, ĉiufoje kiam la rimeda ŝarĝo estas alta, aŭtoskalado kreos novajn podojn, kaj kubernetes distribuos ilin al nodoj kun libera spaco. Se ne restas spaco en la areto mem, vi povas agordi al vi mem atentigon aŭ agordi la aldonon de novaj nodoj per ilia aŭtoskalo.
El la minusoj, indas noti, ke ni perdis en "", t.e. nombro da ujoj kurantaj sur unu nodo. Ni ankaŭ povas havi multajn "malstreĉiĝojn" ĉe malalta trafikdenseco, kaj ankaŭ estas ŝanco, ke vi atingos altan procesoran ŝarĝon, sed aŭtoskalaj nodoj devus helpi pri ĉi-lasta.
Результаты
Mi ĝojas publikigi ĉi tiujn bonegajn rezultojn de eksperimentoj dum la lastaj semajnoj; ni jam vidis signifajn plibonigojn en respondo tra ĉiuj modifitaj servoj:
Ni atingis la plej bonajn rezultojn sur nia hejmpaĝo (), tie la servo akcelis dudek du fojojn!
Ĉu la Linukso-kerna cimo estas riparita?
jes, distribuoj versio 4.19 kaj pli alta.
Tamen, leginte por la dua de septembro 2020 ni ankoraŭ trovas menciojn de iuj Linuksaj projektoj kun simila cimo. Mi kredas, ke iuj Linukso-distribuoj ankoraŭ havas ĉi tiun cimon kaj nur laboras por ripari ĝin.
Se via distribua versio estas pli malalta ol 4.19, mi rekomendus ĝisdatigi al la plej nova, sed ĉiukaze vi devus provi forigi la limigojn pri procesoro kaj vidi ĉu la strekado daŭras. Malsupre vi povas vidi partan liston de Kubernetes-administradservoj kaj Linukso-distribuoj:
- Debian: riparo integrita al la plej nova versio de la distribuo, , kaj aspektas sufiĉe freŝa (). Iuj antaŭaj versioj ankaŭ povas esti riparitaj.
- Ubuntu: riparo integrita en la plej novan version
- EKS ankoraŭ ricevis solvon . Se via versio estas pli malalta ol ĉi tio, vi devus ĝisdatigi la AMI.
- kops: у
kops 1.18+La ĉefa gastiga bildo estos Ubuntu 20.04. Se via versio de kops estas pli malnova, vi eble devos atendi solvon. Ni mem atendas nun. - GKE (Google Cloud): Riparo integrita , tamen estas problemoj kun strolling .
Kion fari se la riparo riparis la problemon de strolla?
Mi ne certas, ke la problemo estas tute solvita. Kiam ni atingos la kernan version kun la riparo, mi testos la areton kaj ĝisdatigos la afiŝon. Se iu jam ĝisdatigis, mi interesus legi viajn rezultojn.
konkludo
- Se vi laboras kun Docker-ujoj sub Linukso (ne gravas Kubernetes, Mesos, Svarmo aŭ aliaj), viaj ujoj eble perdos rendimenton pro strekado;
- Provu ĝisdatigi al la plej nova versio de via distribuo kun la espero, ke la cimo jam estas riparita;
- Forigi procesorajn limojn solvos la problemon, sed ĉi tio estas danĝera tekniko, kiu devas esti uzata kun ekstrema singardemo (pli bone estas unue ĝisdatigi la kernon kaj kompari la rezultojn);
- Se vi forigis CPU-limojn, zorge kontrolu vian CPU kaj memoruzadon kaj certigu, ke viaj CPU-rimedoj superas vian konsumon;
- Sekura opcio estus aŭtoskali podojn por krei novajn podojn en kazo de alta aparataro, tiel ke kubernetes asignas ilin al liberaj nodoj.
Mi esperas, ke ĉi tiu afiŝo helpos vin plibonigi la agadon de viaj ujsistemoj.
PS la aŭtoro korespondas kun legantoj kaj komentistoj (angle).
fonto: www.habr.com