Stručný prehľad problému  Jedného dňa sme počas plánovanej aktualizácie klastra k8s zistili, že takmer všetky naše PODy (približne 500 z 1 000) na nových uzloch sa nedali spustiť a minúty sa rýchlo zmenili na hodiny. Aktívne pátrame po hlavnej príčine, ale po troch hodinách boli PODS stále v stave   .  ContainerCreating  Našťastie to nebolo produkčné prostredie a obdobie údržby bolo naplánované na víkend. Mali sme čas na prešetrenie problému bez akéhokoľvek tlaku.  Kde by ste mali začať hľadať hlavnú príčinu? Chceli by ste sa dozvedieť viac o riešení, ktoré sme našli? Pripútajte sa a užívajte si!  Viac podrobností o probléme  Problém bol v tom, že sme mali veľké množstvo obrázkov dockerov, ktoré bolo potrebné stiahnuť a spustiť na každom uzle v klastri súčasne. Dôvodom bolo, že viacero súbežných stiahnutí obrazu dokovacieho zariadenia na jednom uzle môže viesť k vysokému využitiu disku a predĺženiu doby studeného štartu.  Procesu CD trvá z času na čas až 3 hodiny, kým sa stiahnu obrázky. Tentoraz sa to však úplne zaseklo, pretože množstvo PODS počas upgradu EKS (inline, keď vymeníme všetky uzly v klastri) bolo príliš vysoké.  Všetky naše aplikácie fungujú v k8s (založené na   ). Aby sme ušetrili naše náklady na DEV env, používame spotové inštancie. EKS  Pre uzly používame obraz   . AmazonLinux2  Vo vývojovom prostredí máme veľké množstvo   (FB), ktoré sú neustále nasadzované do nášho klastra Kubernetes. Každý FB má svoju vlastnú sadu aplikácií a každá aplikácia má svoju vlastnú sadu závislostí (vo vnútri obrázka). funkčných pobočiek  V našom projekte je takmer 200 aplikácií a toto číslo rastie. Každá aplikácia používa jeden zo 7 základných obrázkov doku s veľkosťou ~2 GB. Maximálna celková veľkosť archivovaného obrázka (v   ) je približne 3 GB. pokladnici  Všetky obrázky sú uložené v registri Amazon Elastic Container Registry (ECR).  Pre uzly používame predvolený typ zväzku gp3 EBS.   Problémy    Spustenie nového modulu s novým obrázkom môže trvať viac ako 1 hodinu, najmä ak sa na jednom uzle vytiahne viacero obrázkov súčasne. Predĺžený čas studeného štartu:    Časté   alebo uviaznutie v stave   , čo naznačuje problémy s načítaním obrázka. Chyby ErrImagePull: ErrImagePull ContainerCreating    Využitie disku zostáva počas procesu sťahovania obrazu takmer 100 %, predovšetkým kvôli intenzívnym vstupom/výstupom disku potrebným na dekompresiu (napr. „unpigz“). Vysoké využitie disku:    Niektoré systémové DaemonSets (ako   alebo   ) sa presunuli do stavu „nepripravený“ kvôli tlaku disku, čo má vplyv na pripravenosť uzla. Problémy s DaemonSet systému: aws-node ebs-csi-node    Pretože používame bodové inštancie, nemôžeme použiť lokálny disk na ukladanie obrázkov do vyrovnávacej pamäte. Žiadna vyrovnávacia pamäť obrázkov na uzloch:  To vedie k mnohým zastaveným nasadeniam na vetvách funkcií, najmä preto, že rôzne FB majú rozdielne sady základných obrázkov.  Po rýchlom skúmaní sme zistili, že hlavným problémom bol tlak disku na uzly procesom   . Tento proces je zodpovedný za dekompresiu obrázkov doku. Predvolené nastavenia pre typ hlasitosti gp3 EBS sme nemenili, pretože to nie je vhodné pre náš prípad. unpigz  Rýchla oprava na obnovenie klastra  Ako prvý krok sme sa rozhodli znížiť počet PODov na uzloch.  Nové uzly presunieme do stavu „Cordon“.  Odstráňte všetky zaseknuté PODS, aby ste znížili tlak disku  Spúšťajte jeden po druhom PODy, aby ste zahriali uzly  Potom presunieme zahriate uzly do normálneho stavu („unCordon“)  Odstránili sa všetky uzly v zaseknutom stave  Všetky PODS sa úspešne spustili pomocou vyrovnávacej pamäte obrázkov Docker   Originálny dizajn CI/CD  Hlavnou myšlienkou riešenia je zahriať uzly pred spustením procesu CD najväčšou časťou obrazu dockeru (vrstva závislostí JS), ktorá sa používa ako koreňový obraz pre všetky naše aplikácie. Máme aspoň 7 typov koreňových obrázkov so závislosťami JS, ktoré súvisia s typom aplikácie. Poďme teda analyzovať pôvodný dizajn CI/CD.     V našom potrubí CI/CD máme 3 piliere:   Originálny kanál CI/CD:  V kroku   it: pripravíme prostredie/premenné, definujeme sadu obrázkov na prebudovanie atď... Init  V kroku   : vytvoríme obrázky a pošleme ich do pokladne Build  V kroku   : nasadíme obrázky do k8 (aktualizácia nasadení atď.) Deploy   Viac podrobností o pôvodnom dizajne CICD:  Naše hlavné pobočky (FB) sa rozdelili z   pobočky. V procese CI vždy analyzujeme množinu obrázkov, ktoré boli zmenené na FB a prestavujeme ich.   vetva je vždy stabilná, pretože definícia by mala byť vždy najnovšia verzia základných obrázkov. main main  Samostatne vytvárame obrázky dokovacích staníc závislostí JS (pre každé prostredie) a posielame ich do ECR, aby sme ich znova použili ako koreňový (základný) obrázok v súbore Dockerfile. Máme približne 5 až 10 typov dokovacieho obrazu závislostí JS.  FB je nasadený do klastra k8s do samostatného menného priestoru, ale do spoločných uzlov pre FB. FB môže mať ~200 aplikácií s veľkosťou obrázka do 3 GB.  Máme klastrový autoscaling systém, ktorý škáluje uzly v klastri na základe zaťaženia alebo čakajúcich PODS s príslušným nodeSelector a toleranciou.  Pre uzly používame bodové inštancie.  Realizácia procesu zahrievania  Existujú požiadavky na proces zahrievania.  Povinné:    : Rieši a rieši problémy   . Riešenie problémov ContainerCreating    : Výrazne znižuje čas spustenia pomocou predhriatych základných obrazov (závislosti JS). Vylepšený výkon  Je pekné mať vylepšenia:    : Umožňuje jednoduché zmeny typu uzla a jeho životnosti (napr. vysoká SLA alebo predĺžená doba životnosti). Flexibilita    : Poskytuje jasné metriky používania a výkonu. Transparentnosť    : Šetrí náklady odstránením VNG ihneď po odstránení súvisiacej vetvy funkcií. Efektivita nákladov    : Tento prístup zaisťuje, že iné prostredia nebudú ovplyvnené. Izolácia  Riešenie  Po analýze požiadaviek a obmedzení sme sa rozhodli implementovať proces zahrievania, ktorý by predhrieval uzly so základnými obrázkami vyrovnávacej pamäte JS. Tento proces by sa spustil pred spustením procesu CD, čím sa zabezpečí, že uzly sú pripravené na nasadenie FB a máme maximálnu šancu zasiahnuť do vyrovnávacej pamäte.  Toto zlepšenie sme rozdelili do troch veľkých krokov:  Vytvorte   (skupinu virtuálnych uzlov)  množinu uzlov pre každý FB  Pridajte   pre nové uzly základné obrázky do skriptu cloud-init  Pridajte   so sekciou   , aby ste si stiahli potrebné obrazy dokovacích staníc do uzlov pred spustením procesu CD. krok pred nasadením na spustenie DaemonSet initContainers     Aktualizovaný kanál CI/CD by vyzeral takto:   Aktualizovaný kanál CI/CD:    krok  1.1. (nový krok)   : Ak ide o prvé spustenie FB, potom vytvorte novú osobnú sadu inštancií uzla (v našich podmienkach je to skupina Virtual Node Group alebo VNG) a stiahnite si všetky základné obrázky JS (5–10 obrázkov ) z hlavnej pobočky. Je to dosť fér, pretože sme FB forkovali z hlavnej pobočky. Dôležitý bod, nie je to blokovacia operácia. Úvodný Init deploy    krok Stavať  Krok   Stiahnite si čerstvo upečené základné obrázky JS so špecifickým FB tagom z ECR.  3.1.(nový krok)   : Je to blokovacia operácia, pretože by sme mali znížiť tlak disku. Jeden po druhom stiahneme základné obrázky pre každý súvisiaci uzol.  Btw, vďaka za krok „   , už máme základné obrázky dockerov z hlavnej vetvy, čo nám dáva veľkú šancu zasiahnuť do vyrovnávacej pamäte pri prvom spustení. pred nasadením Dôležité body init deploy“  **Nasadenie  **V tomto kroku nie sú žiadne zmeny. Ale vďaka predchádzajúcemu kroku už máme všetky ťažké vrstvy obrázkov dockerov na potrebných uzloch.  Krok nasadenia    prostredníctvom volania API (do systému automatického škálovania tretej strany) z nášho kanála CI. Vytvorte novú množinu uzlov pre každý FB   Vyriešené problémy:    : Každý FB má svoj vlastný súbor uzlov, ktorý zabezpečuje, že prostredie nie je ovplyvnené inými FB. Izolácia    : Môžeme ľahko zmeniť typ uzla a jeho životnosť. Flexibilita    : Uzly môžeme vymazať ihneď po vymazaní FB. Efektivita nákladov    : Môžeme ľahko sledovať využitie a výkon uzlov (každý uzol má značku súvisiacu s FB). Transparentnosť    : Inštancia spotu začína s už preddefinovanými základnými obrázkami, to znamená, že po spustení bodového uzla sú na uzle už základné obrázky (z hlavnej vetvy). Efektívne využitie inštancií spotu    pomocou   skriptu. Stiahnite si všetky základné obrázky JS z hlavnej vetvy do nových uzlov cloud-init  Zatiaľ čo sa obrázky sťahujú na pozadí, proces CD môže pokračovať v vytváraní nových obrázkov bez akýchkoľvek problémov. Okrem toho budú ďalšie uzly (ktoré budú vytvorené systémom automatického škálovania) z tejto skupiny vytvorené s aktualizovanými údajmi   , ktoré už majú pokyny na stiahnutie obrázkov pred spustením. cloud-init  Vyriešené problémy:    : Tlak na disk je preč, pretože sme aktualizovali skript   pridaním sťahovania základných obrázkov z hlavnej pobočky. To nám umožňuje trafiť cache pri prvom spustení FB. Riešenie problému cloud-init    : Inštancia spotu začína s aktualizovanými údajmi   . To znamená, že po spustení bodového uzla sú na uzle už základné obrázky (z hlavnej vetvy). Efektívne využitie inštancií spotu cloud-init    : Proces CD môže pokračovať v vytváraní nových obrazov bez akýchkoľvek problémov. Vylepšený výkon  Táto akcia pridala ~17 sekúnd (volanie API) do nášho kanála CI/CD.  Táto akcia dáva zmysel len prvýkrát, keď spustíme FB. Nabudúce nasadíme naše aplikácie do už existujúcich uzlov, ktoré už majú základné obrázky, ktoré sme dodali pri predchádzajúcom nasadení.  Krok pred nasadením  Tento krok potrebujeme, pretože obrázky FB sa líšia od obrázkov hlavnej pobočky. Pred spustením procesu CD musíme stiahnuť základné obrázky FB do uzlov. Pomôže to zmierniť predĺžené časy studeného štartu a vysoké využitie disku, ktoré môže nastať, keď sa súčasne stiahne viacero ťažkých obrazov.   Ciele kroku pred nasadením    : Postupne sťahujte najťažšie obrázky dokovacieho zariadenia. Po kroku init-deploy už máme základné obrázky na uzloch, čo znamená, že máme veľkú šancu na nájdenie cache. Zabráňte tlaku disku    : Zaistite, aby boli uzly predhriate základnými obrázkami dokovacieho zariadenia, čo vedie k rýchlejšiemu (takmer okamžite) spusteniu zariadenia POD. Zlepšite efektivitu nasadenia    : Minimalizujte pravdepodobnosť výskytu chýb   /   a zabezpečte, aby sady systémových démonov zostali v stave „pripravenosti“. Vylepšenie stability ErrImagePull ContainerCreating  V rámci tohto kroku pridáme k procesu CD 10–15 minút.  Podrobnosti o kroku pred nasadením:  Na CD vytvoríme DaemonSet so sekciou   . initContainers  Sekcia   sa spustí pred spustením hlavného kontajnera, čím sa zabezpečí, že sa potrebné obrázky stiahnu pred spustením hlavného kontajnera. initContainers  Na CD priebežne kontrolujeme stav daemonSet. Ak je daemonSet v stave „pripravený“, pokračujeme v nasadení. V opačnom prípade počkáme, kým bude sada démonov pripravená.  Porovnanie  Porovnanie pôvodných a aktualizovaných krokov s procesom predhrievania.  Krok  Krok nasadenia  Krok pred nasadením  Nasadiť  Celkový čas  Dif  Bez predohrevu  0  0  11 m 21 s  11 m 21 s  0  S predhrievaním  8 sekúnd  58 sekúnd  25 sekúnd  1 m 31 s  -9m 50s  Hlavná vec je, že čas „Deploy“ sa zmenil (z prvého príkazu na použitie do stavu Spustenia modulov) z 11 m 21 s na 25 sekúnd. Celkový čas sa zmenil z 11m 21s na 1m 31s. Dôležitý bod, ak neexistujú žiadne základné obrázky z hlavnej vetvy, čas „nasadenia“ bude rovnaký ako pôvodný čas alebo o niečo viac. Ale aj tak sme vyriešili problém s tlakom disku a časom studeného štartu.  Záver   Hlavný problém   bol vyriešený procesom zahrievania. Ako výhodu sme výrazne skrátili čas studeného štartu PODov.  Tlak disku bol preč, pretože už máme základné obrázky na uzloch. Systémové sady démonov sú v „pripravenom“ a „zdravom“ stave (pretože nie je žiadny tlak na disk) a nezaznamenali sme žiadne chyby   súvisiace s týmto problémom. ContainerCreating ErrImagePull  Možné riešenia a odkazy  Použite inštancie   pre uzly namiesto   Tento spôsob nemôžeme použiť, pretože je to mimo rámca nášho rozpočtu pre neprodukčné prostredia. na požiadanie okamžitých inštancií    Tento spôsob nemôžeme použiť, pretože táto funkcia tiež presahuje rozsah nášho rozpočtu pre neprodukčné prostredia. Okrem toho má AWS   IOPS pre váš účet na región. Použite typ zväzku Amazon EBS gp3 (alebo lepší) so zvýšeným IOPS limity    V skutočnosti sa týmto spôsobom nemôžeme pohnúť, pretože to má príliš veľký dopad na produkciu a iné prostredia, ale je to tiež dobré riešenie nášho problému. Znížte čas spúšťania kontajnera na Amazon EKS pomocou objemu dát Bottlerocket   Riešenie problémov Kubernetes Cluster Autoscaler trvá 1 hodinu, kým sa zväčší 600 modulov    Chcel by som poďakovať skvelému technickému tímu v   (   ) za neúnavnú prácu a skutočne kreatívny prístup k akémukoľvek problému, ktorému čelia s Najmä pokrik Ronnymu Sharabymu, vynikajúcemu lídrovi, ktorý je zodpovedný za skvelú prácu, ktorú tím odvádza. Teším sa na ďalšie a ďalšie skvelé príklady toho, ako vaša kreativita ovplyvňuje produkt Justt. PS: Justt https://www.linkedin.com/company/justt-ai

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Tento zvuk je vyrobený v pôvodnom jazyku príbehu!

Príliš dlho; Čítať

Make resilience your competitive advantage

Ako optimalizovať Kubernetes pre veľké obrázky Docker

About Author

KOMENTÁRE

ZAVISTE ŠTÍTKY

TENTO ČLÁNOK BOL PREDSTAVENÝ V

Related Stories

112 Stories To Learn About Hackernoon Community

Mutmut: a Python mutation testing system

Code Smell 298 - How to Fix Microsoft Windows Time Waste

16 Best Sklearn Datasets for Building Machine Learning Models

112 Stories To Learn About Hackernoon Community

Mutmut: a Python mutation testing system

Code Smell 298 - How to Fix Microsoft Windows Time Waste

16 Best Sklearn Datasets for Building Machine Learning Models

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps