Al final de la lliçó anterior van quedar tres preguntes obertes. Com fer que la migració d'esquema s'executi automàticament abans que arrenqui api-reserves, en comptes de com un Job a part? Com evitar que api-reserves entri en CrashLoopBackOff quan arrenca abans que postgres-reserves? Com exportar mètriques de PostgreSQL sense tocar la imatge oficial?

Les tres es responen igual: posant més d'un contenidor al mateix pod.

Des de la lliçó 02-01 sabem que un pod és un grup de contenidors que comparteixen espai de noms de xarxa —i per tant localhost—, volums i cicle de vida. Fins ara no havíem aprofitat aquesta capacitat: tots els pods de Rutas Norte tenen un sol contenidor. En aquesta lliçó la farem servir amb criteri, que és la part difícil: la majoria de pods multicontenidor mal dissenyats neixen de posar dues aplicacions juntes perquè "van relacionades", i això sempre acaba malament.

1. Quan un pod necessita diversos contenidors i quan això és un error
2. Init containers: preparació seqüencial abans de l'arrencada
3. Casos d'ús d'init containers a Rutas Norte
4. Diagnòstic d'init containers fallits
5. Sidecars natius: init containers amb restartPolicy: Always
6. Els tres patrons clàssics: sidecar, ambaixador i adaptador
7. Patró sidecar: exportador de mètriques al costat de postgres-reserves
8. Patró ambaixador: la connexió amb la passarel·la de pagaments
9. Patró adaptador: normalitzar el log de worker-notificacions
10. Ordre d'arrencada i terminació, i el cost real

La regla d'or, formulada amb precisió:

Dos processos van al mateix pod quan estan tan acoblats que no té sentit escalar-los, actualitzar-los ni executar-los per separat, i un d'ells existeix únicament per servir l'altre.

La conseqüència immediata de compartir pod és que comparteixen destí: es programen al mateix node, escalen junts, es reinicien junts i s'actualitzen junts. Si api-reserves necessita 5 rèpliques i worker-notificacions en necessita 2, posar-los al mateix pod obliga a tenir-ne 5 de cadascun. Això és un error de disseny, no una optimització.

Tres preguntes de control abans d'afegir un contenidor a un pod existent:

1. Han d'escalar junts sempre? Si la resposta és no, són dues càrregues de treball diferents.
2. El segon serveix exclusivament el primer? Si altres pods també el necessiten, és un Service a part.
3. Necessiten compartir localhost o un sistema de fitxers? Si no, no hi ha motiu tècnic per ajuntar-los.

Kubernetes ofereix dues categories de contenidor auxiliar:

• initContainers: s'executen abans, en ordre, un rere l'altre, i han d'acabar amb èxit.
• Contenidors auxiliars que acompanyen el principal durant tota la vida del pod: els sidecars.

Un init container és un contenidor que s'executa fins a completar-se abans que arrenqui cap contenidor principal. Si n'hi ha diversos, s'executen en l'ordre en què apareixen al manifest, cadascun esperant que l'anterior acabi amb èxit.

Propietats que els distingeixen dels contenidors normals:

Aquesta última fila és més útil del que sembla: l'init container pot fer servir una imatge amb psql, curl o git que la imatge de producció no té, sense engreixar la imatge final ni ampliar-ne la superfície d'atac.

Sintaxi bàsica:

Els init containers també consumeixen recursos i participen en el càlcul del que el pod demana al scheduler. La fórmula efectiva és:

És a dir, un init container que demana 2 GiB obliga el scheduler a trobar un node amb 2 GiB lliures, encara que l'aplicació només necessiti 256 MiB. Convé mantenir-los lleugers.

Quan s'aixeca un entorn des de zero, api-reserves pot arrencar abans que la base de dades estigui llesta, fallar en connectar, sortir i entrar en CrashLoopBackOff. Acaba recuperant-se, però l'arrencada triga minuts i els esdeveniments s'omplen de soroll que emmascara problemes reals.

pg_isready és una utilitat de la mateixa imatge de PostgreSQL que retorna 0 si el servidor accepta connexions. El bucle no té límit d'intents a propòsit: el pod es quedarà en Init:0/1 indefinidament, cosa que a kubectl get pods és un senyal claríssim de "la base de dades no està disponible", molt millor que un CrashLoopBackOff la causa del qual s'ha d'anar a buscar als logs.

Una nota de disseny honesta: això no substitueix que l'aplicació gestioni la reconnexió. Si postgres-reserves cau dues hores després, l'init container ja no hi és per ajudar. És una comoditat per a l'arrencada, no una garantia de resiliència.

Aquí reprenem la pregunta que va deixar oberta la lliçó 06-03. La migració pot anar en un init container en comptes d'en un Job separat:

Avantatge evident: la migració va acoblada al desplegament. És impossible desplegar el codi 2.5.0 sense haver migrat, perquè el contenidor de l'aplicació no arrenca si l'init container no acaba bé.

Però hi ha un parany important que cal conèixer:

Amb 4 rèpliques d'api-reserves, l'init container de migració s'executa 4 vegades, potencialment en paral·lel durant una actualització.

Conseqüències i mitigacions:

• La migració ha de ser idempotent i estar protegida per un lock. IF NOT EXISTS no n'hi ha prou: dos ALTER TABLE simultanis es poden bloquejar mútuament. Una eina de migracions seriosa (Flyway, Liquibase, golang-migrate) pren un lock d'aplicació a la base de dades i les altres instàncies esperen.
• Si la migració triga minuts, cada rèplica paga aquesta espera, i el desplegament s'allarga.

Recomanació per a Rutas Norte: Job separat per a migracions grans o destructives (índexs sobre milions de files, canvis de tipus), initContainer per a migracions petites i idempotents del dia a dia.

botiga-web serveix HTML estàtic des de nginx, i la plantilla del peu de pàgina canvia segons l'entorn. En comptes de construir tres imatges, un init container genera el fitxer en un volum compartit:

El mecanisme és exactament l'emptyDir de 05-01: un volum buit creat amb el pod, compartit per tots els seus contenidors. L'init container escriu, nginx llegeix en només lectura. Quan el pod mor, l'emptyDir desapareix, i tant se val: es regenera a l'arrencada següent.

Els init containers tenen els seus propis estats a la columna STATUS, i saber llegir-los estalvia molt de temps.

Un cas real: api-reserves encallada perquè la base de dades no respon.

Init:0/2 sostingut quatre minuts: el primer init container (esperar-postgres) continua al seu bucle.

La clau és a -c <nom>. Sense aquesta bandera, kubectl logs intenta llegir el contenidor principal, que encara no existeix, i respon amb un error confús.

Un altre cas: la migració falla.

Diagnòstic: la migració no és idempotent. Hi faltava l'IF NOT EXISTS.

Ordres útils per inspeccionar init containers:

A la sortida de describe, els init containers apareixen en un bloc Init Containers: abans del bloc Containers:, cadascun amb el seu estat, el seu codi de sortida i la seva raó de terminació.

Durant anys, un sidecar era simplement "un altre contenidor més a la llista containers". Funcionava, però tenia dos defectes greus que Kubernetes 1.29 va resoldre i que són estables des de 1.33.

Problema 1: no hi ha ordre d'arrencada. Tots els contenidors de containers arrenquen en paral·lel. Si el sidecar és un proxy pel qual l'aplicació ha de sortir a la xarxa, i l'aplicació arrenca abans que el proxy, les primeres peticions fallen.

Problema 2: els Jobs no acabaven mai. Un Job el pod del qual té un sidecar era un problema sense solució neta. El contenidor principal acaba amb èxit, però el sidecar continua viu, així que el pod no arriba mai a Succeeded i el Job es queda penjat indefinidament. L'única sortida eren apedaçaments lletjos: fitxers sentinella en un emptyDir, o que el contenidor principal matés el sidecar per l'API.

Aquest únic camp canvia completament la semàntica del contenidor:

Les quatre conseqüències pràctiques, en ordre d'importància:

