Per dominar completament Kubernetes, heu de conèixer diferents maneres d'escalar els recursos del clúster: per , aquesta és una de les principals tasques de Kubernetes. Hem proporcionat una visió general d'alt nivell dels mecanismes d'escala automàtica horitzontal i vertical i de canvi de mida del clúster, així com recomanacions sobre com utilitzar-los de manera eficaç.
Article traduït per l'equip que va implementar l'escala automàtica .
Per què és important pensar en l'escala
- una eina per a la gestió i l'orquestració de recursos. Per descomptat, és bo jugar amb les característiques interessants de desplegament, supervisió i gestió de pods (un pod és un grup de contenidors que es llancen en resposta a una sol·licitud).
Tanmateix, també hauríeu de pensar en les preguntes següents:
- Com escalar mòduls i aplicacions?
- Com mantenir els contenidors operatius i eficients?
- Com respondre als canvis constants de codi i càrregues de treball dels usuaris?
Configurar clústers de Kubernetes per equilibrar els recursos i el rendiment pot ser un repte i requereix un coneixement expert del funcionament intern de Kubernetes. La càrrega de treball de la vostra aplicació o serveis pot fluctuar al llarg del dia o fins i tot al llarg d'una hora, de manera que l'equilibri es pensa millor com un procés continu.
Nivells d'escalat automàtic de Kubernetes
L'autoescala eficaç requereix una coordinació entre dos nivells:
- Nivell de pod, inclòs l'autoescalador horitzontal (Horizontal Pod Autoscaler, HPA) i vertical (Vertical Pod Autoscaler, VPA). Això és escalar els recursos disponibles per als vostres contenidors.
- Nivell de clúster, que és gestionat per Cluster Autoscaler (CA), que augmenta o disminueix el nombre de nodes dins del clúster.
Mòdul Horizontal Autoscaler (HPA).
Com el seu nom indica, HPA escala el nombre de rèpliques de pod. La majoria de devops utilitzen la CPU i la càrrega de memòria com a activadors per canviar el nombre de rèpliques. Tanmateix, és possible escalar el sistema basant-se en , els seus o .
Diagrama de funcionament d'HPA d'alt nivell:
- L'HPA comprova contínuament els valors mètrics especificats durant la instal·lació en un interval predeterminat de 30 segons.
- L'HPA intenta augmentar el nombre de mòduls si s'arriba al llindar especificat.
- L'HPA actualitza el nombre de rèpliques dins del controlador de desplegament/rèplica.
- A continuació, el controlador de desplegament/replicació desplega els mòduls addicionals necessaris.
HPA inicia el procés de desplegament del mòdul quan s'arriba a un llindar de mètrica
Quan utilitzeu HPA, tingueu en compte el següent:
- L'interval de comprovació HPA predeterminat és de 30 segons. El posa la bandera horitzontal-pod-autoscaler-període de sincronització al gestor del controlador.
- L'error relatiu predeterminat és del 10%.
- Després de l'últim augment del nombre de mòduls, HPA espera que les mètriques s'estabilitzin en tres minuts. Aquest interval el defineix la bandera horitzontal-pod-autoscaler-upscale-delay.
- Després de l'última reducció del nombre de mòduls, l'HPA espera cinc minuts per estabilitzar-se. Aquest interval el defineix la bandera horitzontal-pod-autoscaler-downscale-delay.
- HPA funciona millor amb objectes de desplegament que amb controladors de rèplica. L'escalat automàtic horitzontal és incompatible amb l'actualització continua, que manipula directament els controladors de rèplica. Amb el desplegament, el nombre de rèpliques depèn directament dels objectes de desplegament.
Autoescala vertical de beines
L'escala automàtica vertical (VPA) assigna més (o menys) temps de CPU o memòria als pods existents. Adequat per a pods amb estat o sense estat, però principalment destinat a serveis amb estat. Tanmateix, també podeu utilitzar VPA per a mòduls sense estat si necessiteu ajustar automàticament la quantitat de recursos assignats inicialment.
El VPA també respon als esdeveniments OOM (fora de memòria). Canviar el temps de la CPU i la memòria requereix reiniciar els pods. Quan es reinicia, l'AVA respecta el pressupost d'assignació () per garantir el nombre mínim exigit de mòduls.
Podeu establir els recursos mínims i màxims per a cada mòdul. Així, podeu limitar la quantitat màxima de memòria assignada a 8 GB. Això és útil si els nodes actuals definitivament no poden assignar més de 8 GB de memòria per contenidor. Les especificacions detallades i el mecanisme de funcionament es descriuen a .
A més, VPA té una interessant funció de recomanació (VPA Recommender). Supervisa l'ús de recursos i els esdeveniments OOM de tots els mòduls per suggerir nous valors de memòria i temps de CPU basats en un algorisme intel·ligent basat en mètriques històriques. També hi ha una API que pren un controlador de pod i retorna els valors de recursos suggerits.
Val la pena assenyalar que el recomanador VPA no fa un seguiment del "límit" dels recursos. Això pot provocar que el mòdul monopolitzi els recursos dins dels nodes. És millor establir el límit a nivell d'espai de noms per evitar un gran consum de memòria o CPU.
Esquema d'operació VPA d'alt nivell:
- VPA comprova contínuament els valors mètrics especificats durant la instal·lació en un interval predeterminat de 10 segons.
- Si s'arriba al llindar especificat, el VPA intenta canviar la quantitat de recursos assignada.
- El VPA actualitza el nombre de recursos dins del controlador de desplegament/replicació.
- Quan es reinicien els mòduls, tots els recursos nous s'apliquen a les instàncies creades.
VPA afegeix la quantitat necessària de recursos
Si us plau, tingueu en compte els punts següents quan feu servir VPA:
- L'escala requereix un reinici obligatori del pod. Això és necessari per evitar un funcionament inestable després de fer canvis. Per fiabilitat, els mòduls es reinicien i es distribueixen entre nodes en funció dels recursos assignats recentment.
- VPA i HPA encara no són compatibles entre si i no poden funcionar als mateixos pods. Si utilitzeu els dos mecanismes d'escala al mateix clúster, assegureu-vos que la vostra configuració impedeix que s'activin als mateixos objectes.
- VPA ajusta les sol·licituds de contenidors de recursos en funció només de l'ús passat i actual. No estableix límits d'ús de recursos. Pot haver-hi problemes amb les aplicacions que no funcionen correctament i comencen a agafar més i més recursos, això farà que Kubernetes desactivi aquest pod.
- El VPA encara es troba en una fase inicial de desenvolupament. Estigueu preparats perquè el sistema pugui experimentar alguns canvis en un futur proper. Podeu llegir sobre и . Així, es preveu implementar el funcionament conjunt de VPA i HPA, així com el desplegament de mòduls juntament amb una política d'autoescala vertical per a ells (per exemple, una etiqueta especial "requereix VPA").
Escala automàtica d'un clúster de Kubernetes
Cluster Autoscaler (CA) canvia el nombre de nodes en funció del nombre de pods en espera. El sistema comprova periòdicament els mòduls pendents i augmenta la mida del clúster si es necessiten més recursos i si el clúster no supera els límits establerts. L'AC es comunica amb el proveïdor de serveis al núvol, li sol·licita nodes addicionals o n'allibera els inactius. La primera versió generalment disponible de CA es va introduir a Kubernetes 1.8.
Esquema d'alt nivell d'operació SA:
- CA comprova si hi ha mòduls en estat pendent amb un interval predeterminat de 10 segons.
- Si un o més pods es troben en estat d'espera perquè el clúster no té prou recursos disponibles per assignar-los, prova de subministrar un o més nodes addicionals.
- Quan el proveïdor de serveis al núvol assigna el node necessari, s'uneix al clúster i està preparat per servir els pods.
- El planificador de Kubernetes distribueix pods pendents al nou node. Si després d'això alguns mòduls encara romanen en un estat d'espera, el procés es repeteix i s'afegeixen nous nodes al clúster.
Provisionament automàtic de nodes de clúster al núvol
Tingueu en compte el següent quan feu servir CA:
- CA garanteix que tots els pods del clúster tinguin espai per executar-se, independentment de la càrrega de la CPU. També intenta assegurar-se que no hi hagi nodes innecessaris al clúster.
- CA registra la necessitat d'escalar després d'aproximadament 30 segons.
- Quan ja no es necessita un node, l'AC per defecte espera 10 minuts abans d'escalar el sistema.
- El sistema d'escalat automàtic té el concepte d'expansors. Es tracta d'estratègies diferents per seleccionar un grup de nodes als quals s'afegiran nous nodes.
- Utilitzeu l'opció de manera responsable cluster-autoscaler.kubernetes.io/safe-to-evict (true). Si instal·leu molts pods, o si molts d'ells estan dispersos per tots els nodes, perdreu en gran mesura la capacitat d'escalar el clúster.
- ús per evitar que s'eliminin els pods, cosa que podria provocar que parts de la vostra aplicació es trenquin completament.
Com interactuen els escaladors automàtics de Kubernetes entre ells
Per a una harmonia perfecta, l'escalat automàtic s'ha d'aplicar tant a nivell de pod (HPA/VPA) com a nivell de clúster. Interaccionen entre ells de manera relativament senzilla:
- Els HPA o VPA actualitzen les rèpliques dels pods o els recursos assignats als pods existents.
- Si no hi ha prou nodes per a l'escalat previst, l'AC nota la presència de pods en estat d'espera.
- L'AC assigna nous nodes.
- Els mòduls es distribueixen a nous nodes.
Sistema col·laboratiu d'escalada horizontal de Kubernetes
Errors comuns en l'escala automàtica de Kubernetes
Hi ha diversos problemes comuns amb els quals es troben els devops quan intenten implementar l'escala automàtica.
HPA i VPA depenen de mètriques i algunes dades històriques. Si no s'assignen recursos suficients, els mòduls es minimitzaran i no podran generar mètriques. En aquest cas, l'escala automàtica mai es produirà.
L'operació d'escala en si és sensible al temps. Volem que els mòduls i el clúster s'escalin ràpidament, abans que els usuaris notin cap problema o fallada. Per tant, s'ha de tenir en compte el temps mitjà d'escala per a les beines i el clúster.
Escenari ideal - 4 minuts:
- 30 segons. Actualitza les mètriques de l'objectiu: 30-60 segons.
- 30 segons. HPA comprova els valors mètrics: 30 segons.
- Menys de 2 segons. Els pods es creen i passen a l'estat d'espera: 1 segon.
- Menys de 2 segons. CA veu mòduls en espera i envia trucades als nodes de subministrament: 1 segon.
- 3 minuts. El proveïdor de núvol assigna nodes. Els K8 espera fins que estiguin a punt: fins a 10 minuts (depenent de diversos factors).
El pitjor dels casos (més realista) - 12 minuts:
- 30 segons. Actualitza les mètriques d'objectiu.
- 30 segons. HPA comprova els valors mètrics.
- Menys de 2 segons. Els pods es creen i entren a l'estat d'espera.
- Menys de 2 segons. La CA veu els mòduls en espera i fa trucades per subministrar els nodes.
- 10 minuts. El proveïdor de núvol assigna nodes. Els K8 espera fins que estiguin a punt. El temps d'espera depèn de diversos factors, com ara el retard del proveïdor, el retard del sistema operatiu i les eines de suport.
No confongueu els mecanismes d'escala dels proveïdors de núvol amb la nostra CA. Aquest últim s'executa dins d'un clúster de Kubernetes, mentre que el motor del proveïdor de núvol funciona sobre una base de distribució de nodes. No sap què està passant amb els vostres pods o aplicació. Aquests sistemes funcionen en paral·lel.
Com gestionar l'escala a Kubernetes
- Kubernetes és una eina d'orquestració i gestió de recursos. Les operacions per gestionar pods i recursos de clúster són una fita clau per dominar Kubernetes.
- Entendre la lògica de l'escalabilitat del pod tenint en compte HPA i VPA.
- CA només s'ha d'utilitzar si coneixeu bé les necessitats de les vostres beines i contenidors.
- Per configurar de manera òptima un clúster, heu d'entendre com funcionen conjuntament els diferents sistemes d'escala.
- A l'hora d'estimar el temps d'escalada, tingueu en compte el pitjor i el millor dels casos.
Font: www.habr.com