A la lliçó anterior vam canviar la imatge de botiga-web i vam observar una cosa que vam deixar deliberadament sense explicar: va aparèixer un segon ReplicaSet, el vell es va quedar a zero rèpliques sense esborrar-se, i durant uns segons hi van conviure pods de dues versions. Aquell mecanisme és la raó de ser del Deployment i la resposta directa al primer dels quatre objectius de Rutas Norte: zero talls als desplegaments, davant del minut o dos d'aturada que avui obliga a desplegar els dimarts de matinada. En aquesta lliçó prenem el control d'aquell traspàs. Veuràs les dues estratègies natives del Deployment i quan exigeix cadascuna, calcularàs pod a pod el que passa durant una actualització d'api-reserves, ajustaràs el ritme amb maxSurge i maxUnavailable, distingiràs quins canvis generen una revisió nova i quins no, i faràs servir el joc complet de kubectl rollout: status, history, undo, pause i resume. I acabaràs trencant un desplegament a propòsit amb una imatge inexistent, diagnosticant-lo i desfent-lo.

1. Les dues estratègies natives: RollingUpdate i Recreate
2. Per què postgres-reserves no admet RollingUpdate
3. maxSurge i maxUnavailable, pas a pas amb api-reserves
4. Ritme i tolerància: minReadySeconds, progressDeadlineSeconds, revisionHistoryLimit
5. Què dispara una revisió nova i què no
6. El joc complet de kubectl rollout
7. L'anotació kubernetes.io/change-cause
8. Desplegament sense tall: què cal de debò
9. Diagnòstic i rollback d'un desplegament encallat

spec.strategy.type només admet dos valors. No hi ha més estratègies natives a Kubernetes: blue-green i canary, que veuràs a 11-04, es construeixen combinant aquests maons amb Serveis i Ingress.

Substitueix els pods de forma progressiva: aixeca pods de la versió nova i retira els de la vella a poc a poc, mantenint sempre un nombre mínim de pods servint.

Mata tots els pods vells, espera que desapareguin, i només llavors crea els nous. Hi ha un interval, normalment de segons a un parell de minuts, sense cap pod servint.

Com es declara explícitament:

És la pregunta clau d'aquest apartat, i la resposta ensenya més que l'estratègia en si. Imagina que postgres-reserves fos un Deployment d'1 rèplica amb RollingUpdate i maxSurge: 1. Durant l'actualització, això és el que passaria:

1. Kubernetes crea el pod nou abans de retirar el vell, perquè maxSurge: 1 ho permet.
2. Durant uns segons hi ha dos processos PostgreSQL simultanis.
3. Tots dos intenten muntar i escriure al mateix directori de dades.

Conseqüències reals, en ordre de gravetat:

• Bloqueig de l'arrencada: PostgreSQL detecta el fitxer postmaster.pid de la instància viva i es nega a arrencar. El desplegament s'encalla (el cas benigne).
• Corrupció de dades si el bloqueig falla o l'emmagatzematge no ho garanteix: dos processos escrivint als mateixos fitxers WAL.
• Escriptures perdudes: reserves confirmades al client que no queden registrades.

I hi ha un segon motiu, independent de l'emmagatzematge: la migració d'esquema. Si la versió nova d'api-reserves requereix una columna que la vella no coneix, tenir les dues versions parlant alhora amb la mateixa base de dades trenca una de les dues. Amb RollingUpdate aquella coexistència dura minuts; amb Recreate, no existeix.

La conclusió honesta: per a postgres-reserves, la resposta correcta no és Recreate, és no fer servir un Deployment. Recreate és l'estratègia adequada per a càrregues d'una sola rèplica que no toleren duplicitat però tampoc no necessiten identitat estable, com el nostre redis-cache.

Aplica-ho a redis-cache, que ja vas desplegar a la lliçó anterior:

Recorda portar també aquell canvi al manifest a Git.

Aquests dos paràmetres governen completament el ritme d'una actualització progressiva.

Tots dos admeten un nombre enter o un percentatge. Els percentatges s'arrodoneixen així: maxSurge cap amunt i maxUnavailable cap avall, per pecar sempre per excés de capacitat. I hi ha una restricció: no poden valer 0 tots dos alhora, perquè aleshores el desplegament no podria fer ni un pas.

api-reserves amb 4 rèpliques, maxSurge: 1 i maxUnavailable: 1. Actualitzem de la versió 2.4.0 a la 2.5.0. Els números que regeixen tot el procés:

• Màxim de pods simultanis = replicas + maxSurge = 4 + 1 = 5
• Mínim de pods disponibles = replicas - maxUnavailable = 4 − 1 = 3

Prepara l'escenari:

Les dues lectures importants d'aquella taula:

• En cap moment no hi ha menys de 3 pods servint. Rutas Norte no perd mai capacitat total, només el 25 % durant uns segons.
• En cap moment no hi ha més de 5 pods. El clúster necessita lloc per a un pod extra, no per a vuit.

En una terminal:

En una altra, llança l'actualització:

I el recompte de rèpliques de cada ReplicaSet durant el procés:

El Deployment està traspassant rèpliques d'un ReplicaSet a un altre. Això és, literalment, tot el que fa un desplegament progressiu.

Per a producció de Rutas Norte, l'elecció recomanada és maxSurge: 1 i maxUnavailable: 0: en un pont amb el trànsit multiplicat per sis, perdre un 25 % de capacitat durant un desplegament no és acceptable.

Tres camps que completen el control del desplegament.

minReadySeconds mereix una explicació a part perquè el seu efecte és subtil però molt valuós. Amb el valor per defecte de 0, tan bon punt un pod nou diu "estic llest", el controlador retira un altre de vell i tira endavant. Si aquell pod cau dos segons després, el dany ja està fet: el desplegament avança sobre una versió trencada. Amb minReadySeconds: 15, cada pod nou ha de sobreviure 15 segons llest abans de comptar. Si cau abans, el desplegament es frena.

progressDeadlineSeconds és la diferència entre un desplegament que falla en silenci i un que avisa. Sense ell, un desplegament encallat per una imatge inexistent es quedaria intentant-ho eternament sense que cap sistema d'alertes se n'assabentés.

Manifest d'api-reserves amb els tres camps i l'estratègia de producció:

Amb aquesta configuració, una actualització d'api-reserves a rutas-norte-pro triga com a mínim 4 × 15 = 60 segons, i si alguna cosa falla es declara fallida als 5 minuts en lloc d'als 10. Lentitud a canvi de seguretat: en un component que gestiona pagaments de bitllets, és un canvi excel·lent.

Aquesta és la regla més important de la lliçó i la més oblidada:

Només els canvis sota spec.template disparen una revisió nova. Tota la resta, no.

La lògica és transparent: una revisió és un ReplicaSet, i un ReplicaSet es distingeix d'un altre pel hash de la seva plantilla de pod. Si la plantilla no canvia, el hash no canvia, i no hi ha cap ReplicaSet nou a crear.

Comprova-ho tu mateix:

Mateix historial: escalar no és desplegar.

Una conseqüència pràctica que sorprèn molta gent: canviar un ConfigMap no reinicia els pods que el consumeixen, perquè el ConfigMap no és al template, només s'hi referencia des d'ell. El truc habitual, que veuràs al mòdul 3, és forçar un canvi al template amb una anotació calculada, o fer servir directament:

rollout restart no canvia res funcional: escriu una anotació kubectl.kubernetes.io/restartedAt dins del template, cosa que altera el hash i provoca una substitució progressiva de tots els pods. És la manera correcta i sense tall de "reiniciar" un Deployment.

La sintaxi és <nom-del-contenidor>=<imatge>. El nom del contenidor és el de spec.template.spec.containers[].name, no el del pod. Amb diversos contenidors es poden actualitzar alhora separant-los per espais.

Advertiment de disciplina: en un projecte declaratiu, la via correcta és editar el manifest i aplicar-lo. set image és per a emergències, i el seu canvi es perd al següent apply.

I el detall complet d'una revisió concreta:

Aquella informació surt íntegrament del ReplicaSet a 0 rèpliques que va quedar guardat. Per això revisionHistoryLimit: 0 et deixaria sense historial i sense rollback.

Torna a la revisió immediatament anterior. Per anar a una de concreta:

Dues precisions importants:

1. Un rollback és un desplegament més: fa servir la mateixa estratègia, respecta maxSurge i maxUnavailable, i per tant tampoc no talla el servei.
2. Desfer no esborra la revisió dolenta: crea una revisió nova amb el contingut de l'antiga. Si eres a la 3 i fas undo, apareixes a la 4, el contingut de la qual és el de la 2. Els números no retrocedeixen mai.