1. Arrenca abans que els contenidors principals, garantint que el proxy o l'exportador estiguin llestos quan l'aplicació comença a treballar.
2. Continua viu durant tota la vida del pod i es reinicia si mor, cosa que un init container normal no fa.
3. S'acaba després dels contenidors principals, així que un sidecar de logs captura els últims missatges del tancament.
4. No impedeix que un Job acabi. Quan els contenidors de containers acaben, el kubelet para els sidecars i el pod arriba a Succeeded. Això desbloqueja tota la feina per lots amb sidecars: un CronJob amb proxy, amb exportador de mètriques o amb adaptador de logs simplement funciona.

Una precisió sobre l'ordre: el pod no espera que el sidecar acabi (no ho farà mai), sinó que estigui iniciat —i que passi la seva startupProbe si en té—. A diferència dels init containers normals, els sidecars sí que admeten sondes, tema de la lliçó 07-01.

Regla de decisió senzilla: si el contenidor auxiliar ha d'estar llest abans que l'aplicació, o si el pod és d'un Job, fes servir sidecar natiu. En els altres casos, un contenidor normal a containers continua sent perfectament vàlid.

Els tres noms vénen de l'article fundacional de Brendan Burns i Dave Oppenheimer sobre patrons de disseny per a sistemes distribuïts. Es distingeixen per cap a on va el flux i què transformen.

Una altra manera de memoritzar-ho:

• El sidecar afegeix alguna cosa.
• L'ambaixador simplifica el que l'aplicació veu del món exterior.
• L'adaptador simplifica el que el món exterior veu de l'aplicació.

Tots tres es recolzen en els mateixos dos mecanismes, que ja coneixes de 02-01:

• localhost compartit: tots els contenidors del pod comparteixen l'espai de noms de xarxa, així que es parlen per 127.0.0.1 sense passar per la xarxa del clúster, sense DNS i sense latència apreciable. Corol·lari: dos contenidors del mateix pod no poden fer servir el mateix port.
• Volums compartits: un emptyDir muntat als dos permet passar fitxers. És el canal del patró adaptador.

La imatge postgres:16.4 no exposa mètriques en format Prometheus. Modificar-la seria un error: perdríem les actualitzacions oficials i hauríem de mantenir una imatge pròpia. La solució és un sidecar que es connecta a PostgreSQL per localhost, executa consultes d'estat i publica el resultat a /metrics.

Afegim el sidecar al StatefulSet que vam construir a 06-01:

Punts que expliquen el patró:

• DATA_SOURCE_URI: localhost:5432: no hi ha nom de servei ni DNS. El sidecar parla amb PostgreSQL a través del bucle local del pod. És l'avantatge fonamental: latència mínima, sense exposar el port 5432 a la xarxa del clúster per a això, i sense necessitat de NetworkPolicy addicional, perquè el trànsit ni tan sols surt del pod.
• Sidecar natiu: arrenca abans que PostgreSQL. En principi no és imprescindible aquí, però garanteix que no perdem les mètriques dels primers segons de vida, que són justament les de l'arrencada i la recuperació del WAL.
• Recursos modestos i separats: 20m de CPU i 48 MiB. Se sumen als de PostgreSQL en el càlcul del scheduler.
• Enduriment propi: el sidecar corre com a nobody i amb sistema de fitxers de només lectura. No necessita res més, i així una fallada a l'exportador no compromet el contenidor de la base de dades.

Nota important sobre QoS: a 03-05 vam establir que postgres-reserves és de classe Guaranteed. Perquè el pod ho continuï sent, tots els seus contenidors —sidecar inclòs— han de tenir requests iguals a limits. Amb els valors de dalt (20m/100m, 48Mi/96Mi) el pod passaria a Burstable. Si volem conservar Guaranteed, cal igualar-los:

És una conseqüència poc intuïtiva d'afegir sidecars que convé tenir present.

El Service que exposa les mètriques:

Comprovació:

pg_up 1 confirma que l'exportador pot connectar; numbackends dona les connexions actives. Aquestes mètriques són les que Prometheus recollirà a la lliçó 07-03; aquí només n'hem muntat la font.

