Saps fer servir totes dues. Has aixecat Aurora Libros amb compose.yaml i overrides per entorn al mòdul 4, i l'has desplegada en un clúster amb StatefulSet, Ingress, HPA i rollback assajat al mòdul 6. Aquesta lliçó no ve a dir-te quina guanya, sinó a donar-te els criteris per decidir quina necessita el teu projecte, amb les equivalències exactes entre tots dos formats i una xifra honesta del cost de mantenir un clúster.

1. No són la mateixa categoria d'eina
2. La pregunta correcta
3. Comparativa a fons, dimensió per dimensió
4. Equivalències conceptuals
5. El mateix aurora-api, en tots dos formats
6. Arbre de decisió
7. El camí intermedi: Compose en producció
8. Swarm com a esglaó, i els serveis que executen Compose
9. Kompose i els límits reals de la conversió
10. El cost ocult de Kubernetes
11. Aurora Libros a tres mides

Comparar Compose amb Kubernetes és com comparar una recepta amb una cuina industrial. Totes dues coses serveixen per menjar, però una és un document i l'altra és un sistema amb personal.

La diferència estructural és a la quarta fila. Compose executa el que li demanes i acaba; Kubernetes guarda la teva intenció i no deixa de comparar-la amb la realitat. Aquell bucle és el que et permet que un node caigui a les quatre de la matinada i els Pods reapareguin en un altre sense que ningú es desperti. També és el que t'obliga a mantenir un pla de control.

No és «quina és millor?». És una bateria de preguntes concretes:

1. Et pots permetre que la plataforma estigui caiguda quinze minuts mentre reinicies una màquina?
2. Quants nodes tindràs de debò d'aquí a un any: un, tres o trenta?
3. Hi ha algú a l'equip que sàpiga depurar un CrashLoopBackOff sense buscar a Internet?
4. Qui està de guàrdia a les tres de la matinada, i cobra per estar-hi?
5. La teva càrrega és constant o té pics de ×8 que exigeixen autoescalat?
6. El pressupost aguanta el pla de control més els nodes amb marge lliure?

Si has respost «quinze minuts són acceptables, un node, ningú, ningú, constant, no» —que és la situació de la majoria de projectes—, Compose és la resposta professional, i dir-ho en veu alta t'estalviarà un any de patiment. Si has respost el contrari en tres preguntes o més, Kubernetes comença a pagar el seu cost.

Les tres últimes files decideixen més projectes que totes les anteriors juntes, i són les que menys apareixen a les comparatives d'Internet.

Gairebé tot el que vas escriure al compose.yaml d'Aurora Libros té traducció. El que canvia no és la idea, sinó quants objectes calen per expressar-la.

Dues files mereixen un avís. La de depends_on: a Kubernetes no existeix l'arrencada ordenada global; el Pod de l'API arrencarà encara que PostgreSQL no hi sigui, fallarà, i CrashLoopBackOff ho reintentarà fins que la base de dades respongui. És lleig de veure i és el correcte: obliga que l'aplicació toleri que les seves dependències no hi siguin, que és just el que vas aprendre a 06-01. I la de Secret: està codificat en base64, no xifrat; sense xifratge en repòs d'etcd i RBAC ben posat, no és un secret, és un text incòmode de llegir.

Compose, tal com va quedar després del mòdul 4:

Vint-i-vuit línies. Ara el mateix a Kubernetes, sense retallar res d'essencial:

La proporció de més del doble de YAML no és un detall estètic: es multiplica per cada servei, i amb quatre serveis i tres entorns tens un directori que ja ningú no llegeix sencer. A canvi, cada línia de més compra alguna cosa real. La pregunta és si necessites el que compra.

Cinc criteris i cap no és «el que es porta». Fixa't que el camí cap a Kubernetes exigeix dos sís seguits —coneixement i pressupost— i que el node H existeix perquè la pitjor decisió possible és un clúster autogestionat que ningú no sap reparar.

Hi ha una idea molt estesa i falsa: que Compose «no és per a producció». Compose en un host ben muntat serveix milions de peticions diàries en empreses reals. El que cal és muntar-lo amb criteri:

