La lliçó anterior va acabar assenyalant el supòsit ocult de tot el que portem construït: hem donat per fet que, quan l'HorizontalPodAutoscaler demana trenta rèpliques d'api-reserves, hi ha lloc on posar-les. No n'hi ha. El clúster de Rutas Norte té quatre nodes, i trenta pods d'api-reserves més quinze de botiga-web més vint de worker-notificacions no hi caben ni de bon tros.

El resultat d'aquesta situació té un nom i un aspecte molt concret: pods en estat Pending, amb un esdeveniment FailedScheduling que diu Insufficient cpu. Ja el sabem llegir des de 06-05 i 07-06. El que no sabem encara és què fer-hi de manera automàtica.

Aquest és el tercer i últim nivell de l'escalat. L'HPA canvia el nombre de pods. El VPA canvia la mida de cada pod. L'autoescalat de clúster canvia el nombre de nodes. Sense ell, els altres dos tenen un sostre dur que no poden travessar.

Veurem el Cluster Autoscaler en detall: com decideix ampliar, la part delicada de reduir nodes (que és on són tots els problemes reals), els temps que triga de debò un node a estar disponible, el patró de sobreaprovisionament que compensa aquests temps, i Karpenter com a alternativa moderna. Acabarem amb el pla de capacitat concret de Rutas Norte per al pont de maig, amb els seus números i el seu cost.

1. El sostre dur: quan l'HPA demana i no hi ha lloc
2. El símptoma exacte: Pending i FailedScheduling
3. Què és el Cluster Autoscaler i on viu
4. Com decideix ampliar: simulació i expanders
5. Grups de nodes i la seva relació amb el proveïdor
6. La reducció de nodes: la part delicada
7. Els motius pels quals un node no es pot buidar
8. Diagnòstic: el ConfigMap d'estat i els esdeveniments
9. Els temps reals: quant triga un node de debò
10. Sobreaprovisionament amb pods de farciment
11. Karpenter: l'alternativa moderna
12. Com encaixen els tres escaladors
13. Què es pot practicar a minikube
14. El pla de capacitat de Rutas Norte i el seu cost
15. Errors comuns i consells
16. Exercicis
17. Conclusió

Posem l'escenari amb números reals. El clúster de Rutas Norte en producció:

I el consum en repòs, amb tots els components a minReplicas:

Queden uns 6,2 nuclis lliures. Ara arriba el pont de maig:

Quinze pods d'api-reserves es quedaran en Pending. L'HPA haurà fet la seva feina: va demanar 30 rèpliques i el Deployment les va crear. El ReplicaSet les té registrades. Però el planificador no troba on posar-les, i allà es queden.

I això és el pitjor de l'assumpte: l'HPA no ho sap. A kubectl get hpa veuràs REPLICAS 30. A Grafana, el panell de rèpliques dirà 30. La plataforma tindrà 15 pods llestos i 15 fantasmes. I com que l'HPA calcula la mitjana de CPU només entre els pods que sí que existeixen i estan llestos, veurà que estan al 90 % i demanarà... res més, perquè ja és a maxReplicas.

El resultat és una plataforma que cau amb la il·lusió d'estar escalada.

Aprenguem a reconèixer-ho amb precisió, perquè és el disparador de tota la resta.

Pending amb 0/2 i sense reinicis: el pod existeix a l'API però cap node no l'ha acceptat. No hi ha contenidors corrent perquè no hi ha on.

Dues línies d'or:

Node: <none> — confirmació que no està assignat a cap node.

0/4 nodes are available: 4 Insufficient cpu — el planificador va avaluar els quatre nodes i els quatre van fallar per CPU insuficient. El missatge sempre té la forma X/Y nodes are available: <raons>, i les raons s'agrupen per causa. Les que veuràs a la pràctica:

La línia NotTriggerScaleUp és la del Cluster Autoscaler, i en aquest exemple diu max node group size reached: el CA està instal·lat, ha vist el pod pendent, i no hi pot fer res perquè el grup de nodes ja és a la seva mida màxima. Tornarem a aquest missatge a l'apartat 8, perquè és la principal eina de diagnòstic.

Una ordre molt útil per veure tots els pendents d'un cop d'ull:

I per veure l'ocupació real dels nodes:

Fixa't que la columna que importa és Requests, no Limits. El planificador col·loca pods segons requests. Un node al 97 % de requests està ple a efectes de planificació, encara que el consum real sigui del 30 %. És la lliçó del mòdul 3, ara amb conseqüències de capacitat.

El Cluster Autoscaler (CA) és un component que ajusta el nombre de nodes del clúster. Com el VPA, viu al repositori kubernetes/autoscaler i no forma part del nucli de Kubernetes.

El seu funcionament en una frase: observa els pods que no es poden planificar i afegeix nodes; observa els nodes infrautilitzats i els retira.

Corre com un Deployment dins del mateix clúster, normalment a kube-system, amb un ServiceAccount que té permisos amplis (llegir pods i nodes, crear esdeveniments, desallotjar pods) i credencials del proveïdor de núvol per manipular els grups de nodes.

