Tancàvem la lliçó anterior dient que ja tenies clúster, CLI i llenguatge de manifests, i que només faltava el pacient. Aquí el tens. Aquesta lliçó presenta a fons Rutas Norte S.L., l'empresa fictícia la plataforma de venda de bitllets d'autobús de la qual desplegarem i operarem sobre Kubernetes durant els onze mòduls restants. No és un exemple decoratiu: cada concepte que aprenguis a partir d'ara entrarà en escena perquè Rutas Norte el necessita, i al final del curs tindràs una plataforma completa, segura, observable i autoescalada, construïda peça a peça. Veuràs la situació de partida de l'empresa, cadascun dels seus sis components, l'arquitectura objectiu, el mapa de quin mòdul aporta què, i les convencions que seguirem sempre. I acabaràs amb el primer desplegament real: botiga-web corrent al teu clúster i responent al teu navegador.

1. L'empresa i el seu problema actual
2. Els sis components de la plataforma
3. Arquitectura objectiu sobre Kubernetes
4. Full de ruta: què aporta cada mòdul
5. Convencions del projecte
6. Primer desplegament: botiga-web a rutas-norte-dev
7. Per què aquest pod és fràgil

Rutas Norte S.L. és un operador d'autobusos interurbans que ven els seus bitllets per internet a través de la plataforma Rutas Norte. Tretze persones al departament tècnic, unes 4.000 reserves diàries de mitjana i 25.000 els dies punta.

La seva infraestructura actual:

• Dues màquines llogades amb Docker Compose. Una serveix el web i l'API; l'altra, la base de dades.
• Desplegaments manuals: algú es connecta per SSH, executa docker compose pull && docker compose up -d i creua els dits. Hi ha un tall de servei d'entre un i dos minuts, així que només es desplega els dimarts de matinada.
• Sense autoreparació: al març, el contenidor de l'API va morir a les 02:40 per una fuita de memòria i ningú no se'n va adonar fins a les 07:15. Quatre hores i mitja sense vendre bitllets.
• Sense elasticitat: en els pics de ponts i vacances el trànsit es multiplica per sis. La resposta ha estat contractar una màquina dimensionada per a l'agost i pagar-la els dotze mesos.
• Secrets per tot arreu: la contrasenya de PostgreSQL viu en un fitxer .env que s'ha compartit per correu. Aquesta base de dades conté nom, DNI, telèfon i correu de cada client.
• Sense observabilitat: els logs són en fitxers dins de cada contenidor. Diagnosticar un problema implica entrar per SSH i buscar amb grep.

La direcció tècnica ha aprovat la migració a Kubernetes amb quatre objectius mesurables: zero talls als desplegaments, recuperació automàtica de caigudes, capacitat elàstica als pics i traçabilitat i control d'accés sobre les dades personals. Aquests quatre objectius són, un a un, el temari que tens al davant.

Aquests noms t'acompanyaran durant tot el curs. Conserva'ls exactament així.

• Què és: el frontal públic. Una SPA servida per nginx amb els resultats de cerca, el selector de seients i el procés de pagament.
• Estat: sense estat. Qualsevol rèplica serveix qualsevol petició.
• Imatge: registry.rutasnorte.example/botiga-web:1.8.0
• Domini: www.rutasnorte.example
• Què necessita del clúster: diverses rèpliques, exposició HTTP/HTTPS a l'exterior, configuració injectada (la URL de l'API varia per entorn) i actualització sense tall.

• Què és: l'API REST en Node.js. Consulta disponibilitat de places, calcula preus, crea reserves i emet bitllets. És el cor del negoci.
• Estat: sense estat. Tota la persistència és a PostgreSQL i a Redis.
• Imatge: registry.rutasnorte.example/api-reserves:2.4.0
• Domini: api.rutasnorte.example
• Què necessita del clúster: rèpliques, autoescalat per càrrega, credencials de base de dades com a secret, sondes de salut, límits de recursos i accés restringit a la base de dades.

• Què és: PostgreSQL 16 amb les taules de reserves, clients, rutes i expedicions.
• Estat: amb estat. És el component crític del sistema.
• Imatge: postgres:16
• Què necessita del clúster: emmagatzematge persistent que sobrevisqui a la recreació del pod, identitat de xarxa estable, credencials gestionades com a secret, còpies de seguretat i una política de xarxa que impedeixi que s'hi connecti qualsevol.