Els dos buits que no pot tapar: l'host és un punt únic de fallada (si mor la màquina, mor el servei fins que n'arrenquis una altra) i no hi ha autoescalat. Si el negoci tolera aquests dos buits —i moltíssims negocis els toleren—, has resolt la plataforma amb un fitxer, sense pla de control i sense guàrdies.

Una regla honesta de dimensionament: una VM de 4 vCPU i 8 GB amb la pila d'Aurora Libros ben afinada atén amb escreix uns quants centenars de peticions per segon. Abans de donar per fet que necessites un clúster, mesura amb la prova de càrrega de 06-06.

Si el problema és només el punt únic de fallada, hi ha un esglaó intermedi abans del salt gros.

Swarm (06-03) mereix un paràgraf d'honestedat: és senzill, funciona, i portar el compose.yaml a tres nodes costa afegir deploy: i docker stack deploy. Però el seu ecosistema està congelat, contractar algú que el conegui és més difícil cada any i la documentació de tercers escasseja. Com a esglaó temporal és raonable; com a aposta a cinc anys, pensa-t'ho dues vegades.

Els serveis tipus Cloud Run són la novetat que canvia l'arbre de decisió: autoescalen de zero a centenars d'instàncies sense que existeixi cap clúster a mantenir. Per a ghcr.io/auroralibros/aurora-api:2.0.0 —sense estat, amb sondes, dotze factors i aturada ordenada— encaixen sense tocar res. L'estat se'n va a una base de dades gestionada, i el problema de la disponibilitat deixa de ser teu.

kompose tradueix un compose.yaml a manifestos de Kubernetes. És útil com a punt de partida i perillós com a resultat final.

La conclusió pràctica: kompose t'estalvia el primer 60 % del teclejat i no t'estalvia res del pensament. Tot el que fa que un desplegament sigui apte per a producció —sondes separades, requests i limits mesurats, PDB, política de xarxa, Ingress amb TLS— continua sent feina teva. Tracta'l com un esborrany, revisa'l línia a línia i no l'apliquis mai directament contra un clúster real.

El que no surt a les presentacions:

L'última fila és la que decideix. Formula-la així a la reunió: «si el clúster es trenca un dissabte a les tres de la matinada, qui l'arregla, en quant de temps i cobrant què?». Si no hi ha una resposta amb un nom propi, Kubernetes encara no és una opció, per molt bé que quedi a l'arquitectura.

I convé dir-ho també a l'inrevés: quan la resposta existeix, Kubernetes torna amb escreix el que costa. Autoescalat real, desplegaments sense tall, reprogramació automàtica, quotes per equip i un ecosistema que resol problemes que ni sabies que tenies. L'error no és triar Kubernetes; és triar-lo abans d'hora.

Fixa't en la tercera columna: molt trànsit en pic no implica Kubernetes. Implica autoescalat, i hi ha més d'una manera d'aconseguir-lo. I a la segona, el que inclina la balança no és només el trànsit: és que existeix una persona amb perfil de sistemes. Sense aquella persona, la recomanació seria una altra encara que el trànsit fos el mateix.

• Triar Kubernetes pel currículum. És una raó real i humana, i és la pitjor de totes per al projecte. Si el vols aprendre, munta un clúster de laboratori amb kind, no la plataforma de producció de l'empresa.
• Creure que «Compose no és per a producció». Amb digests, límits, rotació de logs, còpies provades i vigilància, Compose sosté negocis reals. El que no dona és tolerància a la caiguda de l'host ni autoescalat.
• Aplicar la sortida de kompose sense revisar-la. Perd depends_on, no genera les tres sondes ni Ingress, HPA o PDB, i ignora els bind mounts.
• Migrar a Kubernetes sense haver mesurat. Abans de justificar un clúster per rendiment, executa la prova de càrrega de 06-06 sobre l'host actual. El límit real sol ser a la base de dades, i un clúster no el mou.
• Traduir depends_on esperant arrencada ordenada. No existeix. L'aplicació ha de reintentar; si no ho fa, arregla-la abans de migrar.
• Tractar els Secret com a xifrats. Són base64. Sense xifratge en repòs d'etcd i RBAC estricte, no protegeixen res.
• Consell: escriu la decisió i els seus motius en un document breu dins del repositori, amb data. D'aquí a un any voldràs saber per què es va triar, i si les premisses continuen sent certes.
• Consell: mantén el compose.yaml viu encara que despleguis a Kubernetes. És la millor manera d'aixecar la pila sencera en local per desenvolupar i depurar.
• Consell: si dubtes, comença per Compose. Migrar de Compose a Kubernetes amb una imatge ben feta és una feina de dies; desmuntar un clúster que ningú no sap operar costa mesos.

