Horizontal Pod Autoscaler i Kubernetes ka veçori që ndoshta nuk i dini. Ja se si t'i përdorni ato në avantazhin tuaj.
Shumica e njerëzve që përdorin Kubernetes e dinë se mund t'i shkallëzoni aplikacionet duke përdorur Horizontal Pod Autoscaler (HPA) bazuar në përdorimin e CPU-së ose të kujtesës. Megjithatë, ka shumë veçori të tjera të HPA që mund t'i përdorni për të personalizuar sjelljen e shkallëzimit të aplikacionit tuaj, si p.sh. shkallëzimi duke përdorur metrika të personalizuara të aplikacionit ose metrikë të jashtëm, si dhe veçori alfa/beta si “shkallëzimi në zero” ose shkallëzimi i metrikës së kontejnerit.
Pra, në këtë artikull ne do t'i shqyrtojmë të gjitha këto opsione në mënyrë që të mund të përfitojmë plotësisht nga të gjitha veçoritë e disponueshme të HPA dhe të marrim një fillim në krye të veçorive që do të vijnë në publikimet e ardhshme të Kubernetes.
Konfigurimi
Përpara se të fillojmë me shkallëzimin, së pari na duhet një mjedis testimi. Për këtë ne do të përdorim grupin KinD (Kubernetes në Docker) të përcaktuar nga YAML e mëposhtme:
Ky manifest konfiguron grupin KinD me 1 nyje rrafsh kontrolli dhe 3 punëtorë, përveç kësaj ai mundëson disa porta të veçorive që lidhen me shkallëzimin automatik. Këto porta të veçorive më vonë do të na lejojnë të përdorim disa veçori alfa/beta të HPA. Për të krijuar një grup me konfigurimin e mësipërm, mund të ekzekutoni:
Përveç grupit, do të na duhet edhe një aplikacion që do ta shkallëzojmë. Për këtë ne do të përdorim "mjetin e konsumit të burimeve" dhe imazhin e tij, të cilat përdoren në testimin nga fundi në fund të Kubernetes. Për ta vendosur atë, mund të ekzekutoni:
Ky aplikacion është shumë i dobishëm në këtë situatë, pasi na lejon të simulojmë konsumin e CPU-së dhe kujtesës së një Pod. Ai gjithashtu mund të ekspozojë metrikat e personalizuara që nevojiten për shkallëzim bazuar në metrikat e personalizuara/të jashtme. Për ta testuar këtë mund të ekzekutojmë:
Më pas, do të na duhet gjithashtu të vendosim shërbime që mbledhin metrikë bazuar në të cilat më vonë do të shkallëzojmë aplikacionin tonë të testimit. E para nga këto është Kubernetes metrics-server i cili zakonisht është i disponueshëm në grup si parazgjedhje, por ky nuk është rasti në KinD, kështu që për ta vendosur atë duhet të ekzekutojmë:
metrics-server na lejon të monitorojmë për metrikat bazë si CPU-ja dhe përdorimi i kujtesës, por duam gjithashtu të zbatojmë shkallëzim bazuar në metrika të personalizuara, si ato të ekspozuara nga një aplikacion në pikën fundore të tij /metrics, apo edhe ato të jashtme si thellësia e radhës së një radhe vrapimi jashtë grupit. Për këto do të na duhen:
- "Operatori Prometheus" për të mbledhur matjet me porosi/të jashtme.
- Objektet ServiceMonitor për t'i treguar Prometeut se si të gërvisht matjet e aplikacionit tonë.
- "Përshtatës Prometheus" për të marrë metrikë të personalizuar/të jashtëm nga shembulli i Prometheus në Kubernetes API.
Për më shumë detaje të konfigurimit, mund t'i referoheni "përcjelljes nga fundi në fund".
Sa më sipër kërkon shumë konfigurim, kështu që për qëllimin e këtij artikulli dhe për lehtësinë tuaj, unë kam bërë një skript dhe një grup manifestesh që mund t'i përdorni për të rrotulluar grupin KinD së bashku me të gjithë komponentët e kërkuar. E tëra çfarë ju duhet të bëni është të ekzekutoni skriptin setup.sh nga kjo depo.
Pas ekzekutimit të skriptit, ne mund të verifikojmë që gjithçka është gati duke përdorur komandat e mëposhtme:
Komandat më të dobishme mund të gjenden në daljen e skriptit të lartpërmendur ose në "magazinë README".
Autoscaling bazë
Tani që kemi infrastrukturën tonë në funksion, ne mund të fillojmë të shkallëzojmë aplikacionin e testimit. Mënyra më e thjeshtë për ta bërë këtë është të krijoni HPA duke përdorur komandën si kubectl autoscale deploy resource-consumer --min=1 --max=5 --cpu-percent=75, kjo megjithatë krijon HPA me apiVersion nga autoscaling/v1, të cilës i mungojnë shumica e veçorive.
Pra, në vend të kësaj, ne do të krijojmë HPA me YAML, duke specifikuar autoscaling/v2 si apiVersion:
HPA e mësipërme do të përdorë metrikat bazë të mbledhura nga Pod(et) e aplikacionit deri në metrics-server. Për të testuar shkallëzimin, ne mund të simulojmë përdorimin e rëndë të memories:
Metrikë të personalizuar
Shkallëzimi i bazuar në përdorimin e CPU-së dhe kujtesës është shpesh i mjaftueshëm, por ne jemi pas opsioneve të avancuara të shkallëzimit. E para prej tyre është shkallëzimi duke përdorur metrika të personalizuara të ekspozuara nga një aplikacion:
Ky HPA është konfiguruar për të shkallëzuar aplikacionin bazuar në vlerën e custom_metric që u gërvisht nga Prometheus nga pika fundore /metrics e aplikacionit. Kjo do ta rrisë aplikacionin nëse vlera mesatare e metrikës së specifikuar në të gjitha grupet (.target.type: AverageValue) shkon mbi 100.
Më sipër përdor metrikën Pod për t'u shkallëzuar, por është e mundur të specifikohet çdo objekt tjetër që ka një metrikë të bashkangjitur me vete:
Ky fragment arrin njësoj si ai i mëparshmi, megjithatë këtë herë, duke përdorur Shërbimi në vend të Pod si burim të metrikës. Gjithashtu tregon se mund të përdorni krahasimin e drejtpërdrejtë për të matur pragun e shkallëzimit duke vendosur .target.type në Value në vend të AverageValue.
Për të kuptuar se cilat objekte ekspozojnë metrikë që mund të përdorni në shkallëzim, mund të përshkoni API-në duke përdorur kubectl get --raw. Për shembull, për të kërkuar custom_metric për Pod ose Shërbimi mund të përdorni:
Gjithashtu, për t'ju ndihmuar të zgjidhni problemet, objekti HPA ofron një strofë statusi, që tregon nëse metrika e aplikuar është njohur:
Së fundi, për të testuar sjelljen e HPA-së së mësipërme, ne mund të përplasim metrikën e ekspozuar nga aplikacioni dhe të shohim se si aplikacioni rritet:
Metrika e jashtme
Për të treguar potencialin e plotë të HPA, ne do të përpiqemi gjithashtu të shkallëzojmë një aplikacion bazuar në metrikën e jashtme. Kjo do të kërkonte që ne të gërvishtim metrikat nga sistemi i jashtëm që funksionon jashtë një grupi, si Kafka ose PostgreSQL. Ne nuk e kemi atë në dispozicion, kështu që në vend të kësaj ne kemi konfiguruar përshtatësin Prometheus për të trajtuar metrika të caktuara si të jashtme. Konfigurimi që e bën këtë mund të gjendet "këtu". Gjithçka që duhet të dini është se me këtë grup testimi, çdo metrikë e aplikacionit e prefiksuar me external do të shkojë në API të metrikës së jashtme. Për ta testuar këtë, ne përmbledhim një metrikë të tillë dhe kontrollojmë nëse API plotësohet:
Për të shkallëzuar më pas vendosjen tonë bazuar në këtë metrikë, ne mund të përdorim HPA-në e mëposhtme:
HPAScaleToZero
Tani që kemi kaluar nëpër të gjitha tiparet e njohura të HPA, le të hedhim një vështrim edhe në ato alfa/beta që kemi aktivizuar duke përdorur portat e veçorive. I pari është HPAScaleToZero.
Siç sugjeron emri, kjo do t'ju lejojë të vendosni minReplicas në HPA në zero, duke e fikur në mënyrë efektive shërbimin nëse nuk ka trafik. Kjo mund të jetë e dobishme në rrjedhën e punës 'bursty', për shembull në rastin kur aplikacioni juaj merr të dhëna nga një radhë e jashtme. Në këtë rast përdorimi, aplikacioni mund të shkallëzohet në mënyrë të sigurt në zero kur ka mesazhe që presin për t'u përpunuar.
Me portën e veçorive të aktivizuar, ne thjesht mund të ekzekutojmë:
E cila vendos kopjet minimale të HPA-së së treguar më parë në zero.
Sidoqoftë, kini parasysh se kjo do të funksionojë vetëm për metrikat e type External ose Object.
HPAcontainerMetrics
Një portë tjetër veçori që ne mund të përdorim është HPAContainerMetrics e cila na lejon të përdorim metrikat e type: ContainerResource:
Kjo bën të mundur shkallëzimin bazuar në përdorimin e burimeve të kontejnerëve individualë dhe jo të POD-it të tërë. Kjo mund të jetë e dobishme nëse keni Pod me shumë kontejnerë me kontejner aplikacioni dhe karrige anësore, dhe dëshironi të injoroni karrigen anësore dhe të shkallëzoni vendosjen vetëm në bazë të kontejnerit të aplikacionit.
Ju gjithashtu mund të shikoni ndarjen e metrikës së Pod/kontejnerit duke ekzekutuar komandën e mëposhtme:
LogaritmikScaleDown
E fundit, por jo më pak e rëndësishme është flamuri i veçorisë LogarithmicScaleDown.
Pa këtë veçori, Pod që ka funksionuar për më pak kohë fshihet së pari gjatë zvogëlimit të shkallës. Kjo nuk është gjithmonë ideale, pasi mund të krijojë çekuilibër në shpërndarjen e kopjeve, sepse Pods më të reja priren të shërbejnë më pak trafik sesa ato më të vjetrat.
Me këtë flamur funksioni të aktivizuar, një përzgjedhje gjysmë e rastësishme e Pods do të përdoret në vend të kësaj kur zgjedh Pod që do të fshihet.
Për një arsyetim të plotë dhe detaje të algoritmit, shihni KEP-2189.
Mendime mbyllëse
Në këtë artikull, u përpoqa të mbuloja shumicën e gjërave që mund të bëni me Kubernetes HPA për të shkallëzuar aplikacionin tuaj. Megjithatë, ka shumë mjete dhe opsione të tjera për shkallëzimin e aplikacioneve që ekzekutohen në Kubernetes, si "vertical pod autoscaler" i cili mund të ndihmojë në mbajtjen e përditësuar të kërkesave dhe kufijve të burimeve të Pod.
Një opsion tjetër do të ishte HPA parashikuese nga Digital Ocean, i cili do të përpiqet të parashikojë se sa kopje duhet të ketë një burim dhe një aplikacion.
Më në fund, shkallëzimi automatik nuk përfundon me Pods - hapi tjetër pas konfigurimit të shkallëzimit automatik të Pod është të konfiguroni gjithashtu "shkallëzim automatik të grupit" për të shmangur mbarimin e burimeve të disponueshme në të gjithë grupin tuaj.
Want to Connect? This article was originally posted at martinheinz.dev