• Què és: memòria cau en memòria de la disponibilitat de places per expedició i data. Absorbeix la majoria de les consultes de cerca i evita saturar PostgreSQL.
• Estat: amb estat, però prescindible. Si es perd, es repobla des de la base de dades; només es degrada el rendiment durant uns minuts.
• Imatge: redis:7.2-alpine
• Què necessita del clúster: un nom estable, límits de memòria estrictes i configuració de política d'expulsió.

• Què és: procés en segon pla que consumeix una cua i envia els correus de confirmació de reserva i els recordatoris de viatge.
• Estat: sense estat, però no rep trànsit entrant: no cal que sigui accessible des de fora.
• Imatge: registry.rutasnorte.example/worker-notificacions:1.2.0
• Què necessita del clúster: rèpliques escalades per longitud de cua i no per CPU, credencials SMTP com a secret, i aturada ordenada per no perdre un enviament a mig fer.

• Què és: tasca programada que cada nit a les 02:30 calcula l'ocupació per línia i expedició del dia anterior i deixa un informe per al departament comercial.
• Estat: sense estat, d'execució finita: arrenca, treballa uns minuts i acaba.
• Imatge: registry.rutasnorte.example/informes-ocupacio:1.0.3
• Què necessita del clúster: execució programada, control de reintents, límit d'execucions simultànies i historial de resultats.

Aquesta taula conté ja una lliçó de disseny: el tipus d'objecte de Kubernetes que necessites es dedueix de dues preguntes —té estat? i rep trànsit?— abans d'escriure una sola línia de YAML.

Aquesta és la destinació a la qual arribarem al final del mòdul 11.

Punts que convé llegir al diagrama:

• Una sola porta d'entrada: l'Ingress Controller termina el TLS i encamina per domini cap al Service corresponent.
• Cap component no coneix IP: tot es comunica pel nom del Service, resolt pel DNS intern del clúster.
• postgres-reserves és l'únic amb disc persistent, i només ha de ser abastable des d'api-reserves, el worker i el CronJob. Això es garantirà amb una NetworkPolicy al mòdul 4.
• worker-notificacions no té Service: ningú no li parla, ell consumeix feina i surt a parlar amb altres.

Aquesta taula és el contracte del curs: diu quina peça de Rutas Norte afegim o millorem a cada mòdul.

Aquestes regles s'apliquen a totes les lliçons. Adopta-les des d'ara; són també bones pràctiques del món real.

Durant el mòdul 1 i bona part del 2 treballarem només a rutas-norte-dev.

Tots els objectes porten aquestes tres etiquetes com a mínim:

Això permet consultes com aquestes, que valen or quan el clúster creix:

El registre d'imatges de l'empresa és registry.rutasnorte.example. La regla més important del projecte quant a imatges:

Cada versió es publica amb una etiqueta única i immutable, que no es reutilitza mai. Prohibit latest en qualsevol entorn.

La que vam definir a la lliçó Objectes, Manifests YAML i el Model Declaratiu:

I la regla d'or que l'acompanya: si un canvi no és a Git, no existeix. Res de kubectl edit com a mètode de desplegament.

Prou teoria. Desplegarem el primer tros real de Rutas Norte.

Fixa't que l'hem creat amb un manifest, no amb kubectl create namespace. És una decisió deliberada: el namespace forma part de la definició del projecte i ha de ser a Git com tota la resta.

I ara, el consell de productivitat de la lliçó 01-05, que t'estalviarà escriure -n rutas-norte-dev centenars de vegades:

Repàs camp a camp, recolzant-nos en el que hem après:

• apiVersion: v1 i kind: Pod: el Pod pertany al grup core, per això no porta prefix de grup.
• metadata.name: nom únic dins del namespace.
• metadata.labels: les tres etiquetes del projecte. Al mòdul 2 seran les que faci servir el Service per trobar els seus pods.
• metadata.annotations: metadada informativa, no consultable.
• spec.containers: una llista. Aquí un sol element, com serà habitual.
• image: nginx:1.27-alpine: fem servir la imatge pública nginx perquè registry.rutasnorte.example és un registre fictici i no existeix. A tot el curs, quan aparegui una imatge de registry.rutasnorte.example, substitueix-la mentalment —i al teu clúster— pel seu equivalent públic. Etiqueta explícita, mai latest, segons la convenció del projecte.
• ports: és documentació informativa; no obre res per si sol. L'exposició real vindrà amb el Service (mòdul 2).
• resources: requests és el que el scheduler reserva per decidir en quin node hi cap; limits és el sostre que el kubelet imposa. Els estudiarem a fons al mòdul 3, però convé posar-los des del primer dia.

Estàs veient, en directe, el recorregut de la lliçó Arquitectura de Kubernetes: Pending mentre el scheduler tria node, ContainerCreating mentre el kubelet descarrega la imatge i prepara la xarxa, Running quan el contenidor és viu. Talla amb Ctrl+C.

Els quatre esdeveniments expliquen la història completa: el scheduler va assignar node, i després el kubelet va obtenir la imatge, va crear el contenidor i el va arrencar. Exactament el repartiment de responsabilitats que vam estudiar.

El pod té IP 10.244.0.21, però aquesta IP només existeix dins del clúster. Per arribar-hi des de la teva màquina fem servir port-forward:

Obre http://localhost:8080 al navegador: veuràs la pàgina de benvinguda de nginx. A Rutas Norte, aquella seria la portada de la botiga de bitllets. Deixa l'ordre corrent mentre proves i talla-la amb Ctrl+C.

Des d'un altre terminal també ho pots comprovar sense navegador:

Enhorabona: acabes de desplegar el primer component de Rutas Norte a Kubernetes.

Abans de celebrar-ho gaire, fem l'experiment que dona sentit al mòdul 2.

Ha desaparegut i no torna. Compara-ho amb el que vam dir a la lliçó de conceptes: un pod solt no té cap controlador que el vigili. Ningú no executa un bucle de reconciliació sobre ell, perquè l'estat desitjat que vas declarar era literalment "que existeixi aquest pod", i en esborrar-lo també vas esborrar aquella declaració.

Els quatre problemes d'un pod solt:

La solució és la jerarquia que ja coneixes del mapa conceptual: Deployment → ReplicaSet → Pod. Un Deployment declara "vull 3 rèpliques d'aquesta imatge", el ReplicaSet les manté contra vent i marea, i un Service els dona un nom estable.

Torna a crear el pod per deixar el clúster com estava i tancar el mòdul amb la plataforma en marxa:

• Aplicar al namespace equivocat. Si kubectl get pods no mostra res, comprova el namespace amb kubectl config view --minify | grep namespace o fes servir -A. Declarar metadata.namespace explícitament a cada manifest, com fem aquí, elimina el problema d'arrel.
• Fer servir registry.rutasnorte.example literalment. És un registre fictici: no existeix. El pod es quedaria en ImagePullBackOff. Als exercicis pràctics fes servir sempre la imatge pública equivalent (nginx, postgres, redis, node).
• Creure que ports.containerPort exposa el pod. No fa res per si sol: és documentació. L'accés real arriba amb port-forward (per a proves), Service (mòdul 2) o Ingress (mòdul 4).
• Deixar port-forward com a solució. És una eina de depuració d'un sol usuari, lligada al teu terminal. No és mai una forma d'exposar un servei.
• Crear pods solts i acostumar-s'hi. Aquest ha estat un exercici deliberat per entendre la fragilitat. A partir del mòdul 2, tot va en Deployments.
• Oblidar resources. Sense requests, el scheduler no pot planificar bé; sense limits, un contenidor descontrolat pot tombar els seus veïns. Posa'ls des del principi encara que els ajustos vinguin després.
• Consell: crea ja el repositori amb l'estructura k8s/ i fes un commit amb namespace.yaml i botiga-web-pod.yaml. Treballar així des de la primera lliçó és la diferència entre acabar el curs amb una plataforma reproduïble i acabar amb un clúster ple de coses que ningú no sap com es van crear.

Sense escriure cap manifest, completa una taula amb els sis components de Rutas Norte i, per a cadascun, respon: (a) té estat?, (b) rep trànsit entrant i d'on?, (c) quin objecte de Kubernetes el governarà?, i (d) què passaria avui, amb Docker Compose, si la màquina que l'allotja s'apagués? Després, justifica en tres línies per què redis-cache i postgres-reserves, essent tots dos "amb estat", reben tractaments molt diferents.

Seguint totes les convencions del projecte, crea el manifest k8s/base/redis-cache-pod.yaml per a un pod redis-cache a rutas-norte-dev amb la imatge pública redis:7.2-alpine, el port 6379, les tres etiquetes del projecte i requests de 50m de CPU i 64Mi de memòria. Després:

1. Valida'l sense tocar el clúster i aplica'l.
2. Comprova que està Running i esbrina la seva IP i el seu node.
3. Entra al contenidor i comprova que Redis respon executant redis-cli ping.
4. Mostra únicament els pods de la plataforma Rutas Norte fent servir l'etiqueta comuna.

1. Simula una caiguda de l'aplicació matant el procés principal del contenidor de botiga-web amb kubectl exec, i observa amb --watch què passa. Torna el contenidor? Canvia el comptador RESTARTS? Canvia la IP del pod?
2. Ara esborra el pod sencer amb kubectl delete pod i observa de nou. Torna?
3. Explica la diferència entre els dos casos indicant quin component actua en cada un.
4. Escriu en dues frases quin objecte necessitaries perquè el segon cas també es recuperés sol.

Solució 1

redis-cache i postgres-reserves reben tractaments diferents perquè l'estat de Redis és reconstruïble: si es perd, es repobla des de la base de dades i només es degrada el rendiment. L'estat de PostgreSQL és la font de veritat del negoci: perdre'l significa perdre reserves i dades personals de clients. Per això PostgreSQL exigeix emmagatzematge persistent, identitat estable, còpies de seguretat i aïllament de xarxa, mentre que Redis només necessita un límit de memòria i una política d'expulsió.

Solució 2

Solució 3

El contenidor sí que torna: RESTARTS passa de 0 a 1 i la IP del pod no canvia, perquè és el mateix pod. Qui el recupera és el kubelet, aplicant la restartPolicy: Always que un pod té per defecte. El kubelet reinicia contenidors dins d'un pod existent.

El pod no torna. No hi ha cap controlador que vigili la seva existència.

3. La diferència és en qui actua i sobre què: el kubelet vigila els contenidors dins dels pods que té assignats i els reinicia si moren, però no pot recrear un pod que ja no existeix com a objecte a l'API. Recrear pods és feina d'un controlador del kube-controller-manager, i un pod solt no en té cap d'associat: en esborrar-lo, vas esborrar el mateix estat desitjat.

4. Necessites un Deployment, que crea un ReplicaSet el controlador del qual manté permanentment el nombre de rèpliques declarat. Amb ell, l'estat desitjat deixa de ser "que existeixi aquest pod concret" i passa a ser "que existeixin N pods amb aquestes característiques", de manera que esborrar-ne un provoca immediatament la creació d'un altre.

Ja coneixes el projecte que dona sentit a tot el curs. Rutas Norte S.L. és una empresa amb problemes absolutament reals —caigudes nocturnes sense resposta, pics de demanda en ponts i vacances, desplegaments amb tall de servei i dades personals de clients mal protegides— i la seva plataforma es compon de sis peces amb necessitats ben diferenciades: dos frontals sense estat, una base de dades crítica amb estat, una memòria cau prescindible, un worker sense trànsit entrant i una tasca nocturna programada. Tens l'arquitectura objectiu, el mapa de quin mòdul aporta què, i les convencions —namespaces per entorn, esquema d'etiquetes, etiquetes d'imatge immutables i estructura k8s/ versionada a Git— que aplicarem sense excepció.

I, sobretot, ja has desplegat el teu primer component: botiga-web corrent a rutas-norte-dev, inspeccionat amb get, describe i logs, i visible al teu navegador mitjançant port-forward. També has comprovat en primera persona el seu punt feble: un pod solt que, en esborrar-se, no torna mai.

Amb això tanques el mòdul 1. Saps què és Kubernetes, com està construït, què significa cada terme, tens un clúster funcionant, domines kubectl i entens el model declaratiu. El mòdul 2, Components Principals de Kubernetes, arrenca just on acaba aquesta lliçó: convertirem aquell pod fràgil en un Deployment amb diverses rèpliques que es recupera sol, aprendrem primer què és exactament un Pod per dins i com un ReplicaSet el manté amb vida, i donarem a botiga-web i a api-reserves una adreça estable amb Serveis. La plataforma Rutas Norte comença a prendre forma de debò.