Exercici 1 — Tradueix un servei complet. Pren el servei aurora-cache (redis:7-alpine, sense exposar a l'exterior, amb volum per a la persistència opcional, límit de 256 MB de memòria i un healthcheck amb redis-cli ping) tal com és al compose.yaml. Escriu-lo a Kubernetes: Deployment, Service intern i PersistentVolumeClaim. Indica quin element de l'original no té equivalent directe i com el resols.

Exercici 2 — Aplica l'arbre de decisió. Per a cada escenari, recorre l'arbre de §6, indica el node final i justifica la decisió en tres frases. (a) Una API interna de facturació que fan servir 30 empleats en horari d'oficina, amb un desenvolupador que també fa d'administrador. (b) Una plataforma de venda d'entrades que exhaureix un concert en 90 segons, amb equip de plataforma de cinc persones i guàrdies. (c) Un blog corporatiu amb 400 visites al dia que un proveïdor extern vol desplegar en un clúster gestionat «perquè és l'estàndard».

Exercici 3 — El cost real de la decisió. Aurora Libros creix i la direcció pregunta si «cal passar a Kubernetes». Prepara una comparativa d'una pàgina amb: cost mensual estimat d'infraestructura en tots dos escenaris (fes servir xifres aproximades de proveïdor i explicita els teus supòsits), temps d'aprenentatge i de posada en marxa, quina millora mesurable aporta el clúster, quin risc nou introdueix, i la teva recomanació amb la condició que s'hauria de complir per canviar-la.

Solució 1.

El que no té equivalent directe és el healthcheck únic de Compose: aquí s'ha desdoblat en liveness i readiness, totes dues amb redis-cli ping però amb períodes diferents, perquè a Kubernetes «està viu» i «pot rebre trànsit» són preguntes separades. Tres decisions més que l'enunciat no donava i que cal raonar: strategy: Recreate en lloc de rolling, perquè un PVC ReadWriteOnce no es pot muntar en dos Pods alhora i el rolling es quedaria bloquejat; el --maxmemory de Redis posat per sota del limits.memory del contenidor, perquè Redis expulsi claus abans que el kernel mati el procés per OOM; i l'absència de ports exposats cap a fora, ja que el Service sense tipus és ClusterIP i només s'hi arriba des de dins del clúster, que és exactament el que es demanava.

Solució 2.

(a) API interna de facturació. Tall tolerable: hores, perquè fora de l'horari d'oficina no hi ha ningú que la faci servir. Un sol node n'hi ha prou i no hi ha pics. Node final: Compose en un host ben muntat. L'únic administrador no pot sostenir un clúster, i un desplegament amb restart: unless-stopped, còpies provades i monitoratge bàsic cobreix el requisit amb escreix. Afegir-hi Kubernetes multiplicaria el cost operatiu sense millorar res perceptible.

(b) Venda d'entrades. El tall tolerable és zero durant els 90 segons que importen, hi ha equip de plataforma i hi ha guàrdies. El pic és brutal però previsible en l'instant, cosa que permet preescalar abans de l'esdeveniment en lloc d'esperar que reaccioni l'HPA. Node final: Kubernetes gestionat. És el cas de llibre: alta disponibilitat real, autoescalat, desplegaments sense tall i un equip que el pot operar. Aquí el clúster torna el que costa.

(c) Blog corporatiu. 400 visites al dia són unes 0,005 peticions per segon de mitjana. El tall tolerable és d'hores. Node final: Compose en un host, o directament allotjament estàtic si el contingut ho permet. Un clúster gestionat per a això costa més al mes del que el mateix blog genera de valor i hi afegeix una dependència que ningú de l'equip no sabrà reparar. Que sigui «l'estàndard» no és un requisit: demana al proveïdor que justifiqui la decisió amb els mateixos criteris de l'arbre i la conversa s'acaba sola.

Solució 3. Estructura de la comparativa (els imports són il·lustratius i s'han de substituir pels del proveïdor i la regió reals):

Millores mesurables del clúster: recuperació automàtica davant de la caiguda d'un node (de «minuts amb intervenció humana» a «segons sense ella»), autoescalat de 3 a 12 rèpliques davant de pics, i desplegaments sense tall amb rollback en una comanda. Riscos nous: dependència d'un coneixement que avui no existeix a l'equip, més superfície de configuració que pot fallar, i cost fix que no baixa quan baixa el trànsit.

Recomanació: continuar amb Compose i revisar la decisió amb un disparador concret, no amb una data. Per exemple: «passem a Kubernetes gestionat quan es compleixin dues d'aquestes tres condicions: superar de manera sostinguda el 60 % de CPU de l'host, que el negoci fixi un objectiu de disponibilitat per damunt del 99,9 %, o que s'incorpori a l'equip una persona amb experiència real operant clústers». Escriure el disparador converteix una discussió d'opinions en una condició verificable, i aquest és el veritable lliurable de l'exercici.

Ja pots defensar la decisió amb criteris en lloc de fer-ho amb modes. Tens clar el primer i el més oblidat: no són la mateixa categoria d'eina. Compose és un descriptor que executes i acaba; Kubernetes guarda la teva intenció a etcd i no deixa de reconciliar-la amb la realitat. D'aquella diferència en surten totes les altres, incloses les bones —reprogramació automàtica, autoescalat, desplegaments sense tall— i les cares.

Tens la comparativa per dimensions, amb les tres files que decideixen més projectes que cap altra: cost d'infraestructura, cost operatiu i maduresa de l'equip. Tens la taula d'equivalències completa, amb els seus dos avisos importants: depends_on no té traducció perquè a Kubernetes no existeix l'arrencada ordenada, i un Secret és base64, no xifrat. I has vist el mateix aurora-api en tots dos formats: 28 línies davant de 63, un objecte davant de tres, amb la pregunta correcta al damunt —necessites el que compren aquelles línies de més?—.

L'arbre de decisió et dona cinc criteris concrets i un detall que convé recordar: arribar a Kubernetes exigeix dos sís seguits, coneixement i pressupost, i la pitjor opció de totes és un clúster autogestionat que ningú no sap reparar. Saps que Compose en producció és una decisió perfectament professional quan l'host està ben muntat —digests, límits, rotació de logs, còpies provades, TLS automàtic—, amb els seus dos buits declarats: punt únic de fallada i absència d'autoescalat. Coneixes els esglaons intermedis: Swarm, honest però congelat; els serveis que executen la teva imatge sense que existeixi cap clúster; i kompose, que t'estalvia el 60 % del teclejat i res del pensament.

I t'endús la pregunta que ordena tota la resta: si el clúster es trenca un dissabte a les tres de la matinada, qui l'arregla, en quant de temps i cobrant què?. Amb les tres versions d'Aurora Libros —la botiga petita amb Compose, la que creix amb Kubernetes gestionat, la de campanya amb autoescalat sense clúster— tens tres respostes de referència i l'hàbit d'escriure la decisió, amb la seva data i el seu disparador de revisió, dins del repositori.

A la lliçó següent baixem de la infraestructura a l'escriptori: Docker Desktop. Què és exactament aquella VM Linux que fas servir sense veure-la, per què explica el rendiment dels bind mounts, quines funcions aporta, quines condicions de llicència té —i per què convé consultar-les abans d'instal·lar-lo a l'empresa— i quines alternatives existeixen a cada sistema operatiu.