Fixa't que la revisió 2 ha desaparegut de la llista: el seu ReplicaSet s'ha reaprofitat com a revisió 4.

Amb el Deployment pausat, els canvis que facis no s'apliquen. És l'eina per agrupar diverses modificacions en un sol desplegament:

Sense pause, aquelles tres ordres haurien provocat tres desplegaments encadenats, cadascun interrompent l'anterior. Amb pause, un de sol i una sola revisió.

L'altre ús de pause és d'emergència: si veus que un desplegament està traient pods trencats, kubectl rollout pause el congela a l'acte, deixant-te els pods vells que queden servint mentre decideixes si arreglar o desfer.

Taula resum del joc complet:

Hauràs notat els <none> a la columna CHANGE-CAUSE. Un historial de revisions sense motius és gairebé inútil: al cap de tres setmanes ningú no recorda què era la revisió 7.

kubernetes.io/change-cause és una anotació del Deployment el valor de la qual es copia al ReplicaSet d'aquella revisió i es mostra a l'historial. Tres maneres d'omplir-la, de pitjor a millor:

Amb kubectl annotate (ràpida, imperativa):

Al manifest (la correcta segons les convencions del projecte):

Automatitzada a CI/CD, que és l'ideal:

Un detall que ja coneixes per l'apartat 5, però que convé repetir perquè genera confusió: canviar només aquesta anotació no dispara una revisió nova, perquè viu al metadata del Deployment i no al template. Anota-la juntament amb el canvi real, no després.

Bones pràctiques per al text de Rutas Norte: versió de la imatge, resum del canvi en llenguatge planer i referència al tiquet. Exemple real del projecte:

Aquí arriba l'advertiment més important de la lliçó. Podries pensar que amb RollingUpdate ben configurat ja tens desplegaments sense tall de servei. No és així, i aquesta és la causa número u d'errors 502 durant desplegaments suposadament perfectes.

El problema és que, amb el que sabem fins ara, Kubernetes considera que un pod està "llest" tan bon punt el procés arrenca. Però un procés de Node.js triga uns segons a carregar dependències, connectar a PostgreSQL i quedar operatiu. Durant aquella finestra:

1. El pod ja compta com a Ready.
2. El Deployment retira un pod vell, confiat.
3. El Service comença a enviar-li trànsit real.
4. El pod nou encara no pot respondre: errors 502.

La peça que falta s'anomena sonda de disponibilitat (readinessProbe): una comprovació que el kubelet executa contra la teva aplicació i que decideix si el pod està realment llest per rebre trànsit. Amb ella, el pas 1 de l'esquema no passa fins que l'aplicació respon de debò.

La llista de comprovació completa d'un desplegament realment sense tall a Rutas Norte:

És a dir: RollingUpdate és necessari però no suficient. Sense sondes, el desplegament progressiu avança a cegues. Fins que arribem al mòdul 7, minReadySeconds és un substitut pobre però útil.

Exercici final i el més realista de tots. Un divendres a la tarda, algú desplega a rutas-norte-dev una versió que no existeix al registre.

Lectura: hi ha 5 pods llestos i disponibles —el servei continua funcionant amb la versió anterior— però només 1 té la versió nova. El desplegament ha fet un pas i s'ha aturat. Això és el sistema funcionant bé: maxUnavailable: 0 ha impedit que es retirés cap pod vell fins que el nou estigués llest, i com que no ho estarà mai, no se n'ha retirat cap.

El ReplicaSet nou té 1 pod que no arriba a READY.

Causa arrel identificada, exactament amb el procediment de la lliçó de Pods.

Available: True (continuem servint) + Progressing: False amb ProgressDeadlineExceeded (el desplegament és mort) és la signatura exacta d'un desplegament encallat. En un clúster monitorat, aquella combinació ha de generar una alerta.

Dues opcions, segons el moment:

Advertiment important: si el Deployment està pausat, undo no té cap efecte. Cal fer resume abans.

El ReplicaSet trencat es queda a 0 rèpliques, sense consumir res, com a testimoni de l'incident. I l'historial explica la història completa a qui la llegeixi d'aquí a sis mesos.

La moralitat de tot l'apartat: durant els sis passos anteriors, api-reserves no va deixar d'atendre ni una sola reserva. Amb el Docker Compose de partida, aquell mateix error hauria deixat la plataforma caiguda fins que algú se n'adonés. Això és el que compra un Deployment ben configurat.

Deixa el clúster endreçat abans de continuar:

• Creure que RollingUpdate garanteix zero talls per si sol. Sense readinessProbe, el trànsit arriba a pods que encara no poden respondre. És la causa número u de 502 durant desplegaments.
• Posar maxSurge: 0 i maxUnavailable: 0. L'API ho rebutja: el desplegament no podria avançar.
• Fer servir RollingUpdate amb una càrrega que no tolera dues versions simultànies. Bases de dades d'una rèplica, processos amb bloqueig exclusiu o migracions d'esquema incompatibles: allà hi va Recreate, o directament un StatefulSet.
• Posar revisionHistoryLimit: 0 per "estalviar". Els ReplicaSets a 0 rèpliques no consumeixen ni CPU ni memòria, només uns quilobytes a etcd. A canvi, perds completament la capacitat de desfer.
• Esperar que canviar spec.strategy o spec.replicas dispari un desplegament. No són al template. Només s'apliquen a l'actualització real següent.
• Esperar que modificar un ConfigMap reiniciï els pods. No ho fa. Fes servir kubectl rollout restart.
• Oblidar el change-cause. Un historial de <none> no serveix de res quan cal decidir a quina revisió tornar a les tres de la matinada.
• Anotar el change-cause després del desplegament. Com que no dispara revisió, queda associat al Deployment però pot no reflectir el que va fer aquella revisió. Anota'l al mateix apply.
• Fer undo sobre un Deployment pausat. No passa res fins que facis resume. És un clàssic de la depuració a cegues.
• Confiar en kubectl apply com a verificació. apply només diu que l'API ha acceptat l'objecte. Encadena sempre kubectl rollout status --timeout=... als teus scripts.
• Consell: en producció, maxSurge: 1 i maxUnavailable: 0. Costa un pod extra de capacitat i garanteix que mai no baixes de la capacitat nominal.
• Consell: kubectl rollout status retorna codi de sortida diferent de 0 si el desplegament falla. És el que converteix una canalització de CI/CD en una cosa fiable: kubectl apply -f k8s/ && kubectl rollout status deploy/api-reserves --timeout=300s || kubectl rollout undo deploy/api-reserves.

botiga-web és a rutas-norte-pro amb 6 rèpliques, maxSurge: 2 i maxUnavailable: 1.

1. Quin és el nombre màxim de pods simultanis i el mínim de pods disponibles?
2. Construeix una taula amb els primers cinc passos de l'actualització, indicant a cadascun: pods vells, pods nous, total i disponibles.
3. Si l'equip de plataforma exigeix que mai no es baixi de 6 pods servint, quins valors hi posaries i quins recursos extra necessita el clúster?
4. Amb la configuració del punt 3 i minReadySeconds: 20, quina és la durada mínima teòrica del desplegament si cada pod triga 5 segons a arrencar?

Sobre botiga-web a rutas-norte-dev:

1. Configura RollingUpdate amb maxSurge: 1, maxUnavailable: 0, minReadySeconds: 10 i revisionHistoryLimit: 5, aplicant-ho des del manifest.
2. Actualitza a nginx:1.27.1-alpine amb el seu change-cause corresponent i espera que acabi.
3. Actualitza a nginx:1.26-alpine amb un altre change-cause.
4. Mostra l'historial i el detall de la revisió 2.
5. Simula que la 1.26 té una fallada greu: torna a la 1.27.1 i verifica que les tres rèpliques la serveixen.
6. Explica per què l'historial no mostra la numeració que esperaries.

1. Trenca worker-notificacions a propòsit desplegant la imatge busybox:9.9.9-inexistent, amb change-cause inclòs.
2. Amb quatre ordres, diagnostica el problema seguint l'ordre correcte: estat del Deployment, ReplicaSets, pod culpable i conditions.
3. Respon: continuen enviant-se els correus de confirmació durant l'encallament? Justifica-ho amb la sortida de les ordres.
4. Congela el desplegament, comprova que undo no fa res mentre està pausat, reprèn-lo i desfés.
5. Documenta el rollback amb una anotació i mostra l'historial final.

Solució 1

1. Màxim de pods = replicas + maxSurge = 6 + 2 = 8. Mínim disponibles = replicas - maxUnavailable = 6 − 1 = 5.

2. Primers cinc passos:

3. Per no baixar mai de 6 servint: maxUnavailable: 0, i maxSurge a 1 o 2 segons com de ràpid es vulgui anar. Amb maxSurge: 2, el clúster ha de tenir lloc per a 8 pods de botiga-web alhora: amb requests de 50m de CPU i 64Mi per pod, això són 100m de CPU i 128Mi de memòria lliures de més durant el desplegament. Amb maxUnavailable: 0 el clúster ha de tenir aquella capacitat; si no la té, els pods nous es queden en Pending i el desplegament no avança mai.

4. Amb maxSurge: 2 i maxUnavailable: 0, els pods se substitueixen en tandes de 2. Cada tanda triga 5 s (arrencada) + 20 s (minReadySeconds) = 25 s. Sis pods en tandes de dos són 3 tandes: 75 segons com a mínim teòric, sense comptar descàrregues d'imatge ni el temps de terminació dels vells.

Solució 2

6. La numeració sorprèn perquè les revisions no retrocedeixen mai. En desfer cap a la revisió 2, Kubernetes no hi "torna": reaprofita el seu ReplicaSet i el renumera com a revisió 4, la més recent. Per això la 2 desapareix de la llista i n'apareix una 4 amb el seu mateix change-cause. El número de revisió identifica l'ordre en què es van aplicar els canvis, no el contingut: un rollback és un canvi més.

Solució 3

3. Sí, els correus se segueixen enviant. La prova és a tres llocs: READY 2/2 i AVAILABLE 2 al Deployment, els 2 pods de la revisió anterior en Running, i sobretot Available: True amb MinimumReplicasAvailable a les conditions. Només UP-TO-DATE 1 delata que hi ha una versió nova intentant entrar sense aconseguir-ho. Confirmació directa:

El ReplicaSet trencat continua amb 1 rèplica: l'undo s'ha registrat però no s'ha executat, perquè el Deployment està pausat.

Has tancat el cercle que vam obrir a la lliçó anterior amb aquell segon ReplicaSet que va aparèixer sense explicació. Ara saps que les dues estratègies natives del Deployment són RollingUpdate i Recreate, i per què l'elecció no és de gust sinó de naturalesa de la càrrega: botiga-web, api-reserves i worker-notificacions toleren dues versions convivint i van amb RollingUpdate; redis-cache no, i va amb Recreate; i postgres-reserves no admet cap de les dues perquè el Deployment no és el seu lloc: dos processos PostgreSQL sobre el mateix directori de dades signifiquen bloqueig en el millor cas i corrupció en el pitjor.

Saps calcular un desplegament sobre el paper abans d'executar-lo: replicas + maxSurge és el sostre de pods i replicas - maxUnavailable el terra de disponibles, i amb aquests dos números pots reconstruir pas a pas el que farà el controlador amb les 4 rèpliques d'api-reserves. Coneixes les combinacions útils i la recomanada per a producció, maxSurge: 1 amb maxUnavailable: 0, que protegeix la capacitat nominal en un pont d'agost. Ajustes el ritme amb minReadySeconds, detectes els encallaments amb progressDeadlineSeconds i conserves la teva capacitat de desfer amb revisionHistoryLimit. Tens clara la regla que ho governa tot: només els canvis sota spec.template creen una revisió, i per això escalar no desplega, canviar un ConfigMap no reinicia res i existeix kubectl rollout restart. I fas servir el joc complet —status, history, undo, pause, resume— amb change-cause documentant cada pas, inclòs el rollback d'un desplegament encallat per una imatge inexistent, resolt sense que un sol client deixés de comprar el seu bitllet.

Queda un advertiment pendent i una mancança grossa. L'advertiment: RollingUpdate és necessari però no suficient per desplegar sense tall real; sense una readinessProbe, Kubernetes marca com a llest un pod el procés del qual acaba d'arrencar i li envia trànsit abans que el pugui atendre. Aquella peça arriba a Verificacions de Salut i Sondes. I la mancança: tot el trànsit del qual portem dues lliçons parlant encara no existeix. Els nostres pods tenen IPs que canvien a cada desplegament, i per parlar amb api-reserves hem hagut de buscar a mà la IP d'un pod concret. A la lliçó següent, Serveis, donarem a cada component de Rutas Norte una adreça estable que sobrevisqui als desplegaments, amb balanceig de càrrega entre rèpliques inclòs.