Da biste u potpunosti savladali Kubernetes, morate znati različite načine za skaliranje resursa klastera: pomoću , ovo je jedan od glavnih zadataka Kubernetesa. Dali smo pregled visokog nivoa horizontalnog i vertikalnog automatskog skaliranja i mehanizama za promjenu veličine klastera, kao i preporuke o tome kako ih efikasno koristiti.
Članak preveo tim koji je implementirao automatsko skaliranje u .
Zašto je važno razmišljati o skaliranju
- alat za upravljanje resursima i orkestraciju. Naravno, lijepo je pozabaviti se odličnim karakteristikama postavljanja, nadgledanja i upravljanja podovima (pod je grupa kontejnera koji se pokreću kao odgovor na zahtjev).
Međutim, trebali biste razmisliti i o sljedećim pitanjima:
- Kako skalirati module i aplikacije?
- Kako da kontejneri budu operativni i efikasni?
- Kako odgovoriti na stalne promjene koda i opterećenja korisnika?
Konfigurisanje Kubernetes klastera za balansiranje između resursa i performansi može biti izazovno i zahteva stručno znanje o unutrašnjem radu Kubernetesa. Radno opterećenje vaše aplikacije ili usluga može varirati tokom dana ili čak tokom jednog sata, tako da je balansiranje najbolje smatrati stalnim procesom.
Nivoi automatskog skaliranja Kubernetesa
Učinkovito automatsko skaliranje zahtijeva koordinaciju između dva nivoa:
- Nivo pod, uključujući horizontalni (Horizontal Pod Autoscaler, HPA) i vertikalni autoscaler (Vertical Pod Autoscaler, VPA). Ovo je skaliranje dostupnih resursa za vaše kontejnere.
- Nivo klastera, kojim upravlja Cluster Autoscaler (CA), koji povećava ili smanjuje broj čvorova unutar klastera.
Horizontalni Autoscaler (HPA) modul
Kao što ime govori, HPA skalira broj replika mahuna. Većina devopova koristi CPU i opterećenje memorije kao okidače za promjenu broja replika. Međutim, moguće je skalirati sistem na osnovu , njihov ili čak .
Radni dijagram HPA visokog nivoa:
- HPA kontinuirano provjerava metričke vrijednosti navedene tokom instalacije u zadanom intervalu od 30 sekundi.
- HPA pokušava povećati broj modula ako je dostignut specificirani prag.
- HPA ažurira broj replika unutar kontrolera implementacije/replikacije.
- Kontrolor implementacije/replikacije tada postavlja sve potrebne dodatne module.
HPA pokreće proces postavljanja modula kada se dostigne metrički prag
Kada koristite HPA, uzmite u obzir sljedeće:
- Zadani interval HPA provjere je 30 sekundi. Postavlja se zastavom horizontal-pod-autoscaler-sync-period u menadžeru kontrolera.
- Zadana relativna greška je 10%.
- Nakon posljednjeg povećanja broja modula, HPA očekuje da će se metrika stabilizirati u roku od tri minute. Ovaj interval je postavljen zastavicom horizontal-pod-autoscaler-upscale-delay.
- Nakon posljednjeg smanjenja broja modula, HPA čeka pet minuta da se stabilizuje. Ovaj interval je postavljen zastavicom horizontal-pod-autoscaler-downscale-delay.
- HPA najbolje radi s objektima implementacije, a ne s kontrolerima replikacije. Horizontalno automatsko skaliranje nije kompatibilno sa ažuriranim ažuriranjem, koje direktno manipulira kontrolerima replikacije. Kod implementacije, broj replika direktno ovisi o objektima implementacije.
Vertikalno automatsko skaliranje mahuna
Vertikalno automatsko skaliranje (VPA) dodeljuje više (ili manje) CPU vremena ili memorije postojećim podovima. Pogodno za podove sa statusom ili bez državljanstva, ali uglavnom namijenjeno za usluge s statusom. Međutim, možete koristiti i VPA za module bez stanja ako trebate automatski prilagoditi količinu inicijalno dodijeljenih resursa.
VPA takođe odgovara na događaje OOM (nedostaje memorije). Promjena CPU vremena i memorije zahtijeva ponovno pokretanje podova. Kada se ponovo pokrene, VPA poštuje budžet alokacije () kako bi se jamčio minimalni potreban broj modula.
Možete postaviti minimalne i maksimalne resurse za svaki modul. Tako možete ograničiti maksimalnu količinu dodijeljene memorije na 8 GB. Ovo je korisno ako trenutni čvorovi definitivno ne mogu dodijeliti više od 8 GB memorije po kontejneru. Detaljne specifikacije i radni mehanizam opisani su u .
Osim toga, VPA ima zanimljivu funkciju preporuke (VPA Recommender). On prati korištenje resursa i OOM događaje svih modula kako bi predložio nove vrijednosti memorije i CPU vremena na osnovu inteligentnog algoritma zasnovanog na historijskim metrikama. Postoji i API koji uzima pod handle i vraća predložene vrijednosti resursa.
Vrijedi napomenuti da VPA Recommender ne prati "ograničenje" resursa. Ovo može dovesti do toga da modul monopolizira resurse unutar čvorova. Bolje je postaviti ograničenje na nivou imenskog prostora kako bi se izbjegla velika potrošnja memorije ili CPU-a.
Šema rada VPA visokog nivoa:
- VPA kontinuirano provjerava metričke vrijednosti navedene tokom instalacije u zadanom intervalu od 10 sekundi.
- Ako se dostigne navedeni prag, VPA pokušava promijeniti dodijeljenu količinu resursa.
- VPA ažurira broj resursa unutar kontrolera implementacije/replikacije.
- Kada se moduli ponovo pokrenu, svi novi resursi se primjenjuju na kreirane instance.
VPA dodaje potrebnu količinu resursa
Imajte na umu sljedeće tačke kada koristite VPA:
- Skaliranje zahtijeva obavezno ponovno pokretanje modula. Ovo je neophodno kako bi se izbjegao nestabilan rad nakon unošenja izmjena. Radi pouzdanosti, moduli se ponovo pokreću i distribuiraju po čvorovima na osnovu novododijeljenih resursa.
- VPA i HPA još nisu međusobno kompatibilni i ne mogu raditi na istim podovima. Ako koristite oba mehanizma skaliranja u istom klasteru, uvjerite se da vaše postavke sprječavaju njihovo aktiviranje na istim objektima.
- VPA prilagođava zahtjeve kontejnera za resurse samo na osnovu prethodne i trenutne upotrebe. Ne postavlja ograničenja upotrebe resursa. Može doći do problema s aplikacijama koje ne rade ispravno i počnu preuzimati sve više resursa, što će dovesti do toga da Kubernetes isključi ovaj pod.
- VPA je još uvijek u ranoj fazi razvoja. Budite spremni da sistem može pretrpjeti neke promjene u bliskoj budućnosti. Možete čitati o tome и . Dakle, postoje planovi za implementaciju zajedničkog rada VPA i HPA, kao i postavljanje modula zajedno sa politikom vertikalnog automatskog skaliranja za njih (na primjer, posebna oznaka 'zahtijeva VPA').
Automatsko skaliranje Kubernetes klastera
Cluster Autoscaler (CA) mijenja broj čvorova na osnovu broja podova na čekanju. Sistem periodično proverava da li postoje moduli na čekanju - i povećava veličinu klastera ako je potrebno više resursa i ako klaster ne prelazi postavljena ograničenja. CA komunicira s dobavljačem usluga u oblaku, zahtijeva dodatne čvorove od njega ili oslobađa neaktivne. Prva opšte dostupna verzija CA predstavljena je u Kubernetesu 1.8.
Šema visokog nivoa rada SA:
- CA provjerava module na čekanju u zadanom intervalu od 10 sekundi.
- Ako je jedan ili više podova u stanju pripravnosti jer klaster nema dovoljno raspoloživih resursa da ih dodijeli, pokušava osigurati jedan ili više dodatnih čvorova.
- Kada dobavljač usluga u oblaku dodijeli potrebni čvor, on se pridružuje klasteru i spreman je za opsluživanje podova.
- Kubernetes planer distribuira podove na čekanju novom čvoru. Ako nakon ovoga neki moduli i dalje ostanu u stanju čekanja, proces se ponavlja i novi čvorovi se dodaju u klaster.
Automatsko obezbjeđivanje čvorova klastera u oblaku
Uzmite u obzir sljedeće kada koristite CA:
- CA osigurava da svi podovi u klasteru imaju prostora za pokretanje, bez obzira na opterećenje CPU-a. Također pokušava osigurati da u klasteru nema nepotrebnih čvorova.
- CA registruje potrebu za skaliranjem nakon otprilike 30 sekundi.
- Jednom kada čvor više nije potreban, CA po defaultu čeka 10 minuta prije skaliranja sistema.
- Sistem za automatsko skaliranje ima koncept ekspandera. Ovo su različite strategije za odabir grupe čvorova u koje će se dodati novi čvorovi.
- Koristite ovu opciju odgovorno cluster-autoscaler.kubernetes.io/safe-to-evict (true). Ako instalirate puno podova ili ako je mnogo njih razbacano po svim čvorovima, u velikoj mjeri ćete izgubiti mogućnost skaliranja klastera.
- Koristite kako biste spriječili brisanje podova, što bi moglo uzrokovati da se dijelovi vaše aplikacije potpuno pokvare.
Kako Kubernetes automatski skaleri međusobno djeluju
Za savršenu harmoniju, automatsko skaliranje treba primijeniti i na nivou pod (HPA/VPA) i na nivou klastera. Oni međusobno komuniciraju relativno jednostavno:
- HPA ili VPA ažuriraju replike modula ili resurse dodijeljene postojećim podovima.
- Ako nema dovoljno čvorova za planirano skaliranje, CA primjećuje prisustvo podova u stanju čekanja.
- CA dodjeljuje nove čvorove.
- Moduli se distribuiraju novim čvorovima.
Kolaborativni Kubernetes scale-out sistem
Uobičajene greške u Kubernetes automatskom skaliranju
Postoji nekoliko uobičajenih problema na koje devops nailazi kada pokušava implementirati automatsko skaliranje.
HPA i VPA zavise od metrike i nekih istorijskih podataka. Ako se dodijele nedovoljni resursi, moduli će biti minimizirani i neće moći generirati metriku. U ovom slučaju, automatsko skaliranje se nikada neće dogoditi.
Sama operacija skaliranja je vremenski osjetljiva. Želimo da se moduli i klaster brzo skaliraju - prije nego što korisnici primjete bilo kakve probleme ili kvarove. Stoga treba uzeti u obzir prosječno vrijeme za skaliranje mahuna i klastera.
Idealan scenario - 4 minute:
- 30 sekundi. Ažuriranje ciljnih metrika: 30-60 sekundi.
- 30 sekundi. HPA provjerava metričke vrijednosti: 30 sekundi.
- Manje od 2 sekunde. Podovi se kreiraju i prelaze u stanje čekanja: 1 sekunda.
- Manje od 2 sekunde. CA vidi module na čekanju i šalje pozive čvorovima za obezbjeđivanje: 1 sekunda.
- 3 minute. Dobavljač oblaka dodjeljuje čvorove. K8s čeka dok ne budu spremni: do 10 minuta (u zavisnosti od nekoliko faktora).
Najgori (realističniji) scenario - 12 minuta:
- 30 sekundi. Ažurirajte ciljne metrike.
- 30 sekundi. HPA provjerava metričke vrijednosti.
- Manje od 2 sekunde. Podovi se kreiraju i ulaze u stanje pripravnosti.
- Manje od 2 sekunde. CA vidi module na čekanju i upućuje pozive za obezbjeđivanje čvorova.
- 10 minuta. Dobavljač oblaka dodjeljuje čvorove. K8s čeka dok ne budu spremni. Vrijeme čekanja ovisi o nekoliko faktora, kao što su kašnjenje dobavljača, kašnjenje OS-a i alati za podršku.
Nemojte brkati mehanizme skaliranja dobavljača oblaka s našim CA. Potonji radi unutar Kubernetes klastera, dok mehanizam dobavljača oblaka radi na bazi distribucije čvorova. Ne zna šta se dešava sa vašim podovima ili aplikacijom. Ovi sistemi rade paralelno.
Kako upravljati skaliranjem u Kubernetesu
- Kubernetes je alat za upravljanje resursima i orkestraciju. Operacije za upravljanje podovima i resursima klastera su ključna prekretnica u savladavanju Kubernetesa.
- Shvatite logiku pod skalabilnosti uzimajući u obzir HPA i VPA.
- CA bi se trebao koristiti samo ako dobro razumijete potrebe vaših mahuna i kontejnera.
- Da biste optimalno konfigurirali klaster, morate razumjeti kako različiti sistemi skaliranja rade zajedno.
- Kada procjenjujete vrijeme skaliranja, imajte na umu najgori i najbolji scenarij.
izvor: www.habr.com