A probléma rövid áttekintése  Egy nap, a k8s-fürt tervezett frissítése során felfedeztük, hogy szinte az összes POD-unk (1000-ből körülbelül 500) az új csomópontokon nem tudott elindulni, és a percek gyorsan órákká váltak. Aktívan keressük a kiváltó okot, de három óra elteltével a PODS-ek még mindig   állapotban voltak.  ContainerCreating  Szerencsére ez nem a prod környezet volt, és a karbantartási időszakot a hétvégére ütemezték. Volt időnk nyomás nélkül kivizsgálni a kérdést.  Hol kezdje a kiváltó ok keresését? Szeretne többet megtudni az általunk talált megoldásról? Kapcsold be és élvezd!  További részletek a problémáról  A probléma az volt, hogy nagyszámú docker-képünk volt, amelyeket egyszerre kellett lehúzni és elindítani a fürt minden csomópontján. Ennek az az oka, hogy az egy csomóponton végzett többszöri, egyidejű dokkolókép-letöltés magas lemezkihasználáshoz és meghosszabbított hidegindítási időhöz vezethet.  A CD-feldolgozás időnként akár 3 órát is igénybe vesz a képek előhívásához. Ezúttal azonban ez teljesen elakadt, mert az EKS frissítés során (inline, amikor a fürt összes csomópontját cseréljük) túl magas volt a PODS mennyisége.  Minden alkalmazásunk a k8s-ban él (   alapú). A DEV env költségeinek megtakarítása érdekében spot példányokat használunk. EKS  A csomópontokhoz az   képet használjuk. AmazonLinux2  A fejlesztői környezetben számos   (FB) található, amelyeket folyamatosan telepítünk Kubernetes-fürtünkre. Minden FB-nek megvannak a saját alkalmazáskészletei, és minden alkalmazásnak megvannak a saját függőségei (egy képen belül). szolgáltatási ág  Projektünkben közel 200 alkalmazás, és ez a szám növekszik. Mindegyik alkalmazás a 7 ~2 GB méretű docker alapkép egyikét használja. Az archivált kép maximális teljes mérete (az   -ben) körülbelül 3 GB. ECR  Az összes képet az Amazon Elastic Container Registry (ECR) tárolja.  A csomópontokhoz az alapértelmezett gp3 EBS kötettípust használjuk.   Problémák    Egy új képsor új indítása több mint 1 órát is igénybe vehet, különösen akkor, ha több képet húznak egyszerre egy csomóponton. Meghosszabbított hidegindítási idő:    Gyakori   vagy beragad a   állapotoknál, ami a képlehívással kapcsolatos problémákra utal. ErrImagePull hibák: ErrImagePull ContainerCreating    A lemezkihasználtság 100% közelében marad a képletöltési folyamat során, elsősorban a kibontáshoz szükséges intenzív lemez I/O miatt (pl. „unpigz”). Magas lemezkihasználás:    Egyes rendszer DaemonSets (például   vagy   ) "nem kész" állapotba került a lemeznyomás miatt, ami befolyásolja a csomópont készenlétét. System DaemonSet problémák: aws-node ebs-csi-node    Mivel spot példányokat használunk, nem használhatjuk a helyi lemezt a képek gyorsítótárazására. Nincs képgyorsítótár a csomópontokon:  Ez sok elakadt központi telepítést eredményez a szolgáltatási ágakon, különösen azért, mert a különböző FB-k eltérő alapképkészletekkel rendelkeznek.  Gyors vizsgálat után azt találtuk, hogy a fő probléma az   folyamat által a csomópontokra nehezedő lemeznyomás volt. Ez a folyamat felelős a docker képek kicsomagolásáért. A gp3 EBS kötettípus alapbeállításait nem változtattuk meg, mert esetünkben nem megfelelőek. unpigz  Gyorsjavítás a fürt helyreállításához  Első lépésként úgy döntöttünk, hogy csökkentjük a POD-ok számát a csomópontokon.  Az új csomópontokat „Cordon” állapotba helyezzük  Távolítson el minden elakadt PODS-t a lemeznyomás csökkentése érdekében  Futtassa egyenként a POD-okat a csomópontok bemelegítéséhez  Ezt követően a felmelegedett csomópontokat normál állapotba ("unCordon") mozgatjuk.  Az összes beragadt állapotú csomópont eltávolítva  Az összes PODS sikeresen elkezdte használni a Docker kép-gyorsítótárat   Eredeti CI/CD dizájn  A megoldás fő ötlete az, hogy a CD-folyamat megkezdése előtt felmelegítsük a csomópontokat a docker image (JS függőségi réteg) legnagyobb részével, amely az összes alkalmazásunk gyökérképeként használható. Legalább 7 fajta gyökérképünk van a JS-függőségekkel, amelyek az alkalmazás típusához kapcsolódnak. Tehát elemezzük az eredeti CI/CD dizájnt.     CI/CD folyamatunkban 3 pillérünk van:   Eredeti CI/CD csővezeték:  Az   it lépésben: előkészítjük a környezetet/változókat, meghatározzuk az újraépítendő képek halmazát, stb... Init  Az   lépésben: megépítjük a képeket, és eltoljuk őket az ECR-hez Build  A   lépésnél: telepítjük a képeket a k8s-ba (frissítési telepítések stb.) Deploy   További részletek az eredeti CICD dizájnról:  Szolgáltatási fiókjaink (FB) a   ágból kiágaztak. A CI folyamatban mindig elemezzük az FB-ben módosított képkészletet, és újraépítjük azokat. A   ág mindig stabil, a definíció szerint mindig az alapképek legfrissebb verziójának kell lennie. main main  Külön építjük fel a JS-függőségek docker-képeit (minden környezethez), és továbbítjuk az ECR-hez, hogy újra felhasználhassuk gyökér (alap) képként a Dockerfile-ban. Körülbelül 5–10 típusú JS-függőségi dokkolókép áll rendelkezésünkre.  Az FB a k8s fürtbe kerül a külön névtérbe, de az FB közös csomópontjaiba. Az FB-n ~200 alkalmazás lehet, a képméret akár 3 GB is lehet.  Rendelkezünk a fürt automatikus skálázó rendszerével, amely a terhelés vagy a függőben lévő PODS-ek alapján skálázza a fürt csomópontjait a megfelelő nodeSelectorral és toleranciával.  A csomópontokhoz a spot példányokat használjuk.  A bemelegítési folyamat végrehajtása  A bemelegítési folyamatnak vannak követelményei.  Kötelező:    : Megoldja és megoldja   problémákat. Problémamegoldás ContainerCreating    : Jelentősen csökkenti az indítási időt az előmelegített alapképek (JS-függőségek) használatával. Továbbfejlesztett teljesítmény  Örülök, hogy vannak fejlesztések:    : Lehetővé teszi a csomópont típusának és élettartamának egyszerű megváltoztatását (pl. magas SLA vagy hosszabb élettartam). Rugalmasság    : Világos mérőszámokat biztosít a használatról és a teljesítményről. Átlátszóság    : Költséget takarít meg a VNG azonnali törlésével, miután a kapcsolódó szolgáltatási ágat törölték. Költséghatékonyság    : Ez a megközelítés biztosítja, hogy más környezeteket ne érintsen. Izoláció  Megoldás  A követelmények és megszorítások elemzése után úgy döntöttünk, hogy egy bemelegítő folyamatot hajtunk végre, amely előmelegíti a csomópontokat az alap JS gyorsítótár-képekkel. Ez a folyamat a CD-folyamat megkezdése előtt indul el, biztosítva, hogy a csomópontok készen álljanak az FB telepítésére, és maximális esélyünk legyen a gyorsítótár eléréséhez.  Ezt a fejlesztést nagy lépésekre bontjuk:  Hozza létre a   (virtuális csomópontcsoport)  csomópontok készletét minden egyes FB-nként  Adjon hozzá   parancsfájljához alapképeket az új csomópontok felhő-init  Adjon hozzá egy   az   szakaszsal, hogy a CD-folyamat megkezdése előtt letöltse a szükséges dokkolóképeket a csomópontokra. telepítés előtti lépést a DaemonSet futtatásához initContainers     Egy frissített CI/CD folyamat így néz ki:   Frissített CI/CD folyamat:    lépés  1.1. (új lépés)   : Ha ez az FB első indítása, akkor hozzon létre egy új személyes csomópont-példánykészletet (a mi fogalmaink szerint ez Virtual Node Group vagy VNG), és töltse le az összes JS alapképet (5–10 kép). ) a főágról. Elég jogos megtenni, mert elágaztuk a FB-t a főfiókból. Fontos szempont, hogy ez nem blokkoló művelet. Init Telepítés megkezdése    lépés Építési    lépés Töltse le a frissen elkészített JS-alapképeket az adott FB-címkével az ECR-ből.  3.1.(új lépés)   : Ez egy blokkoló művelet, mert csökkenteni kell a lemeznyomást. Egyesével letöltjük az alapképeket minden kapcsolódó csomóponthoz.  Btw, köszönjük az „   lépést, már megvannak az alap docker image-ek a főágból, vagyis nagy esélyünk van arra, hogy az első indításkor elérjük a gyorsítótárat. Telepítés előtti Fontos tudnivalók init deploy”  ** Telepítés  ** Ebben a lépésben nincs változás. De az előző lépésnek köszönhetően már minden nehéz docker képrétegünk van a szükséges csomópontokon.  Init telepítési lépés    API-híváson keresztül (a harmadik fél automatikus skálázó rendszeréhez) a CI-folyamatból. Hozzon létre egy új csomópontkészletet minden egyes FB-hez   Megoldott problémák:    : Minden FB-nek saját csomópontkészlete van, biztosítva, hogy a környezetet ne befolyásolják más FB-k. Izoláció    : Könnyen megváltoztathatjuk a csomópont típusát és élettartamát. Rugalmasság    : Az FB törlése után azonnal törölhetjük a csomópontokat. Költséghatékonyság    : Könnyen nyomon követhetjük a csomópontok használatát és teljesítményét (minden csomóponton van egy FB-hez kapcsolódó tag). Átlátszóság    : A spot példány már előre definiált alapképekkel indul, vagyis a spot csomópont indulása után már ott vannak az alapképek a csomóponton (a fő ágból). A spot példányok hatékony használata      parancsfájl segítségével. Töltse le az összes JS-alapképet a fő ágból az új csomópontokba cloud-init  Amíg a képek letöltése folyamatban van a háttérben, a CD-folyamat gond nélkül folytathatja az új képek létrehozását. Sőt, ebből a csoportból a következő csomópontok (amelyeket az automatikus skálázási rendszer hoz létre) a frissített   adatokkal jönnek létre, amelyek már rendelkeznek utasításokkal a képek letöltéséhez az indítás előtt. cloud-init  Megoldott problémák:    : A lemeznyomás megszűnt, mert frissítettük a   szkriptet az alapképek letöltésének hozzáadásával a fő ágból. Ez lehetővé teszi, hogy az FB első indításakor elérjük a gyorsítótárat. Problémamegoldás cloud-init    : A helyszíni példány frissített   adatokkal indul. Ez azt jelenti, hogy a spot csomópont indulása után már ott vannak az alapképek a csomóponton (a fő ágból). A helyszíni példányok hatékony használata cloud-init    : A CD-folyamat gond nélkül folytathatja az új lemezképek létrehozását. Továbbfejlesztett teljesítmény  Ez a művelet körülbelül 17 másodpercet (API-hívást) adott a CI/CD folyamatunkhoz.  Ennek a műveletnek csak az első alkalommal van értelme, amikor elindítjuk az FB-t. Legközelebb a már meglévő csomópontokra telepítjük alkalmazásainkat, amelyek már rendelkeznek az előző telepítéskor szállított alapképekkel.  Telepítés előtti lépés  Erre a lépésre azért van szükségünk, mert az FB képek eltérnek a fő ágképektől. A CD-folyamat megkezdése előtt le kell töltenünk az FB alapképeket a csomópontokra. Ez segít csökkenteni a hosszabb hidegindítási időket és a magas lemezkihasználást, amely akkor fordulhat elő, ha több nehéz képet egyszerre húznak ki.   A bevezetés előtti lépés céljai    : A docker legnehezebb képeinek szekvenciális letöltése. Az init-deploy lépés után már megvannak az alapképek a csomópontokon, ami azt jelenti, hogy nagy esélyünk van a találati gyorsítótárra. Lemeznyomás megelőzése    : Győződjön meg róla, hogy a csomópontok előmelegítve vannak az alapvető docker-képekkel, ami gyorsabb (szinte azonnali) POD-indítási időt eredményez. A telepítési hatékonyság javítása    : Csökkentse az   /   hibák előfordulásának esélyét, és biztosítsa, hogy a rendszerdémonkészletek „kész” állapotban maradjanak. Stabilitás növelése ErrImagePull ContainerCreating  Ebben a lépésben 10–15 percet adunk a CD-folyamathoz.  Telepítés előtti lépés részletei:  A CD-n létrehozunk egy DaemonSet-et az   szekcióval. initContainers  Az   szakasz a fő tároló elindulása előtt lefut, biztosítva, hogy a szükséges képek letöltésre kerüljenek a fő tároló indulása előtt. initContainers  A CD-n folyamatosan ellenőrizzük a daemonSet állapotát. Ha a daemonSet „kész” állapotban van, akkor folytatjuk a telepítést. Ellenkező esetben megvárjuk, amíg a daemonSet készen áll.  Összehasonlítás  Az eredeti és frissített lépések összehasonlítása az előmelegítési folyamattal.  Lépés  Init telepítési lépés  Telepítés előtti lépés  Telepítés  Teljes idő  Diff  Előmelegítés nélkül  0  0  11h 21s  11h 21s  0  Előmelegítéssel  8 másodperc  58 másodperc  25 másodperc  1h 31s  -9m 50s  A lényeg, hogy a „Deploy” idő megváltozott (az első alkalmazás parancstól a podok futási állapotáig) 11 perc 21 másodpercről 25 másodpercre. A teljes idő 11 óra 21 másodpercről 1 óra 31 másodpercre változott. Fontos szempont, hogy ha nincsenek alapképek a fő ágból, akkor a „Deploy” ideje megegyezik az eredeti időponttal, vagy kicsit több. De mindenesetre megoldottuk a lemeznyomással és a hidegindítási idővel kapcsolatos problémát.  Következtetés   A   fő problémáját a bemelegítési folyamat megoldotta. Előnyként jelentősen csökkentettük a POD-ok hidegindítási idejét.  A lemeznyomás megszűnt, mert már megvannak az alapképek a csomópontokon. A rendszer démonSets „kész” és „egészséges” állapotban van (mivel nincs lemeznyomás), és nem találkoztunk ezzel a problémával kapcsolatos   hibával. ContainerCreating ErrImagePull  Lehetséges megoldások és linkek  Használjon   példányokat a csomópontokhoz a   helyett  Nem használhatjuk ezt a módot, mert ez nem tartozik a nem gyártási környezetekre szánt költségvetésünkbe. igény szerinti helyszíni példányok    Nem használhatjuk ezt a módot, mert ez a funkció nem gyártási környezetekre is kikerül a költségvetésünk keretéből. Ezenkívül az AWS régiónként   meg az IOPS-t a fiókjában. Használja az Amazon EBS gp3 (vagy jobb) kötettípust a megnövelt IOPS-sel határozza    Tulajdonképpen nem tudunk ezen az úton haladni, mert túl nagy hatással van a termelésre és más környezetekre, de egyben jó megoldás a problémánkra. Csökkentse a konténer indítási idejét az Amazon EKS rendszeren a Bottlerocket adatmennyiséggel   A Kubernetes Cluster Autoscaler hibaelhárítása 1 órába telik a 600 sorba skálázáshoz    Szeretnék köszönetet mondani a   nagyszerű technikai csapatának (   ) fáradhatatlan munkájukért és igazán kreatív hozzáállásukért minden problémához, amellyel szembesülnek. vel. Különösen Ronny Sharaby-nak, a kiváló vezetőnek, aki felelős a csapat által végzett nagyszerű munkáért. Alig várom, hogy egyre több nagyszerű példát láthassak arra vonatkozóan, hogy az Ön kreativitása hogyan hat a Justt termékre. 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

Ez a hanganyag a történet eredeti nyelvén készült!

A Kubernetes optimalizálása a nagy Docker-képekhez

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

HackerNoon Raises $250k at $50M Valuation From Forward Research

HackerNoon Contributor Denisa Ganea on HackerNoon, Human Existence, and Everything in Between

THE LAST DAY OF NEW YORK

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

HackerNoon Raises $250k at $50M Valuation From Forward Research

HackerNoon Contributor Denisa Ganea on HackerNoon, Human Existence, and Everything in Between

THE LAST DAY OF NEW YORK

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps