La lliçó anterior va acabar amb un recompte: sis serveis, tres magatzems, Kafka, Redis, MinIO, Kong, Keycloak, Vault, Prometheus, Loki, Tempo, Patroni, etcd. Desenes de contenidors, centenars de paràmetres, i un docker-compose.yml que ja no cap en una pantalla. Mentre tot això es desplegui com el monòlit de 01-06 (els dimarts i els dijous, amb un ssh, un git pull i una llista de passos en un document que algú segueix a mà), la plataforma té dos problemes que cap patró de resiliència no arregla: no és reproduïble (ningú no sap exactament què hi ha a inventari-2 ni per què difereix d'inventari-1) i depèn que una persona no s'equivoqui un dijous a les 18:00. Aquesta lliçó tracta d'eliminar la persona del camí crític: primer descrivint la infraestructura com a codi (Ansible per configurar màquines; imatges immutables per als serveis), i després delegant en un orquestrador, Kubernetes, les decisions que avui pren algú a mà: on corre cada rèplica, quantes en calen, què fer quan una mor, i com portar una versió nova a producció sense que l'Anna ho noti. Les proves que donen confiança per automatitzar són la lliçó 07-06; els serveis gestionats al núvol, 08-03.

1. Per què automatitzar
2. Infraestructura com a codi: configuració davant d'aprovisionament
3. Ansible: inventari, playbooks, rols i idempotència
4. Immutabilitat: imatges, registre i etiquetes per commit
5. Kubernetes: per què un orquestrador i com està fet
6. Objectes essencials
7. Manifestos de Quilòmetre Zero: k8s/
8. Estratègies de desplegament: rolling, blue/green, canary
9. Namespaces, RBAC, service mesh i operadors
10. GitOps i CI/CD
11. docker-compose davant de Kubernetes
12. Errors comuns i consells
13. Exercicis i solucions
14. Conclusió

Tres raons, i les tres ja s'han vist al curs sense anomenar-les:

• Reproduïbilitat. A 07-03 es va dir que la redundància només protegeix contra fallades independents, i que tres rèpliques "iguals" configurades a mà mai no ho són del tot. Si inventari-2 es va crear copiant inventari-1 i editant "el que calia", hi ha diferències que ningú no recorda, i una d'elles serà la causa d'un incident. Automatitzar és que la descripció sigui l'única font: es pot destruir un node i recrear-lo idèntic.
• Escala. Amb 3 rèpliques es pot fer a mà; amb 30, durant la Setmana de la Verema, no. I "a mà" inclou decidir quantes en calen: l'autoescalat és automatització d'una decisió, no només d'una tasca.
• Errors humans. El DELETE de 07-03, el desplegament del dissabte de 07-01 amb el 8 % d'errors, el certificat que va caducar un diumenge: els tres tenen en comú que algú va fer alguna cosa a mà o va deixar de fer-la. L'automatització no elimina l'error (un script equivocat s'equivoca 30 vegades en 30 nodes), però el fa revisable abans (codi en un pull request), provable (07-06) i reversible (rollout undo).

El monòlit de 01-06 es desplegava amb una finestra de manteniment; l'objectiu aquí és que un desplegament de comandes sigui un esdeveniment tan rutinari que passi diverses vegades al dia sense que ningú se n'adoni, inclosa l'Anna.

Infraestructura com a codi (IaC) és tractar servidors, xarxes, configuracions i desplegaments com a fitxers en un repositori: versionats, revisats i aplicats per una eina. Dues famílies que convé no confondre:

Ansible és la que toca aquesta lliçó, perquè és la que configura el que ja existeix (les màquines físiques o virtuals de Quilòmetre Zero) i perquè el seu concepte central, la idempotència de tasques, és el mateix que governa els reintents de 02-05 i 07-04. Terraform es veu a 08-03, quan la infraestructura passi a ser una API de núvol.

Ansible no necessita agent: es connecta per SSH a cada màquina de l'inventari, executa mòduls (petits programes Python que saben instal·lar paquets, escriure fitxers, gestionar serveis) i retorna si ha canviat res. Un playbook és un YAML que diu quines tasques aplicar a quin grup de màquines; un rol és un playbook empaquetat i reutilitzable (tasques, plantilles, variables per defecte, handlers).

El playbook de Kafka delega en un rol i passa les variables del clúster:

I el rol, amb tasques curosament idempotents:

La idempotència és a cada detall: creates: evita repetir descàrregues i, sobretot, evita tornar a formatar un broker amb dades (un kafka-storage.sh format sobre un broker en producció el destrueix); template només notifica el handler si el contingut ha canviat, així que executar el playbook deu vegades seguides reinicia Kafka zero vegades; serial: 1 amb wait_for al final fa que un desplegament de configuració recorri els brokers d'un en un respectant les ISR de 07-03. Executar ansible-playbook -i inventari.ini kafka.yml --check --diff mostra què canviaria sense canviar res: és la revisió prèvia que l'ssh dels dimarts mai no va tenir. La mateixa estructura (rol cassandra amb nodetool drain abans de reiniciar, rol patroni amb patronictl switchover si el node és líder) s'aplica a la resta de màquines amb estat.

Ansible configura màquines que canvien. Per als serveis de km0/ se segueix el camí contrari: la infraestructura immutable. Un servei no s'"actualitza": es construeix una imatge de contenidor nova amb tot a dins (intèrpret, dependències fixades, codi, configuració per defecte), es puja a un registre i es desplega substituint els contenidors vells per nous. Mai no es fa ssh a un contenidor per arreglar res; si alguna cosa està malament, es construeix una altra imatge.

L'etiqueta de la imatge és la clau de la reproduïbilitat: registre.km0.internal/km0/comandes:1.14.2-3f9a1c7 (versió semàntica + hash curt del commit). Mai latest: latest és un punter mòbil, i "quina versió hi ha a producció" ha de tenir una resposta exacta. La mateixa imatge recorre proves, staging i producció; el que canvia entre entorns és la configuració injectada (variables d'entorn, ConfigMap, Secret), no la imatge. Aquest és el principi "build once, deploy many".

Amb imatges immutables, queda decidir on corre cada contenidor, quants n'hi ha, què passa quan un mor o un node cau, com es troben entre si i com se substitueixen per la versió nova. A docker-compose tot això ho decideix una persona, en un sol node. Un orquestrador ho decideix contínuament, en un clúster:

La idea que ho explica tot és el bucle de reconciliació: l'usuari declara a l'API l'estat desitjat ("3 rèpliques de comandes:1.14.2"), etcd el desa (el mateix etcd de 03-03: Kubernetes és, en el fons, un conjunt de controladors sobre un magatzem de consens), i cada controlador compara contínuament l'estat desitjat amb el real i actua per acostar-los: si hi ha 2 Pods i se'n desitgen 3, en crea un; si el node 1 desapareix, els seus Pods es recreen en un altre. No hi ha "ordre de desplegar"; hi ha "canviar l'estat desitjat" i esperar que els controladors convergeixin. És la mateixa filosofia de la idempotència d'Ansible, però executant-se sense parar.

Cada bloc respon a alguna cosa vista abans: les sondes són les de 07-03 amb els seus paràmetres; requests alimenta l'scheduler i l'HPA; limits és un bulkhead de recursos (07-04) per Pod; maxUnavailable: 0 garanteix que un desplegament no redueix la capacitat; topologySpreadConstraints reparteix per zones; preStop + terminationGracePeriodSeconds són l'apagada ordenada (una petició de 400 ms no es talla a mitges). I envFrom: secretRef només dona al Pod el mínim per presentar-se davant de Vault, que és qui lliura credencials dinàmiques i certificats.

Kong (dins del clúster) encamina /api/v1/comandes a http://comandes.km0-prod.svc:8000. Quan un Pod falla la readiness, desapareix dels endpoints del Service en segons; quan es desplega una versió nova, els Pods nous entren només quan estan preparats. Ningú no edita cap IP.

L'HPA pren el màxim del que demanin les mètriques: si la CPU diu 5 rèpliques i el lag en diu 8, escala a 8. La mètrica externa ve del kafka_exporter de 07-01 a través de prometheus-adapter, que la publica a l'API de mètriques de Kubernetes. Les finestres d'estabilització són l'equivalent del for: de les alertes: escalar ràpid, reduir a poc a poc.

