Tancàvem la lliçó anterior amb el mapa de peces del clúster: apiserver, etcd, scheduler, controladors, kubelet. Aquestes són les peces que executen Kubernetes. Ara toca l'altre vocabulari, el que tu escriuràs cada dia: pods, Deployments, Services, ConfigMaps, PVCs, namespaces. És un vocabulari gran i la temptació és aprendre'l com un diccionari, terme a terme, cosa que és una mala idea: els conceptes de Kubernetes no són independents, formen famílies amb relacions jeràrquiques clares. Aquesta lliçó et dona aquest mapa mental complet, de manera que quan al mòdul 5 aparegui un PersistentVolumeClaim ja sàpigues per endavant on encaixa i amb qui parla. No desenvoluparem l'ús pràctic de cada objecte —cadascun té la seva lliçó pròpia— sinó que els col·locarem al mapa.

1. La base: recurs, objecte i API
2. Clúster i node
3. El pod: la unitat mínima
4. La família de càrregues de treball
5. La família de xarxa
6. La família de configuració
7. La família d'emmagatzematge
8. Organització: namespaces, etiquetes, selectors i anotacions
9. Controladors, operadors i CRDs
10. Taula mestra de conceptes

Abans dels noms concrets, tres termes que es confonen constantment:

I la regla que governa tot el sistema, que ja vam veure a l'arquitectura:

• spec: el que tu vols. L'escrius tu.
• status: el que realment hi ha. L'escriu el clúster.

Tot el que existeix a Kubernetes —una aplicació, una IP virtual, una contrasenya, un disc, un permís— és un objecte amb spec i status emmagatzemat a la mateixa API. Aquesta uniformitat és el que fa que una sola ordre, kubectl get, serveixi per a tot. El detall de l'anatomia d'un objecte el treballarem a Objectes, Manifests YAML i el Model Declaratiu.

• Clúster: el conjunt complet. Un pla de control més un grup de nodes que es presenten com un únic sistema. Quan dius "desplego al clúster", estàs dient "lliuro la meva intenció a l'API i que el sistema decideixi on".
• Node (node): una màquina —física o virtual— que executa càrregues. És també un objecte de l'API: kubectl get nodes t'ho demostra. Té capacitat (CPU, memòria, pods màxims), etiquetes (zona, tipus de disc) i condicions (Ready, MemoryPressure).

Rutas Norte farà servir un clúster de pràctiques d'un sol node (minikube) durant el curs, i parlarem de clústers multinode quan arribem a la planificació (mòdul 6) i a l'alta disponibilitat (mòdul 9).

Aquest és el concepte fundacional, i el que més sorprèn venint de Docker.

Kubernetes no executa contenidors: executa pods. Un pod és un grup d'un o més contenidors que comparteixen xarxa i emmagatzematge i es programen sempre junts al mateix node.

Què comparteixen els contenidors d'un mateix pod:

• Una única IP. Es veuen entre ells per localhost i no poden fer servir el mateix port.
• Els volums declarats al pod.
• El cicle de vida: neixen junts, moren junts, es mouen junts.

En la immensa majoria dels casos —i en gairebé tots els de Rutas Norte— un pod conté un sol contenidor. Els pods multicontenidor es reserven per a patrons concrets (sidecar, init container, adaptador) que s'estudien al mòdul 6.

Dues propietats del pod que cal interioritzar des del primer dia:

1. És efímer. Un pod no es "repara" ni es mou: si el seu node cau, aquell pod es dona per perdut i se'n crea un altre de nou, amb un altre nom i una altra IP. No depenguis mai del nom ni de la IP d'un pod.
2. Rarament es crea a mà. Un pod solt no té qui el ressusciti. Llevat de proves puntuals, sempre es crea a través d'un controlador de càrrega de treball. A la lliçó El Projecte del Curs en crearàs un de solt justament per experimentar aquesta fragilitat en primera persona.

Fragment mínim, només per veure'n la forma:

Tots aquests objectes tenen el mateix propòsit: crear i mantenir pods. Es diferencien en com i quan.

Llegeix-ho així, de baix a dalt:

• El contenidor executa el teu procés.
• El pod embolcalla un o diversos contenidors i és la unitat que es programa en un node.
• El ReplicaSet vigila que hi hagi exactament N pods iguals; si en falta un, el crea.
• El Deployment gestiona ReplicaSets per poder canviar de versió de manera progressiva: crea un ReplicaSet nou amb la imatge nova i va reduint el vell.

Per això tu escrius Deployments, gairebé mai ReplicaSets ni Pods. El ReplicaSet existeix, el veuràs amb kubectl get rs, però és un intermediari que el Deployment gestiona per tu.

La pregunta clau per triar és sempre la mateixa: les meves rèpliques són intercanviables? Si qualsevol pot atendre qualsevol petició i no desen res al disc, és un Deployment. Si cada rèplica té identitat i dades pròpies, és un StatefulSet.

Els pods són efímers i les seves IP canvien. La família de xarxa existeix per donar estabilitat i accessibilitat damunt d'aquest caos.

• Service: una IP virtual i un nom DNS estables que reparteixen trànsit entre un conjunt de pods, triats per etiquetes. És la peça que fa possible que botiga-web cridi api-reserves pel seu nom sense conèixer cap IP. Tipus principals: ClusterIP (intern, l'habitual), NodePort i LoadBalancer (exposició externa), i ExternalName.
• Ingress: regles HTTP/HTTPS que encaminen per domini i ruta cap a Services diferents, amb terminació TLS. És el que permetrà publicar www.rutasnorte.example i api.rutasnorte.example sobre una única IP pública. Un Ingress no fa res per si sol: necessita un Ingress Controller instal·lat al clúster (NGINX, Traefik…).
• NetworkPolicy: tallafoc a nivell de pod. Per defecte, a Kubernetes tots els pods poden parlar amb tots. Una NetworkPolicy ho restringeix: per exemple, que només api-reserves es pugui connectar a postgres-reserves. Atès que aquesta base de dades desa dades personals, per a Rutas Norte no és opcional.
• EndpointSlice: la llista, mantinguda automàticament, de les IP de pods sans que hi ha darrere d'un Service. No s'escriu a mà, però és el primer que es mira quan un Service "no arriba enlloc".

La regla d'or: la imatge conté el codi; mai la configuració ni les credencials. La mateixa imatge api-reserves:2.4.0 ha de poder executar-se a rutas-norte-dev i a rutas-norte-pro sense reconstruir-se.

Un detall que evita molts malentesos: base64 és codificació, no protecció. Qualsevol amb permís de lectura sobre Secrets els pot descodificar en un segon. La protecció real ve de RBAC (mòdul 8) i del xifratge en repòs d'etcd.

Relacionats amb aquesta família hi ha els límits de recursos (requests i limits de CPU i memòria), les ResourceQuota per namespace i els LimitRange, que s'estudien al mòdul 3 i determinen la classe de qualitat de servei (QoS) del pod.

El sistema de fitxers d'un contenidor és efímer: en reiniciar-se, es perd. Per a postgres-reserves això és inacceptable, així que existeix aquesta família.

El flux normal, que veuràs al mòdul 5, és: declares un PVC al teu manifest → la StorageClass aprovisiona dinàmicament un PV real → el PVC queda vinculat a ell → el pod munta aquest PVC com un volum. Tu, com a desenvolupador, gairebé sempre escrius només el PVC.

La separació PV/PVC respon a un repartiment de responsabilitats: l'administrador del clúster gestiona l'oferta (PV i StorageClass), el desenvolupador expressa la demanda (PVC), i cap dels dos no necessita saber els detalls de l'altre.

Amb 40 objectes, el clúster es torna inmanejable sense organització. Kubernetes ofereix dos eixos complementaris.

Un namespace és una partició lògica del clúster. Rutas Norte en farà servir tres: rutas-norte-dev, rutas-norte-pre i rutas-norte-pro.

Què et dona un namespace:

• Unicitat de noms: pot haver-hi un Service api-reserves a cadascun sense conflicte.
• Àmbit de RBAC: "aquest equip pot desplegar a dev però només llegir a pro".
• Àmbit de quotes: límits de CPU i memòria per entorn.
• DNS: un servei es resol com api-reserves.rutas-norte-dev.svc.cluster.local.

Què no et dona: aïllament de xarxa (per a això, NetworkPolicy) ni aïllament de nodes. A més, alguns objectes són d'àmbit de clúster i no viuen en cap namespace: Node, PersistentVolume, StorageClass, ClusterRole, el mateix Namespace.

Una etiqueta (label) és un parell clau-valor enganxat a un objecte. Un selector és una consulta sobre etiquetes. Aquest parell és el mecanisme d'acoblament de tot Kubernetes: un Service no coneix els seus pods pel nom, els troba per etiqueta. El mateix fa un ReplicaSet amb les seves rèpliques.

Convencions que Rutas Norte farà servir a tots els objectes:

I el selector corresponent en un Service:

Les anotacions (annotations) són també parells clau-valor, però amb un propòsit oposat: no es poden seleccionar. Serveixen per adjuntar metadades que consumeixen eines: la configuració d'un Ingress Controller, el commit de Git que va originar el desplegament, un identificador de certificat. Regla mnemotècnica: si hi filtraràs, etiqueta; si és informació per a una eina o per a un humà, anotació.

Aquests tres tanquen el mapa i són la porta a la part avançada del curs.

• Controlador: un procés que executa el bucle de reconciliació de la lliçó anterior sobre un tipus d'objecte. El controlador de ReplicaSet vigila ReplicaSets i crea pods. És el patró universal de Kubernetes.
• CRD (Custom Resource Definition): un objecte que defineix un tipus d'objecte nou. En aplicar un CRD, l'API del teu clúster comença a entendre, per exemple, kind: Certificate o kind: PostgresCluster, amb el seu propi kubectl get certificates.
• Operador: la combinació d'un CRD amb un controlador propi que sap reconciliar-lo. És "coneixement d'un administrador expert convertit en programari": un operador de PostgreSQL pot crear rèpliques, fer còpies de seguretat i executar una commutació per error sense intervenció humana.

Quan al mòdul 6 valoris si postgres-reserves s'ha de gestionar amb un StatefulSet propi o amb un operador, aquesta serà la distinció clau.

Desa aquesta taula: és l'índex conceptual de tot el curs.

• Confondre pod i contenidor. Un pod pot tenir diversos contenidors, però es programa, es mou i s'escala com una unitat. "Escalar" significa crear més pods, no més contenidors dins del pod.
• Crear pods solts en producció. Ningú no els ressuscita. Sempre a través d'un Deployment, StatefulSet, DaemonSet o Job.
• Desar una contrasenya en un ConfigMap. És l'error de seguretat més freqüent en clústers reals. La distinció ConfigMap/Secret existeix precisament per poder aplicar RBAC diferent a cadascun.
• Suposar que un Secret està xifrat. base64 és codificació. Sense xifratge en repòs i RBAC, un Secret és text pla amb un pas extra.
• Creure que un namespace aïlla la xarxa. No ho fa: un pod de rutas-norte-dev pot arribar a un de rutas-norte-pro tret que existeixi una NetworkPolicy.
• Canviar etiquetes a la lleugera. Les etiquetes són el mecanisme d'acoblament: si modifiques l'etiqueta d'un pod, el seu Service deixa de veure'l i el seu ReplicaSet en crea un de nou per substituir-lo. Es fa a propòsit en algunes tècniques de depuració, però mai per accident.
• Consell: quan aparegui un objecte que no coneguis, fes-te tres preguntes — a quina família pertany (càrrega, xarxa, configuració, emmagatzematge)?, quin altre objecte el crea o el consumeix?, és d'àmbit de namespace o de clúster? Amb aquestes tres respostes ja el pots situar. I kubectl explain <recurs> te les respon sense sortir del terminal.

Per a cada necessitat de Rutas Norte, indica quin objecte (o combinació d'objectes) faries servir i per què:

1. Executar 4 còpies intercanviables d'api-reserves i poder passar de la versió 2.4.0 a la 2.5.0 sense tallar el servei.
2. Que postgres-reserves conservi les seves dades encara que el seu pod es recreï, i que sempre es digui igual.
3. Generar un informe d'ocupació cada nit a les 02:30.
4. Que botiga-web arribi a api-reserves per un nom fix encara que les rèpliques canviïn d'IP.
5. Desar la contrasenya de la base de dades fora de la imatge.
6. Impedir que worker-notificacions es pugui connectar directament a la base de dades.

Explica amb les teves paraules, en 6 línies com a màxim, què passa des que escrius replicas: 3 en un Deployment fins que hi ha tres contenidors corrent, anomenant tots els objectes i components que hi intervenen. Després respon: si esborres un d'aquests tres pods a mà, qui el recrea exactament?

Classifica cada metadada com a etiqueta o anotació i justifica-ho en una línia:

1. app: api-reserves
2. entorn: pro
3. rutasnorte.example/commit: 9f3a1c2
4. nginx.ingress.kubernetes.io/proxy-body-size: 8m
5. app.kubernetes.io/part-of: rutas-norte
6. rutasnorte.example/responsable: [email protected]

Solució 1

1. Deployment. És una aplicació sense estat amb rèpliques intercanviables; el Deployment gestiona ReplicaSets i permet l'actualització progressiva i el rollback.
2. StatefulSet + PersistentVolumeClaim (amb la seva StorageClass al darrere). El StatefulSet dona identitat estable (postgres-reserves-0) i un PVC propi per rèplica que sobreviu a la recreació del pod.
3. CronJob, que al seu torn crea un Job i aquest un Pod a cada execució programada.
4. Service de tipus ClusterIP. Dona nom DNS i IP virtual estables i reparteix entre els pods sans seleccionats per etiqueta.
5. Secret, muntat com a variable d'entorn o fitxer, amb RBAC restrictiu. Mai un ConfigMap.
6. NetworkPolicy que permeti trànsit d'entrada a postgres-reserves només des de pods amb l'etiqueta app: api-reserves.

Solució 2

Escrius el Deployment i l'apliques; l'apiserver el desa a etcd. El controlador de Deployment crea un ReplicaSet amb replicas: 3. El controlador de ReplicaSet observa que hi ha 0 pods i crea 3 objectes Pod. El kube-scheduler assigna node a cadascun. El kubelet de cada node demana al runtime, via CRI, que descarregui la imatge i arrenqui el contenidor. Cadena completa: Deployment → ReplicaSet → Pod → contenidor.

Si esborres un pod a mà, el recrea el controlador de ReplicaSet (no el Deployment): detecta que hi ha 2 pods on el seu spec en demana 3 i en crea un de nou, amb nom i IP diferents.

Solució 3

1. Etiqueta. Identifica el component i és la clau per la qual seleccionen Services i ReplicaSets.
2. Etiqueta. Es fa servir per filtrar i per a selectors per entorn.
3. Anotació. És traçabilitat; mai no seleccionaràs objectes per commit i el valor canvia a cada desplegament.
4. Anotació. És configuració que consumeix l'Ingress Controller, no un criteri de selecció.
5. Etiqueta. Etiqueta estàndard recomanada que permet consultar tota la plataforma d'un cop (-l app.kubernetes.io/part-of=rutas-norte).
6. Anotació. Informació de contacte per a humans; no té sentit filtrar-hi i el seu format lliure no encaixa en les restriccions de valor d'una etiqueta.

Ja tens el mapa complet del vocabulari: els objectes de Kubernetes s'agrupen en famílies amb papers clars —càrregues de treball que creen pods, xarxa que els dona estabilitat i accés, configuració que els parametritza, emmagatzematge que els dona persistència— organitzades per namespaces i acoblades entre si mitjançant etiquetes i selectors, amb els controladors reconciliant-ho tot i els CRDs i operadors permetent estendre el sistema. La jerarquia Deployment → ReplicaSet → Pod → contenidor és la columna vertebral que convé tenir sempre present, i la taula mestra et serveix d'índex per a la resta del curs.

Fins aquí, tot ha estat teoria. És el moment de tenir un clúster propi on provar cada cosa que anem aprenent: a la lliçó següent, Configuració d'un Clúster de Kubernetes, muntarem pas a pas l'entorn de pràctiques que farem servir durant els dotze mòduls.