Da biste u potpunosti ovladali Kubernetesom, trebate znati različite načine skaliranja resursa klastera: putem , ovo je jedan od glavnih zadataka Kubernetesa. Pružili smo pregled na visokoj razini horizontalnog i vertikalnog automatskog skaliranja i mehanizama za promjenu veličine klastera, kao i preporuke o tome kako ih učinkovito 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 petljati se sa cool značajkama postavljanja, nadzora i upravljanja podovima (pod je grupa spremnika koji se pokreću kao odgovor na zahtjev).
Međutim, također biste trebali razmisliti o sljedećim pitanjima:
- Kako skalirati module i aplikacije?
- Kako održati spremnike operativnim i učinkovitim?
- Kako odgovoriti na stalne promjene koda i radna opterećenja korisnika?
Konfiguriranje Kubernetes klastera za uravnoteženje resursa i performansi može biti izazovno i zahtijeva stručno znanje o unutarnjem radu Kubernetesa. Radno opterećenje vaše aplikacije ili usluga može varirati tijekom dana ili čak tijekom jednog sata, tako da je balansiranje najbolje smatrati trajnim procesom.
Kubernetesove razine automatskog skaliranja
Učinkovito automatsko skaliranje zahtijeva koordinaciju između dvije razine:
- Razina bloka, uključujući horizontalni (Horizontal Pod Autoscaler, HPA) i okomiti autoscaler (Vertical Pod Autoscaler, VPA). Ovo je skaliranje dostupnih resursa za vaše spremnike.
- Razina klastera, kojom upravlja Cluster Autoscaler (CA), koji povećava ili smanjuje broj čvorova unutar klastera.
Horizontalni autoscaler (HPA) modul
Kao što ime sugerira, HPA skalira broj replika mahuna. Većina devopsa koristi CPU i opterećenje memorije kao okidače za promjenu broja replika. Međutim, moguće je skalirati sustav na temelju , njih ili čak .
HPA radni dijagram visoke razine:
- HPA kontinuirano provjerava metričke vrijednosti navedene tijekom instalacije u zadanom intervalu od 30 sekundi.
- HPA pokušava povećati broj modula ako se dosegne navedeni prag.
- HPA ažurira broj replika unutar kontrolera implementacije/replikacije.
- Kontroler postavljanja/replikacije zatim postavlja sve potrebne dodatne module.
HPA pokreće proces postavljanja modula kada se dosegne metrički prag
Kada koristite HPA, uzmite u obzir sljedeće:
- Zadani HPA interval provjere je 30 sekundi. Postavlja se zastavom horizontalni-pod-autoscaler-period-sync u upravitelju kontrolera.
- Zadana relativna pogreška je 10%.
- Nakon zadnjeg povećanja broja modula, HPA očekuje da će se metrika stabilizirati unutar tri minute. Ovaj interval je postavljen zastavom vodoravno-pod-autoscaler-upscale-odgoda.
- Nakon posljednjeg smanjenja broja modula, HPA čeka pet minuta da se stabilizira. Ovaj interval je postavljen zastavom horizontalna-pod-autoscaler-downscale-delay.
- HPA najbolje radi s objektima za implementaciju, a ne s kontrolerima replikacije. Horizontalno automatsko skaliranje nije kompatibilno s tekućim ažuriranjem, koje izravno manipulira kontrolerima replikacije. Uz implementaciju, broj replika izravno ovisi o objektima implementacije.
Vertikalno automatsko skaliranje mahuna
Okomito automatsko skaliranje (VPA) dodjeljuje više (ili manje) CPU vremena ili memorije postojećim modulima. Prikladno za module s statusom ili bez statusa, ali uglavnom namijenjeno za usluge s statusom. Međutim, možete također koristiti VPA za module bez statusa ako trebate automatski prilagoditi količinu izvorno dodijeljenih resursa.
VPA također reagira na događaje OOM (out of memory). Promjena CPU vremena i memorije zahtijeva ponovno pokretanje modula. Kada se ponovno pokrene, VPA poštuje proračun za dodjelu () kako bi se zajamčio minimalni potreban broj modula.
Možete postaviti minimalne i maksimalne resurse za svaki modul. Stoga 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 spremniku. Detaljne specifikacije i radni mehanizam opisani su u .
Osim toga, VPA ima zanimljivu funkciju preporuke (VPA Recommender). Nadzire korištenje resursa i OOM događaje svih modula kako bi predložio nove vrijednosti memorije i CPU vremena na temelju inteligentnog algoritma temeljenog na povijesnim metrikama. Tu je i API koji preuzima rukovatelj pod i vraća predložene vrijednosti resursa.
Vrijedno je napomenuti da VPA Recommender ne prati "ograničenje" resursa. To može rezultirati time da modul monopolizira resurse unutar čvorova. Bolje je postaviti ograničenje na razini imenskog prostora kako biste izbjegli veliku potrošnju memorije ili procesora.
VPA radna shema visoke razine:
- VPA kontinuirano provjerava metričke vrijednosti navedene tijekom instalacije u zadanom intervalu od 10 sekundi.
- Ako se dosegne navedeni prag, VPA pokušava promijeniti dodijeljenu količinu resursa.
- VPA ažurira broj resursa unutar kontrolera implementacije/replikacije.
- Kada se moduli ponovno pokrenu, svi novi resursi primjenjuju se na stvorene instance.
VPA dodaje potrebnu količinu resursa
Prilikom korištenja VPA imajte na umu sljedeće:
- Skaliranje zahtijeva obavezno ponovno pokretanje modula. Ovo je neophodno kako bi se izbjegao nestabilan rad nakon unošenja promjena. Radi pouzdanosti, moduli se ponovno pokreću i distribuiraju po čvorovima na temelju novododijeljenih resursa.
- VPA i HPA još nisu međusobno kompatibilni i ne mogu raditi na istim modulima. Ako koristite oba mehanizma skaliranja u istom klasteru, provjerite sprječavaju li vaše postavke njihovu aktivaciju na istim objektima.
- VPA prilagođava zahtjeve spremnika za resurse samo na temelju prethodne i trenutne upotrebe. Ne postavlja ograničenja korištenja resursa. Mogu postojati problemi s aplikacijama koje ne rade ispravno i počinju preuzimati sve više i više resursa, što će dovesti do toga da Kubernetes isključi ovaj modul.
- VPA je još uvijek u ranoj fazi razvoja. Budite spremni da bi sustav mogao doživjeti neke promjene u bliskoj budućnosti. Možete čitati o и . Stoga se planira implementacija zajedničkog rada VPA i HPA, kao i implementacija modula zajedno s politikom vertikalnog automatskog skaliranja za njih (na primjer, posebna oznaka 'zahtijeva VPA').
Automatsko skaliranje Kubernetes klastera
Cluster Autoscaler (CA) mijenja broj čvorova na temelju broja blokova koji čekaju. Sustav povremeno provjerava module na čekanju - i povećava veličinu klastera ako je potrebno više resursa i ako klaster ne premašuje utvrđena ograničenja. CA komunicira s pružateljem usluga u oblaku, od njega zahtijeva dodatne čvorove ili oslobađa neaktivne. Prva općenito dostupna verzija CA predstavljena je u Kubernetesu 1.8.
Shema rada SA na visokoj razini:
- CA provjerava module na čekanju u zadanom intervalu od 10 sekundi.
- Ako su jedan ili više podova u stanju pripravnosti jer klaster nema dovoljno dostupnih resursa za njihovu dodjelu, pokušava osigurati jedan ili više dodatnih čvorova.
- Kada pružatelj usluga u oblaku dodijeli potreban čvor, on se pridružuje klasteru i spreman je za posluživanje podova.
- Kubernetes planer distribuira blokove na čekanju u novi čvor. Ako nakon toga neki moduli i dalje ostanu u stanju čekanja, proces se ponavlja i novi čvorovi se dodaju u klaster.
Automatsko dodjeljivanje čvorova klastera u oblaku
Uzmite u obzir sljedeće kada koristite CA:
- CA osigurava da svi moduli u klasteru imaju prostora za rad, bez obzira na opterećenje CPU-a. Također pokušava osigurati da u klasteru nema nepotrebnih čvorova.
- CA registrira potrebu za skaliranjem nakon približno 30 sekundi.
- Nakon što čvor više nije potreban, CA prema zadanim postavkama čeka 10 minuta prije skaliranja sustava.
- Sustav automatskog skaliranja ima koncept ekspandera. Ovo su različite strategije za odabir grupe čvorova kojima će se dodati novi čvorovi.
- Koristite opciju odgovorno cluster-autoscaler.kubernetes.io/safe-to-evict (true). Ako instalirate puno podova ili ako su mnogi od njih razbacani po svim čvorovima, uvelike ćete izgubiti mogućnost skaliranja klastera.
- upotreba kako biste spriječili brisanje podova, što bi moglo uzrokovati potpuni otkaz dijelova vaše aplikacije.
Kako Kubernetes autoscaleri međusobno djeluju
Za savršenu harmoniju, automatsko skaliranje treba primijeniti i na razini mahuna (HPA/VPA) i na razini klastera. Međusobno međusobno djeluju relativno jednostavno:
- HPA ili VPA ažuriraju replike podova ili resurse dodijeljene postojećim podovima.
- Ako nema dovoljno čvorova za planirano skaliranje, CA primjećuje prisutnost podova u stanju čekanja.
- CA dodjeljuje nove čvorove.
- Moduli se distribuiraju novim čvorovima.
Kolaborativni Kubernetes skalirani sustav
Uobičajene pogreške u Kubernetes automatskom skaliranju
Postoji nekoliko uobičajenih problema na koje devops nailazi kada pokušava implementirati automatsko skaliranje.
HPA i VPA ovise o mjernim podacima i nekim povijesnim podacima. Ako se dodijeli nedovoljno resursa, 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 primijete probleme ili kvarove. Stoga treba uzeti u obzir prosječno vrijeme skaliranja za mahune i grozd.
Idealan scenarij - 4 minute:
- 30 sekundi. Ažuriraj ciljane metrike: 30-60 sekundi.
- 30 sekundi. HPA provjerava metričke vrijednosti: 30 sekundi.
- Manje od 2 sekunde. Podovi se stvaraju i prelaze u stanje čekanja: 1 sekunda.
- Manje od 2 sekunde. CA vidi module koji čekaju i šalje pozive čvorovima za pružanje usluga: 1 sekunda.
- 3 minute. Pružatelj usluge oblaka dodjeljuje čvorove. K8s čeka dok ne budu spremni: do 10 minuta (ovisno o nekoliko čimbenika).
Najgori mogući (realniji) scenarij - 12 minuta:
- 30 sekundi. Ažurirajte ciljane metrike.
- 30 sekundi. HPA provjerava metričke vrijednosti.
- Manje od 2 sekunde. Podovi se stvaraju i ulaze u stanje pripravnosti.
- Manje od 2 sekunde. CA vidi module koji čekaju i upućuje pozive za dodjelu čvorova.
- 10 minuta. Pružatelj usluge oblaka dodjeljuje čvorove. K8s čeka dok ne budu spremni. Vrijeme čekanja ovisi o nekoliko čimbenika, kao što su kašnjenje dobavljača, kašnjenje OS-a i alati za podršku.
Ne brkajte mehanizme skaliranja pružatelja usluga oblaka s našim CA-om. Potonji radi unutar Kubernetes klastera, dok mehanizam pružatelja usluga oblaka radi na osnovi distribucije čvorova. Ne zna što se događa s vašim podovima ili aplikacijom. Ovi sustavi rade paralelno.
Kako upravljati skaliranjem u Kubernetesu
- Kubernetes je alat za upravljanje resursima i orkestraciju. Operacije za upravljanje podovima i resursima klastera ključna su prekretnica u svladavanju Kubernetesa.
- Razumjeti logiku skalabilnosti bloka uzimajući u obzir HPA i VPA.
- CA treba koristiti samo ako dobro razumijete potrebe svojih mahuna i spremnika.
- Da biste optimalno konfigurirali klaster, morate razumjeti kako različiti sustavi skaliranja rade zajedno.
- Kada procjenjujete vrijeme skaliranja, imajte na umu najgori i najbolji scenarij.
Izvor: www.habr.com