Un StatefulSet dona el que una base de dades necessita i un Deployment no: noms estables (inventari-db-0 és sempre el mateix, amb el mateix disc), arrencada i aturada ordenades, i un volum per rèplica. En producció, tanmateix, la pràctica habitual és delegar en un operador (secció 9).

L'Ingress només porta el trànsit fins a Kong; tot el de 06-05 (JWT, rate limiting, OpenAPI, X-Request-Id) continua passant a Kong. Amb cert-manager, el certificat que caducava un diumenge es renova sol i l'alerta CertificatCaducaAviat de 07-01 vigila que sigui així.

Un canary amb Kubernetes pur es fa amb dos Deployments sota el mateix Service; el repartiment és proporcional al nombre de Pods (1 canary de 10 = 10 %):

Per a pesos fins (1 %) independents del nombre de Pods, es fan servir les capacitats del mesh o de l'ingress (Istio VirtualService amb weight: 1/99; Kong amb upstreams ponderats) i eines com Argo Rollouts o Flagger que automatitzen l'anàlisi: consulten a Prometheus la taxa d'error i el p99 de la versió canary (etiqueta version a les mètriques de 07-01) i avancen o reverteixen sols segons l'SLO. El dissabte de 07-01, amb un canary al 10 % analitzat automàticament, el 8 % d'errors hauria afectat menys de l'1 % de les comandes durant dos minuts.

