Docker Compose aixeca el sistema de TechCorp en un portàtil, però es queda curt tan bon punt hi ha més d'una màquina: si el servidor que executa servei-comandes cau, ningú no l'arrenca en un altre lloc; si el Black Friday exigeix deu rèpliques de servei-cataleg, algú ha de decidir on posar-les; si cal desplegar la versió 1.0.1 sense tallar el servei, cal coordinar a mà l'arrencada de la nova i l'aturada de la vella. Un orquestrador fa tot això de manera declarativa: li dius què vols ("dues rèpliques d'aquesta imatge, sanes, accessibles amb aquest nom") i ell s'ocupa del com, de manera contínua. Kubernetes és l'orquestrador de la llista curta de 04-01. En aquesta lliçó n'entenem l'arquitectura i els objectes, muntem un clúster local, i escrivim i apliquem els manifestos complets de servei-comandes amb els noms que 03-05 (Service, /health/*) i 04-03 (servei-comandes-config, comandes-db, comandes-rabbitmq) van deixar fixats. El pipeline que aplicarà aquests manifestos automàticament (05-03) i les estratègies per canviar de versió sense talls (05-04) venen després.

1. Per què cal un orquestrador
2. Arquitectura de Kubernetes: pla de control i nodes
3. Els objectes bàsics
4. Entorn local amb kind i kubectl imprescindible
5. Namespace, ConfigMap i Secret de servei-comandes
6. Un Job per a les migracions
7. El Deployment de servei-comandes, línia a línia
8. El Service i el nom DNS servei-comandes:3002
9. Ingress: exposar el gateway a api.techcorp.example
10. Escalat manual i estat del desplegament
11. RabbitMQ i PostgreSQL: dins del clúster o gestionats
12. Helm i Kustomize per no duplicar YAML entre sis serveis

El que un orquestrador resol, comparat amb "contenidors en màquines":

Tot es declara en YAML i es desa a git; el clúster reconcilia contínuament l'estat real amb el desitjat. Aquesta és la idea central: no executes ordres imperatives, descrius el resultat.

• API server: rep totes les peticions (de kubectl, dels controladors, dels kubelets), les valida i les persisteix a etcd, la base de dades clau-valor del clúster.
• Scheduler: observa pods sense node assignat i els en tria un segons els recursos sol·licitats, les afinitats i les restriccions.
• Controller manager: executa els bucles de control. El controlador de Deployment crea ReplicaSet; el de ReplicaSet crea o esborra pods fins a quadrar replicas; el d'Endpoints manté la llista de pods llestos de cada Service (el "registre" de 03-05).
• kubelet (a cada node): agent que parla amb l'API server, arrenca els contenidors dels pods assignats al seu node a través del runtime (containerd, la mateixa tecnologia de contenidors de 05-01) i executa les probes.
• kube-proxy: programa les regles de xarxa perquè la ClusterIP d'un Service reparteixi entre els seus pods.

Un desenvolupador de TechCorp només parla amb l'API server (kubectl), i ni tan sols això en producció: ho farà el pipeline o Argo CD (05-03).

kind (Kubernetes in Docker) crea un clúster complet dins de contenidors; minikube és l'alternativa equivalent. TechCorp fa servir kind perquè és el mateix que corre a CI. El fitxer de configuració publica els ports 80/443 del node al portàtil perquè l'Ingress funcioni:

Les ordres de kubectl que es fan servir cada dia (kubectl config set-context --current --namespace=techcorp evita repetir -n techcorp; en el que segueix l'ometem):

Els manifestos viuen a techcorp/plataforma/k8s/servei-comandes/base/ (l'apartat 12 n'explica l'estructura). Primer el namespace i la configuració no sensible, que és exactament la columna "producció" de la taula de 04-03:

Els secrets no van en YAML dins del repositori. Es creen amb kubectl (o els injecta un gestor extern, 07-04):

Aquest valor és base64, no xifrat: echo cG9z... | base64 -d retorna la contrasenya. Un Secret només és "secret" perquè l'accés s'hi restringeix amb permisos (RBAC) i perquè etcd es pot xifrar en repòs; totes dues coses són de 07-04. Per això els secrets no es versionen en text pla i per això el .dockerignore de 05-01 excloïa .env. Les claus del Secret es diuen com les variables d'entorn (COMANDES_DB_URL) per poder-les injectar amb envFrom.

scripts/migrar.js (04-04) s'ha d'executar abans que arrenqui la nova versió de Comandes, una vegada, i fallar sorollosament si no pot. És un Job:

L'alternativa és un init container dins del pod del servei; funciona, però executa les migracions a cada rèplica en arrencar (amb dues rèpliques, dues vegades, i migrar.js ha de suportar la concurrència). El Job les executa una vegada per versió i es veu a kubectl get jobs. A 05-03 el pipeline el llança i espera abans d'aplicar el Deployment.

Els punts que generen més dubtes:

• selector i labels: el Deployment (a través del seu ReplicaSet) "posseeix" els pods l'etiqueta dels quals app: servei-comandes coincideix; el Service de l'apartat 8 fa servir el mateix selector. Canviar selector en un Deployment existent no està permès: es tria bé des del començament.
• readinessProbe davant de livenessProbe (03-05): readiness mira dependències pròpies (PostgreSQL i RabbitMQ al /health/ready de 04-04) i el seu efecte és deixar de rebre trànsit; liveness només mira que el procés respon i el seu efecte és reiniciar. Posar la comprovació de la base de dades a liveness és l'error clàssic: si PostgreSQL cau, Kubernetes reinicia tots els pods de Comandes en bucle sense arreglar res.
• terminationGracePeriodSeconds: 30 tanca el cercle de l'aturada ordenada: en esborrar un pod, Kubernetes el treu dels Endpoints i envia SIGTERM al PID 1 (el node de 05-01); el servei posa /health/ready a 503, acaba les peticions en curs i surt en menys de 10 s; si no ho fes, als 30 s arribaria SIGKILL. Amb dues rèpliques i aquest contracte, un desplegament no perd cap petició (05-04 ho mostra pas a pas).
• securityContext: runAsNonRoot verifica el que la imatge ja fa (USER node); readOnlyRootFilesystem obliga que qualsevol escriptura vagi a un emptyDir explícit. La resta d'enduriment (capabilities, seccomp, polítiques d'admissió) és de 07-04.

Amb això, el COMANDES_URL=http://servei-comandes:3002 del gateway i el CATALEG_URL=http://servei-cataleg:3001 del ConfigMap de Comandes resolen exactament com a Compose (05-01) i com prometia 03-05, sense que cap servei sàpiga quantes rèpliques hi ha ni a quin node són.

Aplicar i comprovar tot l'anterior:

Si un pod es queda en CrashLoopBackOff, kubectl logs --previous ensenyarà gairebé sempre el missatge de config.js (04-03) dient quina variable falta: la validació fail-fast està pensada per a aquest moment.

El gateway (03-04) es desplega igual que qualsevol servei (Deployment + Service gateway:8080, amb el seu ConfigMap d'URL). L'única cosa que surt del clúster és un Ingress que l'ingress controller (NGINX a kind i en producció; Traefik seria equivalent amb ingressClassName: traefik) converteix en regles de proxy:

L'ingress controller balanceja en capa 7 cap al Service del gateway, i el gateway cap als serveis interns (03-05). L'únic punt d'entrada continua sent el 8080 del gateway; cap servei-* no té Ingress.

kubectl scale és manual: algú decideix el nombre. L'escalat automàtic per CPU o per mètriques (HorizontalPodAutoscaler) és de 06-04, quan tinguem mètriques amb què decidir. Aquí l'important és que escalar és canviar un número i que el Service reparteix només entre les rèpliques llestes.

Decisió de TechCorp: en dev i al clúster kind de CI, PostgreSQL i RabbitMQ dins del clúster amb Helm (dues ordres, dades d'un sol ús); a staging i producció, gestionats, amb l'URL als Secret (comandes-db, comandes-rabbitmq) i el nom rabbitmq resolt per un Service de tipus ExternalName si cal mantenir RABBITMQ_URL estable. L'equip de Plataforma té quatre persones i la seva prioritat és el gateway, el clúster i el pipeline, no fer de DBA.

Helm instal·la un chart (paquet de manifestos parametritzats) que crea l'StatefulSet, el Service (rabbitmq, pg-comandes-postgresql) i els volums; RABBITMQ_URL=amqp://comandes:dev-rabbit@rabbitmq:5672 funciona a kind sense tocar els manifestos dels serveis.

Els quatre fitxers de Comandes es repetirien gairebé idèntics per a Catàleg, Inventari, Pagaments, Notificacions, Clients i el gateway, i a més per entorn (dev, staging, prod). Dues eines eviten copiar i enganxar:

TechCorp fa servir Kustomize per als seus serveis i Helm per a tercers. Estructura a techcorp/plataforma/k8s/:

La base és una per servei, i els overlays només diuen en què es diferencia cada entorn: rèpliques, etiqueta d'imatge, dues claus de configuració. Quan l'equip d'Inventari creï el seu servei, copiarà servei-comandes/ i canviarà noms, port (3006) i ConfigMap: és la part de "plantilla" de la regla del Luis; la part d'"automatitzar" és de 05-03.

• Comprovar la base de dades al livenessProbe. PostgreSQL cau 30 s i Kubernetes reinicia tots els pods de Comandes en bucle. Dependències a readiness; a liveness, només el procés.
• Sense resources. Sense requests l'scheduler apila pods en un node; sense limits el primer que es dispara en memòria tomba els altres. Els valors de partida s'afinen mesurant (06-04).
• Etiquetes del selector que no coincideixen amb template.metadata.labels. L'apply falla amb un missatge clar; al Service, en canvi, un selector mal escrit simplement deixa els Endpoints buits i el servei "no respon". kubectl get endpoints és la primera comprovació.
• Secrets en YAML dins del repositori "perquè són en base64". No és xifratge. kubectl create secret o eines de 07-04 (Sealed Secrets, External Secrets).
• Reaplicar un Job amb el mateix nom i canvis: Kubernetes el rebutja ("field is immutable"). Nom amb versió o kubectl delete job abans.
• Consell: kubectl describe pod i la seva secció Events responen el 90 % dels "no arrenca"; kubectl get events --sort-by=.lastTimestamp dona la vista del namespace.

Exercici 1. Escriu el Deployment i el Service de servei-cataleg (imatge ghcr.io/techcorp/servei-cataleg:1.4.2, port 3001, ConfigMap servei-cataleg-config amb PORT, MONGO_BD, LOG_NIVELL, NODE_ENV; Secret cataleg-mongo amb MONGO_URL) indicant només les línies que difereixen dels de Comandes. Quantes rèpliques posaries a l'overlay de prod i per què?

Exercici 2. Un pod de servei-comandes mostra READY 0/1 durant minuts però STATUS Running i sense reinicis. kubectl logs ensenya "escoltant al 3002" i cap traça d'error. Enumera, en ordre, les tres ordres que executaries per diagnosticar-ho i les dues causes més probables.

Exercici 3. La Marta pregunta per què el Job de migracions porta la versió al nom i què passa si el pipeline desplega la 1.0.1 sense haver canviat cap migració. Respon i proposa com evitar que el Job falli en aquest cas.

Solució 1. Difereixen: metadata.name, labels/selector (app: servei-cataleg), image: ghcr.io/techcorp/servei-cataleg:1.4.2, containerPort: 3001, envFrom amb configMapRef: servei-cataleg-config i secretRef: cataleg-mongo, i al Service port: 3001 (el CATALEG_URL=http://servei-cataleg:3001 de tots). Les probes apunten als mateixos /health/live i /health/ready (contracte de 03-05); terminationGracePeriodSeconds, securityContext i resources poden ser iguals. No hi ha Job de migracions (MongoDB sense esquema; la llavor és només de dev). Rèpliques a prod: més que Comandes (per exemple 4), perquè Catàleg rep els pics ×20 de campanyes (01-05) i és només de lectura, barat de replicar; el nombre definitiu el donarà l'HPA de 06-04.

Solució 2. (1) kubectl describe pod <nom>: a Events apareixerà "Readiness probe failed: HTTP probe failed with statuscode: 503" (o timeout). (2) kubectl port-forward pod/<nom> 3002:3002 i curl localhost:3002/health/ready: el cos diu quina dependència està malament (postgres o rabbitmq). (3) kubectl get secret comandes-db -o jsonpath='{.data.COMANDES_DB_URL}' | base64 -d (i el mateix per a RabbitMQ) per veure on apunta. Causes més probables: l'URL del Secret apunta a un host incorrecte o amb credencials dolentes (el servei arrenca perquè config.js només valida el format, però /health/ready no pot fer SELECT 1), o la dependència no és accessible des del namespace (RabbitMQ encara no instal·lat, Service rabbitmq inexistent). És el comportament desitjat: no llest, sense trànsit, sense reinicis en bucle.

Solució 3. Un Job és immutable i el seu nom únic: si es reapliqués servei-comandes-migracions amb una altra image, l'API server el rebutjaria. Amb la versió al nom, cada desplegament crea un Job nou, en queda registre (kubectl get jobs) i ttlSecondsAfterFinished el neteja. Si la 1.0.1 no porta migracions noves, el Job arrenca, migrar.js consulta migracions_aplicades, veu que 001-004 ja hi són i acaba amb codi 0 sense fer res: és idempotent per disseny (04-04), així que no falla; simplement és un Job de dos segons. L'alternativa d'ometre el Job quan "no hi ha canvis" exigeix que algú ho decideixi, i la regla del Luis prefereix que sigui sempre el mateix pipeline.

Kubernetes executa les imatges de 05-01 de manera declarativa i contínua: un pla de control (API server, etcd, scheduler, controller manager) que reconcilia l'estat desitjat, i nodes amb kubelet, kube-proxy i containerd que el materialitzen. Per a servei-comandes hem escrit i aplicat al namespace techcorp el ConfigMap servei-comandes-config, els Secret comandes-db i comandes-rabbitmq creats amb kubectl create secret (base64, no xifrat), un Job versionat que executa scripts/migrar.js amb la mateixa imatge, un Deployment de dues rèpliques amb envFrom, resources, readinessProbe a /health/ready, livenessProbe a /health/live, terminationGracePeriodSeconds: 30 i runAsNonRoot, i el Service que dona el nom http://servei-comandes:3002; el gateway surt a l'exterior per un Ingress NGINX a api.techcorp.example; RabbitMQ i PostgreSQL van amb Helm en dev/kind i gestionats en producció; i Kustomize (base + overlays dev/prod, amb images: com el punt que canviarà el pipeline) evita duplicar YAML entre els sis serveis. Tot s'ha aplicat a mà amb kubectl apply, i això és precisament el que la lliçó següent elimina: un pipeline de CI/CD per servei que prova, verifica pactes, construeix la imatge i actualitza aquests manifestos sense que ningú escrigui cap ordre.