A Kubernetes gestionat (10-06) el proveïdor l'instal·la i el configura per tu: a EKS, AKS i GKE actives l'autoescalat amb un interruptor i el proveïdor s'encarrega de la resta. És l'escenari més habitual, i per això convé entendre'n el comportament encara que mai l'hagis d'instal·lar a mà.

Aquest tercer requisit és més important del que sembla. El CA assumeix que tots els nodes d'un grup són idèntics. Quan simula si un pod cabria en un node nou del grup A, fa servir la plantilla del grup A. Si el grup té màquines heterogènies, la simulació menteix i el CA pren decisions equivocades. D'aquí la recomanació universal: un tipus de màquina per grup de nodes.

I el quart requisit connecta amb tot el mòdul 3: un pod sense requests és invisible per al planificador a efectes de capacitat, i també per al CA. Aquí, un altre cop, els requests són la base de tot.

El bucle del CA s'executa cada 10 segons per defecte (--scan-interval).

1. Llista els pods no planificables. Els que porten almenys --max-pod-provisioning-time en Pending amb FailedScheduling.
2. Agrupa pods equivalents. Els pods del mateix controlador amb els mateixos requisits es tracten com un grup, per no simular vint vegades el mateix.
3. Per a cada grup de nodes, simula. «Si afegeixo un node del grup A, quants d'aquests pods pendents hi cabrien?» La simulació fa servir el planificador real, amb tots els seus predicats: recursos, taints, afinitats, distribució topològica, ports d'amfitrió.
4. Descarta els grups que no ajuden. Si afegir un node del grup B no permet planificar ni un sol pod (perquè té un taint que el pod no tolera, per exemple), aquest grup es descarta.
5. Tria entre els grups viables fent servir l'expander.
6. Calcula quants nodes calen i demana al proveïdor que ampliï el grup.

Un detall important del pas 6: el CA pot afegir diversos nodes alhora. Si hi ha 15 pods pendents de 520m cadascun i en un node de 4 nuclis en caben 6, demanarà 3 nodes de cop, no un cada vegada. Això està limitat per --max-nodes-total i pel màxim del grup.

Quan diversos grups de nodes servirien, l'expander decideix quin.

Exemple concret de least-waste. Hi ha 3 pods pendents que necessiten 500m i 512Mi cadascun (total: 1,5 nuclis i 1,5 GiB), i dos grups disponibles:

least-waste tria el grup A: s'ajusta millor i no paga per 6 nuclis ociosos. most-pods triaria el B (hi cabrien molts més pods futurs). price triaria l'A si és més barat.

Configuració de l'expander:

L'opció --balance-similar-node-groups mereix menció perquè resol un problema real d'alta disponibilitat: si tens un grup de nodes per zona de disponibilitat, aquest indicador fa que el CA reparteixi els nodes nous equilibradament entre zones en lloc d'amuntegar-los en una. Sense ell, pots acabar amb dotze nodes a la zona A i cap a la B, i una caiguda de zona et deixa sense plataforma. Connecta directament amb el que veurem a 09-05.

Un patró molt rendible al núvol. Les instàncies spot (interrompibles) costen una fracció del preu, però el proveïdor les pot reclamar amb dos minuts d'avís.

El CA intenta primer el grup de prioritat 100. Si el proveïdor no té capacitat spot disponible, cau al de prioritat 50. Per a worker-notificacions, que tolera interrupcions sense problema, és l'opció evident. Per a postgres-reserves, mai.

El CA no crea màquines: manipula grups de nodes del proveïdor. Cada proveïdor té el seu nom per al mateix:

Un grup de nodes té una mida mínima, una màxima i una actual. El CA només canvia l'actual, dins d'aquests límits. Tota la resta (el tipus de màquina, la imatge, els taints i etiquetes inicials) el defineix el grup.

Els grups de Rutas Norte:

Tres decisions de disseny que convé entendre:

Un grup per zona. Necessari perquè --balance-similar-node-groups reparteixi entre zones i perquè l'afinitat de zona funcioni. Amb un únic grup multizona, el CA no pot garantir en quina zona apareixerà el node nou, i això trenca la distribució topològica de 09-05.

Un grup dedicat a dades amb taint. postgres-reserves i redis-cache tenen tolerations per a rol=dades (06-05) i afinitat de node cap a aquest grup. Així les bases de dades viuen en màquines grans amb disc ràpid i no comparteixen node amb l'allau de pods d'api-reserves. El taint impedeix que els pods de l'aplicació hi aterrin.

El grup de dades té max=3, molt baix. És deliberat: no volem que el CA arrenqui màquines grans i cares per error. postgres-reserves no escala horitzontalment (09-01), així que aquest grup gairebé mai necessita créixer.

Quan el CA simula si un pod cabria en un node del grup A, fa servir una plantilla. Si el node real, en arrencar, rep etiquetes o taints que la plantilla no coneixia, la simulació menteix.

Cas típic i molt frustrant: un pod amb nodeSelector: disc=ssd està Pending. El CA simula amb la plantilla del grup, que no té aquesta etiqueta, conclou que el pod no hi cabria ni amb un node nou, i no escala. Però els nodes reals del grup sí que reben aquesta etiqueta en arrencar, mitjançant un script d'arrencada.