Els Namespaces separen entorns i equips al mateix clúster: km0-prod, km0-staging, observabilitat, mesh. Cadascun amb ResourceQuota (CPU i memòria totals) i LimitRange (valors per defecte per a Pods sense resources), i amb RBAC de Kubernetes (diferent del RBAC de l'aplicació de 06-01, mateix model): qui pot fer què sobre quins objectes.

Els Pods també tenen identitat (ServiceAccount), i amb ella s'autentiquen a Vault (06-04) i davant de l'API si ho necessiten; el principi és el mateix de mínim privilegi.

Service mesh. A 07-04 es va veure Envoy com a sidecar amb timeouts, reintents i outlier detection; a 06-04, mTLS entre serveis amb certificats de Vault gestionats per cada servei. Un service mesh (Istio, Linkerd) instal·la aquest sidecar automàticament a cada Pod del namespace i el configura des d'objectes de Kubernetes: mTLS obligatori i amb rotació automàtica de certificats (PeerAuthentication: STRICT), polítiques d'autorització servei a servei, timeouts i reintents per ruta (VirtualService, DestinationRule amb outlierDetection), i telemetria RED uniforme per a Prometheus sense instrumentar res. És la manera d'obtenir 06-04 i 07-04 sense codi per a serveis que no són Python (o per no dependre que cada equip ho faci bé), a canvi d'1-2 ms de latència, memòria per sidecar i una altra peça per operar. La decisió arquitectònica de quan val la pena es reprèn a 08-01.

Operadors. Un operador és un controlador que coneix un sistema concret: sap fer un failover de PostgreSQL, un nodetool drain abans de reiniciar un node de Cassandra, o reassignar particions de Kafka en afegir un broker. S'instal·la al clúster i s'hi parla amb objectes propis (kind: Kafka, kind: PostgresCluster). Per a Quilòmetre Zero: Strimzi per a Kafka, K8ssandra per a Cassandra, CloudNativePG o l'operador de Zalando (Patroni) per a PostgreSQL. Amb ells, el StatefulSet de la secció 7 se substitueix per una declaració de deu línies i l'operador s'ocupa del que 07-03 va fer a mà (i dels backups a MinIO). Aquí n'hi ha prou de saber que existeixen i que són la manera recomanada de fer córrer sistemes amb estat a Kubernetes.

Amb manifestos a k8s/, l'última peça és qui els aplica i quan. GitOps és la resposta: el repositori Git és l'única font de veritat de l'estat desitjat; ningú no executa kubectl apply a mà a producció; un agent al clúster (Argo CD o Flux) observa el repositori i reconcilia contínuament el clúster amb el que hi ha a la branca main. Desplegar és fer merge d'un pull request que canvia l'etiqueta d'imatge; revertir és revertir el commit; auditar qui ha desplegat què és git log. I un canvi manual al clúster ("drift") es detecta i es desfà.

Dos repositoris: el del codi (que produeix imatges) i el del desplegament (k8s/, que Argo CD observa). Així, "quina versió hi ha a producció" és una línia en un YAML amb historial de Git, i el pipeline pot promoure a staging automàticament i a prod amb una aprovació. La signatura d'imatges (cosign) i una política d'admissió que només permet imatges signades tanquen el cercle amb 06-05: res no corre a producció que no hagi passat pel pipeline.

La regla pràctica: compose per desenvolupar (el docker-compose.yml de km0/ continua sent la manera d'aixecar la plataforma al portàtil), Kubernetes per a producció a partir del moment en què es necessita més d'un node o desplegar sense tall. Saltar a Kubernetes amb un equip de dues persones i un servei és pagar la complexitat sense cobrar-ne el benefici; quedar-se a compose amb sis serveis, tres zones i desplegaments diaris és el dels dimarts i dijous amb un altre nom.

• Tasques d'Ansible que no són idempotents. Un command: sense creates: que formata un broker a cada execució. Fes servir mòduls declaratius; per a command/shell, sempre creates:/removes: o changed_when:; prova amb --check --diff.
• Reiniciar tots els nodes amb estat alhora. serial: 1 i una espera de salut entre nodes; per a Kafka i Cassandra, és la diferència entre manteniment i incident.
• image: comandes:latest. Ningú no sap què corre a producció i un rollout undo pot "tornar" a la mateixa imatge. Versió + hash de commit, sempre.
• Deployments sense resources. Sense requests l'scheduler col·loca a cegues i l'HPA per CPU no funciona; sense limits un Pod amb una fuita de memòria s'emporta el node. Tots dos, mesurats amb les mètriques de 07-01.
• Liveness que comprova dependències. Ja a 07-03: reinicis en cascada. Liveness mínima, readiness amb dependències, startup generosa.
• maxUnavailable alt "per desplegar ràpid". Redueix la capacitat durant el desplegament, just quan la versió nova pot ser més lenta. maxUnavailable: 0, maxSurge: 1.
• kubectl apply a mà a producció. Es perd l'historial i apareix drift. GitOps: tot passa per un PR; Argo CD/Flux apliquen.
• Reduir rèpliques tan ràpid com es pugen. L'HPA oscil·la i cada baixada talla capacitat en un pic que torna. Finestra d'estabilització llarga a scaleDown.
• Secrets en ConfigMaps o al repositori. Un Secret de Kubernetes és només base64; el que és sensible de debò ho lliura Vault en temps d'execució (06-04); a Git, mai.
• Kubernetes perquè sí. Un clúster per a un servei amb dues persones és una càrrega sense benefici. Compose fins que les raons (nodes, escalat, desplegaments sense tall) siguin reals.

Exercici 1. En Jordi executa ansible-playbook -i inventari.ini kafka.yml per segona vegada sense haver canviat res, i veu changed=2 a kafka-2: les tasques "Certificat i clau del broker des de Vault" i "Escriure el keystore del broker" apareixen com a canviades, i Kafka s'ha reiniciat a kafka-2. (a) Què està passant i per què no va passar a kafka-1 ni a kafka-3? Pista: mira changed_when i el que fa copy quan el contingut difereix. (b) És un problema d'idempotència del rol o del disseny de certificats de 06-04? Proposa un canvi al rol que eviti reiniciar el broker a cada execució sense deixar de renovar el certificat quan toqui. (c) Què hauria passat sense serial: 1 i amb els tres brokers en la mateixa situació?

Exercici 2. Durant la Setmana de la Verema, comandes puja a 12 rèpliques (el màxim de l'HPA) i continua amb p99 de 700 ms. La Marta mira: la CPU dels Pods és al 35 %, el lag de comandes-saga és baix, km0_bulkhead_en_us{dependencia="inventari"} és a 24 a tots els Pods i km0_circuit_estat a 0. (a) Per què l'HPA no ajuda i què indica el bulkhead ple amb CPU baixa? (b) Què caldria escalar, i quin objecte de Kubernetes governa aquest component? Hi serveix un HPA? (c) Dissenya una mètrica d'HPA per a comandes que reflecteixi millor la saturació real que la CPU, fent servir alguna cosa de 07-01.

Exercici 3. Es desplegarà comandes 1.15.0, que canvia el format de l'esdeveniment comanda.confirmada a comandes.esdeveniments afegint-hi un camp obligatori que analitica 2.3 encara no entén. (a) Per què un rolling update de comandes és perillós aquí encara que les sondes estiguin bé, i quina estratègia de la secció 8 ho mitiga només en part? (b) Descriu un pla de desplegament en passos (amb les ordres o els PR de GitOps que corresponguin) que no trenqui analitica en cap moment, recolzant-te en la compatibilitat d'esquemes de 02-05. (c) Quina comprovació automàtica del pipeline de CI hauria bloquejat el PR abans d'arribar a aquesta situació? (Es desenvolupa a 07-06; n'hi ha prou d'anomenar-la i dir a quin job aniria.)

Exercici 1.

(a) La tasca de Vault genera un certificat nou a cada execució (amb changed_when: false no es marca com a canvi, però el contingut registrat a cert és diferent cada vegada); la tasca copy compara el contingut nou amb el fitxer existent, veu que difereix (un altre certificat, una altra clau) i l'escriu: changed=true i notify: reiniciar kafka. A kafka-1 i kafka-3 no va passar perquè... sí que va passar, o hauria passat: si no es va veure és perquè el playbook amb serial: 1 es va interrompre o perquè en aquests nodes l'execució anterior va fallar abans d'escriure el keystore; en un rol així, tots els brokers es reiniciarien a cada execució. (b) És un defecte d'idempotència del rol, no del disseny de certificats: els certificats de curta durada de 06-04 són correctes, però el rol n'ha de generar un només quan l'actual és a punt de caducar: afegir una tasca prèvia que llegeixi la data de caducitat del certificat existent (community.crypto.x509_certificate_info) i executar la generació i la còpia amb when: cert_actual.expired or (cert_actual.not_after | to_datetime - now()) < 7 days; o, millor, treure la renovació del playbook i delegar-la a l'agent de Vault a cada node (Vault Agent amb plantilles, que renova i recarrega sense reiniciar el broker mitjançant kafka-configs dinàmic). (c) Els tres brokers reiniciant-se alhora deixen sense ISR totes les particions: amb min.insync.replicas=2 i acks=all, comandes.esdeveniments rebutja escriptures (NotEnoughReplicas) durant el reinici, l'outbox de comandes s'acumula i KafkaLagRepartiment i les alertes de 07-01 salten; sense unclean.leader.election.enable=false fins i tot hi podria haver pèrdua de missatges. serial: 1 amb wait_for converteix això en tres reinicis successius sense pèrdua de disponibilitat.

Exercici 2.

(a) L'HPA escala comandes per CPU, i comandes no està limitat per CPU: està esperant. km0_bulkhead_en_us a 24 (el màxim) amb CPU al 35 % i circuit tancat vol dir que totes les crides a inventari tenen èxit però triguen: els 24 permisos estan ocupats per peticions que esperen inventari, i les següents es rebutgen (BulkheadPle, fallback a "pendent de confirmar") o esperen un fil. Afegir rèpliques de comandes multiplica els bulkheads (12 × 24 = 288 crides concurrents) i empitjora la càrrega sobre inventari. (b) Cal escalar inventari (o la seva base de dades): inventari és un Deployment (sense estat, la base és a part) i sí que admet HPA, amb una mètrica de saturació pròpia (peticions en vol o p99 de ReservarEstoc); si el coll d'ampolla és km0_inventari (contenció de bloqueigs sobre vi-crianca, com a la traça de 07-02), afegir rèpliques d'inventari no ajuda: el StatefulSet/operador de PostgreSQL no s'escala horitzontalment per a escriptures, i la solució és de disseny (04-01: particionar l'estoc per mercat, o reserves per lots). (c) Una mètrica de Prometheus via prometheus-adapter: km0_peticions_en_vol{servei="comandes"} de mitjana per Pod amb objectiu, p. ex., 20 (amb 32 fils, 20 en vol de mitjana indica cua incipient); o directament la latència: histogram_quantile(0.99, ...) de POST /comandes amb objectiu 0,4 s. La primera és millor per a l'HPA perquè respon de manera gairebé lineal al nombre de rèpliques; la segona serveix més com a alerta. En tots dos casos, amb scaleDown lent.

Exercici 3.

(a) El rolling update substitueix Pods de comandes sense tall, però tan bon punt el primer Pod nou publica una comanda.confirmada amb el format nou, analitica 2.3 falla en deserialitzar-la: les sondes de comandes són perfectes; el dany és en un altre servei, a través de Kafka, i es manifesta com a missatges a la DLQ d'analitica (02-05) i lag. Un canary redueix la fracció d'esdeveniments amb format nou, però un sol missatge ja trenca el consumidor (o l'envia a la DLQ): mitiga el volum, no el problema. (b) Compatibilitat cap endavant i cap enrere: 1) PR a analitica (2.4) que tolera el camp nou (l'ignora si no l'entén, el fa servir si hi és) i desplegar-lo primer (kubectl rollout status deployment/analitica), amb l'esquema registrat com a compatible; 2) desplegar comandes 1.15.0 amb canary al 10 % (PR al repo de desplegament amb comandes-canary, o Argo Rollouts), observar la DLQ i el lag d'analitica i la taxa d'error de comandes; 3) promoure al 100 %; 4) només quan cap productor no emet el format vell (i els missatges vells han sortit de la retenció del tòpic, 7 dies), un PR a analitica que fa obligatori el camp. A més, fer el camp opcional a l'esquema en lloc d'obligatori evita el pas 4. En cap moment no hi ha un consumidor que no entengui el que hi ha al tòpic. (c) Una prova de contracte entre el productor comandes i el consumidor analitica sobre l'esquema de comanda.confirmada (verificació de compatibilitat de l'esquema contra els registrats, i del contracte consumidor-productor): aniria al job test del pipeline de comandes (python tests/contracte/verificar.py comandes), i hauria fallat en detectar un camp obligatori nou que un consumidor registrat no accepta. Es desenvolupa a 07-06.

Automatitzar és treure la persona del camí crític i deixar-hi al seu lloc una descripció que es pot revisar, provar i aplicar tantes vegades com calgui. Per a les màquines amb estat, Ansible: un inventari, playbooks i rols amb tasques idempotents (creates:, template amb handlers, --check --diff), i que recorren els brokers de Kafka d'un en un respectant les ISR. Per als serveis, imatges immutables etiquetades per versió i commit, construïdes un cop i desplegades a tots els entorns amb configuració injectada. I a sobre, Kubernetes: un magatzem de consens amb controladors que reconcilien sense parar l'estat desitjat amb el real; Deployments amb sondes, resources, repartiment per zones i apagada ordenada; Services que balancegen només cap a Pods preparats; HPA per CPU i per lag de Kafka; StatefulSets o operadors per a Cassandra, Kafka i PostgreSQL; Ingress cap a Kong; rolling, blue/green i canary amb anàlisi automàtica contra els SLO; namespaces i RBAC; el service mesh que dona mTLS i polítiques de resiliència sense codi; i GitOps amb un pipeline en què desplegar és fer merge i revertir és revertir un commit. Compose queda per al portàtil.

Però tot aquest engranatge descansa sobre una suposició que encara no s'ha examinat: que la versió 1.15.0 que el pipeline construeix, signa i desplega funciona. El pipeline executa pytest i verifica contractes, i el canary observa els SLO, però quina prova demostra que la saga compensa bé quan inventari cau a mig camí? Com se sap que el circuit breaker de 07-04 s'obre a temps, o que Patroni commuta en menys de 30 segons, abans que passi a producció un dissabte? Provar un sistema distribuït és més difícil que provar un programa: el no-determinisme, les fallades parcials i el temps fan que les proves unitàries no siguin suficients. L'última lliçó del mòdul tracta les proves en sistemes distribuïts (integració amb dependències reals, contractes, càrrega simulant la Setmana de la Verema) i l'enginyeria del caos: provocar les fallades de 07-03 i 07-04 a propòsit, amb hipòtesi i radi d'explosió controlat, per comprovar que la plataforma respon com es va dissenyar.