api-reserves cobra a través de pagos.proveedorexterno.example, un servei extern amb les complicacions habituals: TLS mutu amb certificat de client, reintents amb retrocés, tallacircuits quan el proveïdor va lent, límit de peticions per segon i un endpoint de proves diferent a cada entorn.

Ficar tota aquesta lògica a api-reserves significa escriure-la en Node.js, mantenir-la, provar-la i tornar-la a fer si demà apareix un segon proveïdor. L'ambaixador la treu del codi: un proxy local que escolta a localhost i s'ocupa de tot.

I la configuració del proxy, resumida a l'essencial:

El que hi ha guanyat Rutas Norte:

I sobretot: api-reserves fa un POST HTTP pla a http://127.0.0.1:8081/cobraments i ja està. A les proves locals de desenvolupament, aquest endpoint pot ser un simulador; l'aplicació no nota la diferència.

La NetworkPolicy de 04-06 que autoritza la sortida a la passarel·la continua aplicant-se al pod, no al contenidor, així que no canvia: el pod sencer necessita permís de sortida al port 443 extern.

Un aclariment necessari: si aquesta idea s'aplica a tot el trànsit de tots els pods, amb un pla de control que distribueix la configuració, ja no se'n diu ambaixador sinó malla de serveis (Istio, Linkerd). Això és territori de la lliçó 08-04; aquí resolem un cas concret sense adoptar una plataforma sencera.

worker-notificacions és un component heretat que escriu en un fitxer, amb un format propi i amb traces multilínia quan hi ha una excepció:

El recol·lector de logs del DaemonSet de 06-02 llegeix la sortida estàndard dels contenidors, no fitxers arbitraris, i encara que els llegís, aquest format no és consultable: no hi ha camps, i una excepció es parteix en tres entrades sense relació.

L'adaptador resol les dues coses: llegeix el fitxer des d'un volum compartit, uneix les línies de continuació i emet JSON estructurat per la seva pròpia sortida estàndard, on el recol·lector sí que el recull.

Resultat a la sortida estàndard de l'adaptador, que és el que el recol·lector del node s'emporta:

L'excepció viatja sencera en un sol registre, amb els seus camps separats i etiquetada amb el component i l'entorn. A 07-05 això permetrà consultes del tipus "tots els ENVIAMENT_ERR de la reserva 4472".

Aquí el sidecar natiu aporta una cosa concreta i important: com que s'acaba després del contenidor principal, captura els últims missatges que worker-notificacions escriu durant el seu tancament ordenat amb SIGTERM (02-01). Amb un contenidor normal a containers, tots dos reben SIGTERM alhora i aquestes últimes línies —sovint les que expliquen per què es va aturar— es perden.

El sizeLimit: 256Mi de l'emptyDir no és opcional: un emptyDir sense límit escriu al disc del node fins a omplir-lo, i llavors el node entra en disk-pressure i desallotja pods aliens.

Amb init containers i sidecars natius, el cicle de vida d'un pod queda així:

Punts a retenir:

1. Els init containers normals s'executen seqüencialment i fins a acabar.
2. Els sidecars natius arrenquen en l'ordre declarat, i n'hi ha prou que estiguin iniciats.
3. Els contenidors principals arrenquen tots alhora, sense garantia d'ordre entre ells.
4. A la terminació, primer els principals; després els sidecars, en ordre invers.
5. El terminationGracePeriodSeconds és del pod, no de cada contenidor: és el pressupost total per a tot el tancament.

Cada sidecar és un contenidor més per cada pod, i aquesta multiplicació és fàcil de subestimar. Números de Rutas Norte en producció:

Mig nucli i 600 MiB només en contenidors auxiliars. En un pic de pont festiu, amb api-reserves autoescalada a 20 rèpliques (09-01), només l'ambaixador ja són 1 CPU i 1,25 GiB.

I hi ha costos menys visibles:

• Cada sidecar és una imatge que cal mantenir, escanejar i actualitzar (08-05). Tres sidecars són tres cadenes de subministrament més.
• Cada sidecar pot fallar i, amb restartPolicy: Always, entrar en bucle de reinici arrossegant el pod sencer.
• Cada sidecar suma temps a l'arrencada, i els natius el sumen de manera seqüencial abans de l'aplicació.
• La depuració es complica: tot kubectl logs i kubectl exec ja necessita la bandera -c.

Preguntes de control abans d'afegir un sidecar:

1. Ho pot fer un DaemonSet, un per node en comptes d'un per pod? Per a logs i mètriques de node, gairebé sempre sí.
2. Ho pot fer la mateixa aplicació amb una llibreria? De vegades cinc línies de codi substitueixen un contenidor de 60 MiB.
3. Justifica el sidecar el seu cost multiplicat pel nombre màxim de rèpliques? Calcula el pitjor cas, no l'habitual.

Oblidar -c <contenidor> a kubectl logs i kubectl exec. Amb diversos contenidors, kubectl exigeix saber quin. L'error a container name must be specified és inequívoc, però quan hi ha init containers el missatge pot despistar perquè el contenidor principal encara no existeix.

Posar un init container en bucle infinit sense visibilitat. Un until ... done sense echo deixa el pod en Init:0/1 sense cap log que expliqui l'espera. Imprimeix sempre alguna cosa a cada iteració.

Init containers pesants. El scheduler reserva el màxim entre els init containers, així que un que demani 2 GiB obliga a trobar un node amb 2 GiB lliures encara que l'aplicació necessiti 256 MiB. Mantén-los petits.

Migracions en initContainer sense lock. Amb N rèpliques, la migració s'executa N vegades, potencialment en paral·lel. Sense idempotència i sense lock d'aplicació, el resultat és una base de dades a mig migrar. Fes servir una eina de migracions que prengui lock, o un Job separat (06-03).

Dos contenidors del mateix pod escoltant al mateix port. Comparteixen l'espai de xarxa, així que el segon falla amb address already in use. Porta un registre de quin port fa servir cada contenidor auxiliar (3000 l'API, 8081 l'ambaixador, 9187 l'exportador...).

Sidecar clàssic en un pod de Job. És el parany històric: el Job no acaba mai. La solució a 1.29+ és un sidecar natiu amb restartPolicy: Always com a init container.

emptyDir sense sizeLimit per a logs. Un log que creix sense control omple el disc del node i provoca disk-pressure, amb desallotjament de pods que no hi tenien res a veure. Posa sempre sizeLimit.

Trencar la classe QoS en afegir un sidecar. Un pod és Guaranteed només si tots els seus contenidors tenen requests == limits. Afegir un sidecar amb valors diferents degrada el pod a Burstable i canvia la seva prioritat de desallotjament (03-05).

Consell: anomena els contenidors per la seva funció, no per la seva tecnologia. ambaixador-pagaments és molt més útil en una alerta a les tres de la matinada que envoy.

Consell: kubectl describe pod és la millor vista. Mostra Init Containers: i Containers: en blocs separats, amb l'estat, el codi de sortida i la raó de cadascun. És més ràpid que encadenar jsonpath.

Consell: kubectl logs --all-containers=true bolca tot el pod de cop, útil per reconstruir la seqüència d'una arrencada problemàtica.

A rutas-norte-dev, crea un Deployment api-demo amb una rèplica de nginx:1.27.2-alpine i un init container que esperi que existeixi i respongui un Service anomenat dependencia-demo. Aplica el Deployment abans de crear la dependència i observa l'estat del pod. Després crea la dependència (un Deployment i un Service amb nginx) i comprova que api-demo arrenca.

A rutas-norte-dev, crea un Deployment worker-demo amb:

• Un contenidor principal worker que cada 5 segons escrigui una línia en format propietari a /logs/sortida.log (per exemple 2026-08-05 10:00:00 | ENVIAMENT_OK | reserva=4471).
• Un sidecar natiu adaptador (init container amb restartPolicy: Always) que segueixi aquest fitxer i emeti cada línia per la seva sortida estàndard amb el prefix [adaptat].
• Un emptyDir amb sizeLimit: 64Mi compartit.

Verifica que el sidecar arrenca abans que el principal i que emet les línies.