La solució és declarar les etiquetes i taints a la mateixa definició del grup de nodes del proveïdor (a AWS, amb etiquetes k8s.io/cluster-autoscaler/node-template/label/... a l'ASG), perquè el CA les conegui abans d'arrencar el node.

Ampliar és fàcil: hi ha pods pendents, s'afegeixen nodes. Reduir és on són tots els problemes, perquè retirar un node implica desallotjar els pods que té i confiar que reapareixeran en un altre lloc sense trencar res.

Cada 10 segons, per a cada node:

1. És per sota del llindar d'utilització? Per defecte, --scale-down-utilization-threshold=0.5: la suma de requests dels seus pods és menor del 50 % de la seva capacitat assignable.
2. Fa prou temps que hi és? --scale-down-unneeded-time=10m: deu minuts consecutius per sota del llindar.
3. Es pot buidar? Simula si tots els seus pods cabrien en altres nodes existents. Si no hi caben, no es toca.
4. Hi ha algun pod que impedeixi el desallotjament? La llista de l'apartat 7.
5. Si tot passa: acordona el node, desallotja els seus pods respectant els PDB, espera, i demana al proveïdor que l'elimini.

Paràmetres principals:

--scale-down-delay-after-add és el paràmetre clau per evitar el ball de nodes. Sense ell, el CA podria afegir un node, veure que el clúster queda infrautilitzat i treure'l immediatament. Deu minuts de gràcia trenquen aquest cicle.

Sobre el llindar d'utilització, un càlcul important:

Fixa't que els DaemonSets compten per a la utilització però no impedeixen l'eliminació (s'ignoren al pas 4, perquè desapareixen amb el node). Amb molts DaemonSets, la utilització base d'un node buit ja és alta, i això fa que el CA redueixi menys del que esperaries. En clústers amb molts agents (logging, seguretat, malla de serveis, monitoratge), és habitual haver de baixar el llindar al 30-40 % perquè la reducció funcioni.

Un node que només té DaemonSets es considera buit i s'elimina per un camí ràpid, sense la simulació completa. Per això, després d'una punta de trànsit, els nodes que queden totalment lliures desapareixen bastant ràpid, mentre que els que tenen un pod solt triguen molt més.

Això explica un fenomen que desconcerta molta gent: després del pont de maig, vuit nodes se'n van en vint minuts i dos es queden durant hores amb un sol pod cadascun. La solució de fons no és tocar el CA: és la distribució topològica i la consolidació (Karpenter, apartat 11).

Aquesta és la llista que cal conèixer de memòria, perquè explica el 90 % dels casos de «tinc nodes buits que l'autoescalador no treu i estic pagant per ells».

És l'eina de control més directa:

Quan té sentit "false":

• Un treball per lots llarg que perdria hores de còmput si es reinicia. informes-ocupacio és un candidat: si triga 40 minuts i el CA el mata al minut 35, la nit es perd.
• Una migració de base de dades en curs.
• Un pod amb estat local irreproduïble.

I el valor contrari, "true", serveix per desbloquejar situacions:

És la manera neta de resoldre el motiu 2 sense canviar l'indicador global del CA. A Rutas Norte, botiga-web fa servir un emptyDir per a la memòria cau de nginx: marcar-lo com a safe-to-evict: "true" permet que el CA retiri els seus nodes sense problema, perquè aquesta memòria cau es regenera sola.

El cas més freqüent i el més perillós. Un PDB així:

Amb una sola rèplica de postgres-reserves i minAvailable: 1, aquest pod mai pot ser desallotjat: fer-ho deixaria 0 disponibles. El node que l'allotgi queda ancorat permanentment. El CA ho intentarà, fallarà, i ho registrarà als seus esdeveniments.

En aquest cas concret el bloqueig és desitjable (no volem que el CA mogui la base de dades pel seu compte), però el mateix patró aplicat per error a un servei qualsevol produeix nodes zombis que ningú sap per què no se'n van. Ho desenvolupem a fons a 09-05.

El CA publica el seu estat intern en un ConfigMap. És el primer lloc on mirar.

Com llegir-ho:

A la sortida de dalt: el grup A té 3 llestos i 1 arrencant. El CA ja ha demanat el node; només cal esperar. Aquesta informació és exactament el que necessites durant un incident per saber si el CA està treballant o encallat.

Estats de ScaleDown que veuràs:

Quan el CA decideix no fer res, ho diu en un esdeveniment sobre el pod pendent:

Aquest missatge és un regal: et diu exactament per què cada grup de nodes va ser descartat. Aquí: un grup és al màxim i un altre té un taint que el pod no tolera.

Missatges habituals de NotTriggerScaleUp i la seva traducció:

I per a la reducció bloquejada:

Els logs del CA són la font definitiva quan el ConfigMap i els esdeveniments no basten. Conserva'ls a EFK (07-05): són imprescindibles per a l'anàlisi posterior d'un incident de capacitat.

Aquí hi ha la dada que canvia l'estratègia, i la que gairebé mai s'explica.

Sumant: entre 3 i 4 minuts en el cas bo. En el cas dolent (imatge gran no cachejada, regió saturada, DaemonSets pesants) pot passar dels 6 minuts.

Desglossament típic en taula:

Tornem al pont de maig. La venda obre a les 10:00. El perfil de trànsit real:

Cinc minuts de latència degradada i errors en el moment de més valor comercial de l'any. Milers d'usuaris que abandonen la compra. El Cluster Autoscaler, per ben configurat que estigui, no pot resoldre una punta que puja en quaranta segons, perquè la física d'arrencar una màquina virtual no ho permet.

D'aquí surten dues estratègies, i calen totes dues:

1. Sobreaprovisionament: tenir capacitat ja arrencada i esperant (apartat 10).
2. Escalat anticipat: escalar abans del pic fent servir un disparador temporal, no reactiu. És el disparador cron de KEDA que veurem a 09-04.

El patró que resol el problema de l'apartat anterior, i que fa servir de manera brillant la PriorityClass i la preemption de 06-05.

Despleguem pods que no fan res —dormen— però reserven CPU i memòria, amb una prioritat negativa. Efectes:

1. El CA compta aquests requests com a ocupació, així que manté nodes arrencats per allotjar-los.
2. Quan arriba un pod real (prioritat 0 o superior) i no hi ha lloc, el planificador desallotja instantàniament un pod de farciment i col·loca el real al seu forat. La preemption triga segons, no minuts.
3. Els pods de farciment desallotjats passen a Pending, cosa que dispara el CA per arrencar nodes nous... que ompliran el coixí per a la propera vegada.

És un coixí de capacitat autoregeneratiu. Compres capacitat ociosa a canvi de temps de resposta.

Pas 1: la PriorityClass negativa.

Dos detalls importants:

• value: -10 garanteix que qualsevol pod sense priorityClassName (prioritat 0) els superi.
• preemptionPolicy: Never fa que aquests pods, en quedar-se Pending, no intentin desallotjar-ne d'altres. Seria absurd que el coixí fes fora un pod real.

Pas 2: el Deployment de farciment.

La imatge pause és l'elecció canònica: és la mateixa que Kubernetes fa servir internament per al contenidor d'infraestructura de cada pod, pesa menys d'un megabyte, ja és a la memòria cau de tots els nodes i la seva única feina és dormir.

Pas 3: comprovar que funciona.

Ara forcem una punta:

I als esdeveniments dels pods d'api-reserves:

Tres segons des de la creació del pod fins a la seva planificació, en lloc de tres minuts i mig. Aquesta és la diferència entre absorbir l'obertura de la venda i caure.

Res no és gratis:

Val la pena? A Rutas Norte, la resposta és clara: cinc minuts de caiguda a l'obertura del pont de maig costen molt més de 1.940 euros en bitllets no venuts. Però és una decisió de negoci, no tècnica, i s'ha de prendre amb números damunt la taula.

Optimització evident: el coixí no ha de ser constant. Un CronJob (06-03) que escali el Deployment de farciment de 2 a 6 rèpliques els divendres a la tarda i el torni a 2 els dilluns redueix el cost anual a una fracció:

I la seva parella el dilluns a les 6:00 amb --replicas=2. El ServiceAccount operador-escalat necessita un Role amb permís sobre deployments/scale, exactament com vam veure a 08-01.

El Cluster Autoscaler té una limitació de disseny: treballa amb grups de nodes predefinits. Algú ha de decidir per endavant quins tipus de màquina existeixen, crear un grup per a cadascun, i mantenir-los.

Karpenter inverteix el plantejament: mira els pods pendents, calcula quina màquina seria la millor per a ells, i l'arrenca directament, sense grups.

En lloc de grups de nodes, defineixes restriccions de quins tipus de màquina són acceptables:

Amb aquesta definició, quan apareixen 15 pods d'api-reserves pendents, Karpenter calcula que la millor màquina per allotjar-los és, posem, una c6i.4xlarge spot a la zona B, i l'arrenca. Sense que ningú hagi creat mai un grup de nodes c6i.4xlarge.

És la diferència més pràctica en el dia a dia. Karpenter revisa contínuament si el conjunt de pods actual cabria en una configuració de nodes més barata, i si és així, migra els pods i substitueix els nodes.

L'escenari que resol: després del pont de maig, el CA deixa cinc nodes amb un pod cadascun, perquè cap no baixa del llindar d'utilització de manera que permeti buidar-lo. Karpenter veu que aquests cinc pods cabrien en un sol node, arrenca aquest node, migra els pods i elimina els cinc.

És exactament el problema que vam esmentar al final de l'apartat 6, resolt d'arrel.

Quan triar cadascun:

• Cluster Autoscaler si ets fora d'AWS, si tens requisits regulatoris sobre quins tipus de màquina són admissibles, si el teu proveïdor ja te'l dona configurat i funciona, o si valores la predictibilitat per sobre de l'estalvi.
• Karpenter si ets a AWS, si el cost és una prioritat real, si la teva càrrega és heterogènia (pods petits i pods grans convivint), i si et compensa la reducció de feina operativa.

Per a Rutas Norte, amb quatre nodes i una càrrega homogènia, el CA és més que suficient. Si la plataforma creixés a cinquanta nodes amb càrregues variades, Karpenter seria la decisió evident. Tornarem a aquest tipus de decisions a 10-06 i 11-06.

Una nota important que la comparativa no ha d'amagar: Karpenter tampoc arregla la punta de quaranta segons. Un o dos minuts continuen sent massa. El sobreaprovisionament continua fent falta.

Ja tenim les tres peces. Vegem el flux complet en ordre temporal.

Les tres rutes i els seus temps:

La conclusió estratègica és directa: el coixí de sobreaprovisionament no és un luxe, és el que converteix un incident de cinc minuts en un de trenta segons.

I encara queda una ruta millor, que no apareix al diagrama perquè no és reactiva: escalar abans que arribi el trànsit. Si a les 9:30 ja tens 25 rèpliques i vuit nodes perquè un disparador cron ho va ordenar, a les 10:00 no hi ha cap incident. Això és 09-04.

Els tres són necessaris i cap no substitueix un altre. L'HPA sense CA té un sostre dur. El CA sense HPA no es dispara mai. El VPA els fa a tots dos més precisos, perquè els requests correctes són la base tant del càlcul de l'HPA com de la simulació del CA.

Moment d'honestedat: el Cluster Autoscaler no es pot provar de debò a minikube. No hi ha proveïdor de núvol que arrenqui màquines. El perfil rutas-norte té els nodes que li vas demanar en crear-lo, i aquests són tots.

1. Produir el símptoma i aprendre a llegir-lo.

Veuràs exactament el FailedScheduling amb Insufficient cpu. És el mateix missatge que en producció.

2. El patró de sobreaprovisionament amb preemption. Això funciona perfectament, perquè la preemption és una funció del planificador, no del proveïdor de núvol.

Veure el Preempted amb els teus propis ulls i mesurar que passa en segons és la part més valuosa de l'exercici, i es practica sense núvol.

3. Afegir i treure nodes a mà, simulant el que faria el CA.

Aquesta seqüència cordon → drain → eliminar és exactament el que fa el CA internament. Practicar-la a mà ensenya més sobre la reducció de nodes que llegir qualsevol documentació, i és la base del procediment de manteniment que veurem a 09-05.

4. Practicar l'anotació safe-to-evict i veure com bloqueja un drenatge.

Per practicar el CA de debò calen: un clúster gestionat (10-06) amb l'autoescalat activat, o kind amb el proveïdor de proves del CA, o un entorn de núvol personal. Recomanació pràctica: un compte de proves d'un proveïdor durant una tarda, amb un clúster petit i maxSize baix, costa uns pocs euros i ensenya moltíssim.

Tanquem amb els números concrets. Aquesta és la feina que cal fer abans d'un pont de maig, i que no es va fer l'any passat.

Dels maxReplicas de 09-01 i els requests recalibrats amb el VPA de 09-02:

El marge del 33 % no és caprici: cobreix errors d'estimació, un desplegament en curs durant el pic (que duplica temporalment els pods d'un component), i la pèrdua d'una zona sencera.

Preus ficticis però d'ordre de magnitud realista:

I la comparació que justifica tot el mòdul:

L'última fila és l'objectiu: pràcticament el mateix cost que el dimensionament fix insuficient, amb la capacitat del dimensionament per al pic. Aquest és tot el valor del mòdul 9 resumit en una línia.

I un recordatori d'honestedat intel·lectual: el coixí reduït fora de temporada només funciona si el CronJob que l'amplia s'executa de debò. Posa-hi una alerta: si el divendres a les 16:05 el Deployment de farciment no té 6 rèpliques, algú se n'ha d'assabentar.

Error 1: creure que l'HPA només et pot portar fins on hi ha capacitat, i no adonar-se'n. El símptoma és silenciós: kubectl get hpa mostra 30 rèpliques i tot sembla bé. Només kubectl get pods revela que 15 estan Pending. Alerta obligatòria sobre pods pendents:

Error 2: maxReplicas de l'HPA incoherent amb el maxSize dels grups de nodes. Un maxReplicas: 100 amb grups que topen en 8 nodes és una mentida: mai arribaràs a 100 rèpliques. Calcula sempre Σ(maxReplicas × requests) i compara-ho amb Σ(maxSize × capacitat assignable). Documenta aquest càlcul al costat dels manifests.

Error 3: pods sense requests en un clúster amb CA. Un pod sense requests és invisible per a la simulació del CA: l'autoescalador creu que un node té lloc de sobres quan en realitat està saturat de pods que consumeixen sense declarar res. El LimitRange del mòdul 3 és la defensa: força un defaultRequest a tot el que es creï.

Error 4: esperar que el CA salvi una punta sobtada. Tres a sis minuts. Si el teu trànsit puja en quaranta segons, el CA arriba tard. Sobreaprovisionament (apartat 10) i escalat anticipat (09-04). No hi ha tercera via.

Error 5: PDB impossibles que ancoren nodes per sempre. Un minAvailable igual al nombre de rèpliques fa que cap pod no es pugui desallotjar mai, i el node que els allotgi no es retirarà mai. Estaràs pagant per nodes infrautilitzats sense saber per què. Ho desenvolupem a 09-05, però el diagnòstic és als logs del CA: pdb-blocked.

Error 6: un sol grup de nodes per a tot. Sense separar les dades de l'aplicació, una allau de pods d'api-reserves pot aterrar al mateix node que postgres-reserves i competir per la seva CPU. Taints i grups separats (06-05).

Error 7: nodes heterogenis dins d'un mateix grup. El CA fa servir una plantilla per grup. Si el grup barreja màquines de 2 i de 8 nuclis, la simulació menteix i les decisions són erràtiques. Un tipus de màquina per grup, sempre.

Consell 1: --balance-similar-node-groups si tens un grup per zona. Sense ell, el CA pot amuntegar tots els nodes nous en una zona i deixar-te exposat a una caiguda de zona. És una línia de configuració amb impacte directe en la disponibilitat.

Consell 2: monitora cluster_autoscaler_unschedulable_pods_count. El CA exposa mètriques Prometheus. Les que importen:

Aquest tercer indicador és especialment valuós: un failed_scale_up significa que el proveïdor t'ha dit que no. Quota esgotada, tipus d'instància sense disponibilitat a la zona, límit del compte. Són problemes que només es descobreixen quan ja és tard, llevat que els vigilis.

Consell 3: assaja l'escalat abans del pic. Una setmana abans del pont, llança una prova de càrrega contra rutas-norte-pre (09-06) i cronometra quant triga el clúster a assolir la capacitat màxima. Aquest número, mesurat i no estimat, és el que et diu si el coixí és suficient.

Consell 4: puja el maxSize dels grups abans de la temporada alta i baixa'l després. És un canvi d'un minut que evita el max node group size reached en el pitjor moment. Posa-ho a la llista de comprovació prèvia a l'esdeveniment.

Consell 5: desa els logs del CA. Són l'única font que explica per què no es va escalar o per què un node no es va retirar. Sense ells, l'anàlisi posterior d'un incident de capacitat és endevinar. EFK (07-05).

Consell 6: revisa el llindar de reducció si tens molts DaemonSets. Amb Fluentd, Falco, el CNI, l'exportador de node i potser un proxy de malla de serveis, la utilització base d'un node buit pot rondar el 25 %. Amb el llindar per defecte del 50 %, la reducció gairebé mai es dispara. Baixar-lo al 35 % pot estalviar nodes sencers.

L'equip de Rutas Norte ha configurat això per al pont de maig:

HPA:

Components fixos: postgres-reserves (1 rèplica, 2 nuclis, 4Gi), redis-cache (1 rèplica, 300m, 2Gi), Ingress (4 rèpliques, 200m, 256Mi).

Grups de nodes:

DaemonSets: 450m i 512Mi per node. Reserva del sistema: 500m i 2Gi per node.

ResourceQuota del namespace: requests.cpu: 40, requests.memory: 80Gi.

Calcula: (a) la CPU i memòria màximes que pot demandar l'aplicació; (b) la capacitat assignable màxima real dels grups; (c) si la configuració aguanta el pic; (d) el percentatge de maxReplicas d'api-reserves que és assolible a la pràctica; (e) què corregiries i en quin ordre.

Després del pont de maig, el clúster continua amb 9 nodes encara que el trànsit va tornar a la normalitat fa 5 hores. La factura preocupa. Això és el que veus:

Analitza cada node bloquejat, digues si el bloqueig és legítim o un error, i proposa la correcció per a cada cas. Calcula quants nodes es podrien retirar després de les correccions i l'estalvi mensual (95 €/node/mes).

Rutas Norte llança una campanya de Black Friday diferent de tot l'anterior:

• Durada: 2 hores exactes, de 20:00 a 22:00 d'un divendres.
• Trànsit esperat: x25 respecte a un dia normal (molt més que el pont de maig).
• El pic arriba en 20 segons: s'anuncia per ràdio i tothom entra alhora.
• Els bitllets són limitats: si la plataforma no respon en els primers 10 minuts, la campanya ha fracassat.
• Pressupost: fins a 400 € per a aquella nit.
• Es coneix amb tres setmanes d'antelació.

Dissenya l'estratègia completa de capacitat. Quina combinació d'HPA, CA, sobreaprovisionament i escalat programat faries servir? Quants nodes, quant coixí, amb quina antelació? Quant costaria? Escriu els manifests clau i una llista de comprovació amb horaris concrets per a aquella nit.

Solució 1

(a) Demanda màxima de l'aplicació:

(b) Capacitat assignable màxima real:

(c) Aguanta el pic? NO.

I hi ha un segon problema que molts passarien per alt: la ResourceQuota.

(d) Percentatge de maxReplicas d'api-reserves assolible:

El maxReplicas: 40 és ficció: la realitat són 25 rèpliques. I pitjor: quan l'HPA demani les rèpliques 26 a 40, es quedaran en Pending i ningú se n'assabentarà llevat que hi hagi una alerta.

(e) Correccions, per ordre de prioritat:

Prioritat 1 (imprescindible): pujar el maxSize dels grups generals.

Prioritat 2: reduir el maxSize del grup de dades.

Prioritat 3: revisar el maxReplicas: 40 d'api-reserves.

Amb 12 nodes generals hi caben 25 rèpliques... espera, recalculem amb la nova capacitat:

Prioritat 4: afegir el coixí de sobreaprovisionament. Sense ell, les rèpliques 5 a 40 trigaran entre 3 i 6 minuts a aparèixer. Amb 6 pods de farciment d'1 nucli, les primeres 11 rèpliques són instantànies.

Prioritat 5: l'alerta de pods pendents. Sense ella, tot aquest càlcul es pot equivocar i ningú ho sabrà fins que sigui tard.

Solució 2

Anàlisi node per node:

Cas 1: ip-10-0-1-88 — informes-ocupacio amb safe-to-evict: false.

Legitimitat: condicional. Si el Job s'està executant ara mateix, el bloqueig és correcte: matar-lo perdria la feina. Però el pont va acabar fa 5 hores i informes-ocupacio és un CronJob nocturn.

Si apareix com a Running des de fa hores, és un Job penjat: probablement va fallar i s'ha quedat encallat. Correcció:

I prevenció estructural al CronJob:

Node recuperable: SÍ, després de netejar el Job.

Cas 2: ip-10-0-2-73 — redis-cache-0.

Legitimitat: sí, plenament. redis-cache és un StatefulSet d'una rèplica amb volum. El CA no el pot moure amb seguretat, i per descomptat no ho ha de fer pel seu compte: reiniciar la memòria cau descarrega tota la càrrega sobre postgres-reserves.

Correcció: cap a curt termini. A mitjà termini, les opcions són:

• Ancorar redis-cache al grup de nodes de dades amb afinitat i taint (06-05), perquè no ocupi un node general.
• Acceptar-ho: un node dedicat a la memòria cau no és un malbaratament si està ben dimensionat.

La millor correcció és la primera: redis-cache no hauria d'estar en un node general. És una decisió d'arquitectura que ja hauríem d'haver pres.

Node recuperable: NO directament, però sí després de moure redis-cache al grup de dades.

Cas 3: ip-10-0-1-15 — PDB bloquejant api-reserves.

Legitimitat: no, és un error de configuració. api-reserves és un Deployment amb moltes rèpliques: moure un pod hauria de ser trivial. Que el PDB ho impedeixi significa que està malament.

Sospita probable:

Després del pont, l'HPA ha baixat a 4-6 rèpliques. Amb minAvailable: 30 i 6 rèpliques vives, cap pod no es pot desallotjar mai: ja s'està per sota del mínim.

Correcció:

Aquesta és la lliçó central de 09-05, avançada: amb HPA, els PDB en número absolut són una trampa. El nombre de rèpliques canvia sol, i un mínim absolut que era raonable al pic es torna impossible a la vall.

Node recuperable: SÍ, immediatament després de corregir el PDB.

Cas 4: ip-10-0-3-22 — generador-carrega sense controlador.

Legitimitat: no, és brossa. És el pod de prova de càrrega de l'apartat 12 de 09-01, creat amb kubectl run sense controlador i oblidat. Fa dies que és allà ancorant un node sencer.

Prevenció:

• Fes servir sempre --rm amb kubectl run per a proves.
• Una política de Kyverno (08-03) que rebutgi pods sense ownerReferences a rutas-norte-pro.
• Una revisió periòdica de pods orfes:

Node recuperable: SÍ, immediatament.

Resum i estalvi:

Comprovació després de les correccions:

Hauria de passar de NoCandidates a CandidatesPresent i després a InProgress.

Lliçó de fons de l'exercici: els nodes zombis mai són culpa del Cluster Autoscaler. Sempre són conseqüència d'alguna cosa mal configurada a les càrregues: un PDB impossible, un Job penjat, un pod orfe, un component amb estat al lloc equivocat. El CA és el missatger; els logs són el missatge.

Solució 3

Anàlisi de l'escenari. Aquest cas és qualitativament diferent del pont de maig:

La conclusió clau: l'escalat reactiu NO serveix aquí. Ni l'HPA (15 s de detecció + 30 s d'arrencada) ni el CA (3-6 min) arriben a temps per a una pujada de 20 segons. Tota la capacitat ha d'estar ja arrencada i calenta abans de les 20:00.

Estratègia: preescalat total.

Pas 1: calcular la capacitat necessària.

Pas 2: traduir a nodes.

Pas 3: els manifests.

Grups de nodes per a aquella nit:

Fixa't en el detall important: el min dels grups es puja a 3, no es confia en el CA. Posant el mínim alt, el proveïdor arrenca les màquines i el CA no les pot retirar. La capacitat està garantida per construcció, no per reacció.

Pas 4: el cost.

El resultat sorprèn i és l'ensenyament de l'exercici: dimensionar generosament per a dues hores és baratíssim. El cost de la infraestructura al núvol és proporcional al temps, i dues hores de sobredimensionament costen menys que un cafè per node. Amb un pressupost de 400 €, no hi ha cap excusa per escatimar capacitat aquella nit.

Amb el marge sobrant es poden permetre millores:

• Pujar a 12 nodes des del principi en lloc de 8: +5,20 €.
• Duplicar les rèpliques de redis-cache en mode rèplica de lectura: +2 €.
• Mantenir la capacitat fins a les 2:00 per buidar la cua de notificacions sense presses: +15 €.

Tot això hi cap folgadament.

Pas 5: la llista de comprovació de la nit.

Notes crítiques sobre el pla:

1. La verificació de les 18:30 és la més important. 88 pods creats no és el mateix que 88 pods Ready. Si a les 18:30 n'hi ha 20 en Pending, hi ha dues hores per arreglar-ho. Si te n'assabentes a les 20:01, no hi ha res a fer.

2. El scaleDown: Disabled és innegociable. Sense ell, una vall d'un minut entre les 20:15 i les 20:16 podria destruir 30 rèpliques que trigarien minuts a tornar.

3. worker-notificacions no s'escala durant la campanya. És una decisió deliberada: els correus de confirmació poden esperar dues hores, la venda no. Tota la capacitat va a la venda. Aquesta és la mena de compromís explícit que distingeix un pla de capacitat d'una llista de desitjos.

4. La regla de "no tocar res" durant la campanya. Gairebé tots els incidents greus en esdeveniments d'aquest tipus els causa algú intentant arreglar alguna cosa sota pressió. Si els panells estan verds, es mira i no es toca.

5. El preescalfament de memòries cau a les 19:30 estalvia que els primers 5.000 usuaris paguin el cost de les consultes fredes a PostgreSQL. És mitja hora de feina amb un impacte enorme en els primers minuts.

L'autoescalat de clúster és el nivell que sosté els altres dos. Sense ell, l'HorizontalPodAutoscaler té un sostre dur i invisible: demana rèpliques, el Deployment les crea, i es queden en Pending mentre els panells mostren números que no es corresponen amb la realitat.

L'essencial:

• El símptoma és sempre el mateix: pods en Pending amb FailedScheduling i Insufficient cpu. Reconèixer-lo i alertar-ne és el primer.
• El Cluster Autoscaler observa pods no planificables, simula quin grup de nodes els allotjaria, i tria amb un expander. least-waste és el més raonable en general.
• Ampliar és fàcil; reduir és on són els problemes. Llindar d'utilització, temps d'espera, i una llista de bloquejadors que cal conèixer: pods sense controlador, emmagatzematge local, PDB restrictius, pods del sistema, i l'anotació safe-to-evict: "false".
• Diagnosticar és llegir tres llocs: el ConfigMap cluster-autoscaler-status, els esdeveniments NotTriggerScaleUp sobre els pods pendents, i els logs del CA amb els seus not suitable for removal.
• Un node triga entre 3 i 6 minuts a passar de la petició a servir trànsit. Això no salva una punta que puja en quaranta segons, per ben configurat que estigui tot.
• El sobreaprovisionament amb pods de prioritat negativa converteix tres minuts i mig en tres segons, a canvi de pagar capacitat ociosa. És l'ús més elegant de la PriorityClass i la preemption de 06-05, i s'autoregenera.
• Karpenter tria la màquina en funció dels pods pendents en lloc de treballar amb grups fixos, i consolida contínuament. Millor a AWS i amb càrregues heterogènies; el CA continua sent l'opció sòlida i predictible en la resta de casos.
• Els tres escaladors encaixen en cascada: l'HPA crea pods → si no hi caben, Pending → el CA afegeix nodes. I el coixí talla el camí llarg.
• El pla de capacitat de Rutas Norte costa pràcticament el mateix que el dimensionament fix insuficient de l'any passat, però amb la capacitat del dimensionament per al pic. Aquest és tot el valor del mòdul.

Però continuem tenint un problema de fons que cap de les tres lliçons no ha resolt. Tot el que hem construït és reactiu: espera que la CPU pugi per actuar. I hi ha dos casos on això simplement no funciona.

El primer és worker-notificacions. Durant el pont de maig pot tenir quaranta mil correus esperant a la cua i la CPU al 20 %, perquè la seva feina és esperar respostes del servidor de correu, no calcular. Un HPA per CPU veuria aquest 20 % contra un objectiu del 70 % i conclouria que sobren rèpliques: escalaria cap avall justament quan més consumidors calen.

El segon és el mateix moment d'obertura de la venda. Sabem que passa a les 10:00 en punt. És informació que tenim amb mesos d'antelació. I tanmateix, tot el nostre sistema espera a les 10:00:15 per descobrir, per la CPU, alguna cosa que ja sabíem al març.

A la propera lliçó, Escalat per Esdeveniments i Mètriques Personalitzades amb KEDA, resolem els dos. Veurem com l'HPA pot consumir mètriques de negoci a través de l'API d'agregació, què és KEDA i per què no substitueix l'HPA sinó que l'alimenta, com escalar worker-notificacions per la longitud real de la seva cua —amb escalat a zero inclòs—, com escalar api-reserves per peticions per segon fent servir les mètriques que vam instrumentar a 07-03, i com programar un disparador que preescalfi tota la plataforma mitja hora abans que s'obri la venda del pont de maig.