Crea a rutas-norte-dev un Job informe-amb-sidecar el pod del qual tingui un contenidor principal que trigui 15 segons i acabi, i un sidecar natiu que escrigui alguna cosa cada 3 segons indefinidament. Comprova que el Job sí que arriba a Complete. Després raona què hauria passat si el sidecar estigués declarat a containers en comptes de com a init container amb restartPolicy: Always.

Solució 1

Init:0/1: l'init container està corrent i cap no s'ha completat.

Ara la dependència:

El pod va passar d'Init:0/1 a PodInitializing i després a Running sense cap reinici. Aquest RESTARTS: 0 és la millora davant de deixar que l'aplicació entri en CrashLoopBackOff mentre espera.

Solució 2

La primera línia confirma l'ordre: el sidecar va imprimir el seu missatge d'arrencada abans que el worker escrivís res, perquè els sidecars natius arrenquen abans que els contenidors de containers. El contenidor principal, en canvi, no imprimeix res per la seva sortida estàndard:

Tot el seu registre va al fitxer, i només arriba al recol·lector del node gràcies a l'adaptador. Aquest és exactament el propòsit del patró.

Solució 3

El Job arriba a Complete en 19 segons tot i que el sidecar continuava imprimint batecs indefinidament.

El pod està Completed amb els seus dos contenidors aturats.

Què hauria passat amb el sidecar a containers: el contenidor generador hauria acabat amb èxit als 15 segons, però metriques-lot hauria continuat viu. Un pod només arriba a la fase Succeeded quan tots els seus contenidors han acabat, així que el pod s'hauria quedat indefinidament en Running amb 1/2 contenidors llestos, i el Job en 0/1 completions per sempre. Només activeDeadlineSeconds ho hauria tallat, i amb estat Failed.

Aquest era exactament el problema històric que els sidecars natius van resoldre.

Un pod amb diversos contenidors és una eina potent i fàcil de fer servir malament. La regla que la governa és que els processos comparteixin pod només quan estiguin tan acoblats que no tingui sentit escalar-los ni desplegar-los per separat, i quan un existeixi per servir l'altre.

Els init containers s'executen en ordre, fins a completar-se, abans que arrenqui cap contenidor principal, i a Rutas Norte ens serveixen per esperar postgres-reserves, aplicar migracions petites i idempotents, i preparar contingut en un emptyDir compartit. Els seus estats —Init:0/2, Init:Error, Init:CrashLoopBackOff— són diagnòstics per si mateixos, i kubectl logs -c <nom> és l'ordre que cal interioritzar.

Els sidecars natius de Kubernetes 1.29+ són init containers amb restartPolicy: Always: arrenquen abans que els contenidors principals, viuen durant tot el pod, es reinicien si moren, es paren després dels principals i —cosa que va tancar un problema d'anys— no impedeixen que un Job acabi.

Els tres patrons clàssics es distingeixen per la direcció del flux: el sidecar afegeix una capacitat (l'exportador de mètriques de postgres-reserves que Prometheus consumirà a 07-03); l'ambaixador intermedia la sortida cap a l'exterior (el proxy que s'ocupa de TLS mutu, reintents i tallacircuits contra pagos.proveedorexterno.example); l'adaptador normalitza el que l'aplicació produeix (el conversor a JSON del log propietari de worker-notificacions). Tots tres es recolzen en localhost i en volums compartits, i tots tres costen recursos multiplicats pel nombre de pods, cosa que cal calcular en el pitjor cas d'escalat.

Fins aquí hem decidit què s'executa i com es compon cada pod. La pregunta que no hem tocat és on: fins ara el kube-scheduler ha col·locat els nostres pods on ha volgut, i això ha bastat. Però postgres-reserves hauria d'estar en un node amb disc SSD, les rèpliques d'api-reserves no haurien de compartir node —si aquell node cau, cau l'API sencera—, i les càrregues d'anàlisi no haurien de competir amb la venda de bitllets. Tot això es controla amb afinitat, taints i toleracions, i és el tema de la lliçó següent: Planificació.