A la lliçó anterior vam tancar amb una promesa: saps què fa Kubernetes —mantenir de manera contínua l'estat que li declares— i ara toca veure com ho fa. Un clúster no és cap capsa màgica: són sis o set processos amb responsabilitats molt delimitades que es comuniquen sempre a través d'un únic punt central. Entendre aquesta arquitectura és el que després et permetrà diagnosticar problemes en lloc de reiniciar coses a l'atzar: quan un pod es queda en Pending, quan un desplegament no avança o quan el clúster deixa de respondre, la causa és gairebé sempre en una peça concreta i aquesta lliçó t'ensenya quina. Acabarem seguint, pas a pas, tot el que passa des que executes kubectl apply -f api-reserves.yaml fins que el contenidor d'api-reserves està servint peticions en un node.

1. Visió general: pla de control i nodes de treball
2. Els components del pla de control
3. Els components dels nodes de treball
4. El bucle de reconciliació: la idea central
5. Recorregut complet de kubectl apply
6. Què passa quan falla cada peça
7. Alta disponibilitat del pla de control

Un clúster de Kubernetes es divideix en dues meitats amb papers molt diferents:

• El pla de control (control plane): és el cervell. Decideix, registra i vigila. No executa les aplicacions dels usuaris (llevat de clústers d'un sol node com minikube).
• Els nodes de treball (worker nodes): són els músculs. Executen els contenidors de les teves aplicacions i reporten el seu estat.

Fixa't en la propietat més important del diagrama: totes les fletxes passen per kube-apiserver. Cap component no parla directament amb un altre. El scheduler no crida el kubelet; el kubelet no consulta etcd. Tots llegeixen i escriuen a l'API, i aquesta API és l'única que toca etcd. Aquesta topologia en estrella és el que fa el sistema extensible: per afegir una funcionalitat nova n'hi ha prou d'escriure un procés que observi l'API i actuï (això és un controlador, i és exactament el que fan els operadors del mòdul 6).

És el frontal REST de tot el clúster i l'únic component que escriu a etcd. Tot el que passa a Kubernetes és una petició HTTP contra aquest servidor.

Les seves responsabilitats, en l'ordre en què s'apliquen a cada petició:

1. Autenticació: qui ets? (certificat de client, token, OIDC…).
2. Autorització: pots fer això? És on actua RBAC (mòdul 8).
3. Control d'admissió: modificar o rebutjar l'objecte abans de desar-lo (per exemple, injectar valors per defecte, aplicar quotes o rebutjar imatges no signades).
4. Validació de l'esquema de l'objecte.
5. Persistència a etcd.
6. Notificació a tots els components subscrits mitjançant el mecanisme de watch.

És sense estat i horitzontalment escalable: pots tenir tres rèpliques darrere d'un balancejador.

És una base de dades clau-valor distribuïda i consistent, basada en l'algorisme de consens Raft. Desa absolutament tot l'estat del clúster: objectes, configuració, secrets i estat observat.

Punts que has de retenir:

• És l'única font de veritat. Si perds etcd sense còpia de seguretat, has perdut el clúster (no les aplicacions ja corrent, però sí tota la seva definició).
• Es desplega en nombre senar de membres (3 o 5) per poder formar quòrum.
• És sensible a la latència de disc: es recomana SSD dedicat. És el coll d'ampolla habitual en clústers grans.
• La seva còpia de seguretat (etcdctl snapshot save) és la còpia de seguretat del clúster, i és matèria d'examen a la CKA (mòdul 12).

La seva feina és una sola cosa, i la fa molt bé: decidir en quin node s'executa cada pod acabat de crear. Observa contínuament l'API buscant pods sense nodeName assignat i, per a cadascun, executa dues fases:

El resultat no és "arrencar el contenidor": és simplement escriure el camp spec.nodeName del pod a l'API. El scheduler no contacta mai amb el node. Els criteris avançats (afinitat, taints, tolerations) s'estudien al mòdul 6.

És un únic binari que executa desenes de controladors en paral·lel, cadascun amb el seu propi bucle de reconciliació. Els més rellevants per al curs:

Quan al mòdul 2 escriguis un Deployment amb replicas: 3 i vegis aparèixer tres pods, qui els ha creat ha estat aquest procés.

Aïlla tot el que depèn del proveïdor de núvol, de manera que el nucli de Kubernetes no tingui codi d'AWS, Azure o GCP. S'encarrega de:

• Nodes: consultar al proveïdor si una màquina virtual ha estat eliminada realment.
• Balancejadors: quan crees un Service de tipus LoadBalancer, és qui demana el balancejador real al núvol (mòdul 4).
• Rutes: configurar l'encaminament entre nodes a la xarxa del proveïdor.

A minikube o kind no existeix, i per això un Service de tipus LoadBalancer es queda amb la IP externa en <pending> tret que facis servir minikube tunnel. És una font clàssica de confusió que veurem al seu moment.

És l'agent que corre a cada node i l'únic que realment arrenca contenidors. El seu bucle és:

1. Preguntar a l'API quins pods li han estat assignats (spec.nodeName == aquest node).
2. Comparar amb el que hi ha corrent a la màquina.
3. Demanar al runtime de contenidors, via CRI, que arrenqui o aturi el que calgui.
4. Muntar volums, injectar ConfigMaps i Secrets, aplicar límits de recursos.
5. Executar les sondes de salut (mòdul 7) i reiniciar contenidors fallits.
6. Reportar contínuament l'estat del node i dels seus pods a l'API.

Important: el kubelet només obeeix l'API, no accepta ordres de ningú més. I només gestiona pods, no contenidors solts: si arrenques un contenidor amb docker run en un node, el kubelet l'ignora.

Implementa el concepte de Service a nivell de xarxa a cada node. Observa els Services i els seus EndpointSlices i programa regles de xarxa (iptables o, en clústers grans, IPVS) perquè el trànsit dirigit a la IP virtual d'un servei es reparteixi entre els pods sans.

No és un proxy al camí de les dades en el mode habitual: escriu regles del kernel i s'aparta. Alguns plugins de xarxa moderns (Cilium en mode eBPF) el substitueixen del tot. S'estudia al mòdul 4.

El kubelet no sap crear contenidors: delega en un runtime a través de la CRI (Container Runtime Interface), una API gRPC estàndard. Els runtimes habituals:

Sota el runtime hi ha un altre nivell (runc) que és qui realment parla amb el kernel (namespaces i cgroups). Aquest detall no el necessites per operar, però explica la frase "Kubernetes ja no fa servir Docker": les imatges que construeixes amb Docker continuen funcionant perfectament perquè compleixen l'estàndard OCI.

Dues interfícies més que convé anomenar ja:

• CNI (Container Network Interface): el plugin que assigna IP als pods i fa que es vegin entre nodes. Calico, Cilium, Flannel. Sense CNI instal·lat, els nodes es queden en NotReady. Mòdul 4.
• CSI (Container Storage Interface): el plugin que aprovisiona discos reals per als volums persistents. Mòdul 5.

Si et quedes amb una sola idea d'aquesta lliçó, que sigui aquesta. Tots els controladors de Kubernetes executen el mateix patró:

Conseqüències pràctiques d'aquest disseny, que expliquen molts comportaments que et trobaràs:

• L'spec l'escrius tu; el status l'escriu el sistema. No editis mai un status a mà.
• És per nivell, no per esdeveniment. El controlador no reacciona a "s'ha esborrat un pod": compara la foto actual amb la desitjada. Per això el sistema es recupera encara que es perdi un missatge o un controlador es reiniciï.
• És idempotent. Aplicar el mateix manifest deu vegades produeix el mateix resultat que aplicar-lo una.
• La correcció manual no dura. Si esborres un pod gestionat per un ReplicaSet, torna en segons. Perquè desaparegui cal canviar l'estat desitjat.
• Les fallades són "eventualment consistents". Entre que declares una cosa i es compleix passa un temps; per això els objectes tenen condicions i esdeveniments, i per això kubectl get de vegades mostra estats intermedis.

Seguirem una petició real de Rutas Norte. Suposa aquest fitxer mínim al directori k8s/ del repositori (els detalls del format es veuen a la lliçó Objectes, Manifests YAML i el Model Declaratiu):

I l'apliques:

Darrere d'aquesta línia de sortida han passat dotze passos.

Pas a pas, amb detall:

1. kubectl llegeix el teu kubeconfig per saber a quin clúster ha de parlar, amb quines credencials i en quin namespace.
2. Converteix el YAML a JSON i l'envia com a POST (o PATCH si l'objecte ja existia) sobre HTTPS a l'endpoint del recurs.
3. Autenticació. L'apiserver valida el teu certificat de client o token. Si falla: error: You must be logged in to the server (Unauthorized).
4. Autorització. RBAC comprova si el teu usuari pot fer create pods al namespace rutas-norte-dev. Si falla: Error from server (Forbidden).
5. Control d'admissió. S'executen els admission controllers en dues tandes: primer els mutants (afegeixen valors per defecte, la ServiceAccount, límits d'un LimitRange…) i després els validadors (ResourceQuota, Pod Security Standards, webhooks propis). Qualsevol pot rebutjar la petició.
6. Escriptura a etcd. L'objecte es desa. En aquest moment el pod ja existeix com a objecte, encara que no hi hagi cap contenidor en marxa. El seu estat és Pending i el seu spec.nodeName és buit.
7. etcd confirma l'escriptura per consens Raft.
8. L'apiserver respon a kubectl amb 201 Created. Aquí acaba la teva ordre: kubectl apply no espera que el contenidor arrenqui.
9. El scheduler rep la notificació pel seu watch sobre pods sense node assignat.
10. El scheduler decideix. Filtra els nodes sense recursos suficients o incompatibles, puntua els restants, tria node-2 i escriu el binding a l'API. El pod continua en Pending, però ja té destinació.
11. El kubelet de node-2 se n'assabenta pel seu propi watch i pren el control.
12. El kubelet executa: demana al runtime, via CRI, que descarregui registry.rutasnorte.example/api-reserves:2.4.0 (estat ContainerCreating, o ImagePullBackOff si el registre rebutja la descàrrega), crea el sandbox de xarxa demanant una IP al plugin CNI, munta volums i secrets, i arrenca el contenidor. Després informa l'API: status.phase = Running.

A partir d'aquí, el kubelet vigila el contenidor de manera permanent i el bucle de reconciliació continua viu fins que l'objecte s'esborri.

Aquesta taula és or pur per diagnosticar incidències, i una pregunta recurrent en entrevistes i certificacions.

La conclusió operativa és tranquil·litzadora: el pla de control és el cervell, no el cor. Si cau, el clúster deixa de canviar, però no deixa de servir. Això és un disseny deliberat i explica per què una caiguda del pla de control és greu però rarament és una caiguda del servei.

Un clúster de pràctiques té un sol node de control. Un clúster de producció, com el que Rutas Norte voldrà per al seu namespace rutas-norte-pro, necessita tolerar la pèrdua d'una màquina del pla de control.

L'esquema estàndard:

• 3 nodes de pla de control (nombre senar, pel quòrum d'etcd).
• kube-apiserver replicat als tres, darrere d'un balancejador o d'un keepalived amb IP virtual. En ser sense estat, escala en actiu-actiu.
• etcd en 3 membres. Tolera la pèrdua d'1. Amb 5 membres en tolera 2. Amb 2 membres no en tolera cap: no facis servir mai un nombre parell.
• scheduler i controller-manager en actiu-passiu. S'executen tots tres, però només un actua: trien líder mitjançant un objecte Lease a l'API. És imprescindible que només un reconciliï, o crearien pods per duplicat.
• etcd apilat o extern: apilat (stacked, etcd a les mateixes màquines de control) és l'habitual i més senzill; extern aïlla la fallada i es fa servir en clústers grans.

A més, en un clúster gestionat (EKS, AKS, GKE, mòdul 10-06) el proveïdor opera tot això per tu i ni tan sols veus les màquines del pla de control: pagues una quota i només administres els nodes de treball. Per a la majoria d'empreses, inclosa Rutas Norte, aquesta és l'opció sensata.

• Creure que el scheduler arrenca contenidors. No: només escriu un nom de node. Qui arrenca és el kubelet. Si un pod està en Pending, el problema és del scheduler (no cap en cap node); si està en ContainerCreating o ImagePullBackOff, el problema és del kubelet o del runtime.
• Pensar que kubectl apply espera que l'aplicació estigui llesta. Retorna tan bon punt l'objecte es desa a etcd. Per esperar de debò, es fa servir kubectl rollout status o kubectl wait.
• Modificar recursos a mà en un node. Aturar un contenidor amb crictl o docker no serveix de res: el kubelet el recrea. Sempre s'actua sobre l'API.
• Oblidar la còpia de seguretat d'etcd. És l'únic component la dada del qual és irreemplaçable. Sense snapshot, un desastre a etcd equival a reconstruir el clúster des dels manifests (raó addicional per tenir-los tots a Git).
• Posar 2 membres d'etcd "per tenir redundància". Empitjora la disponibilitat: amb 2 membres el quòrum és 2, així que perdre'n un bloqueja el clúster. Sempre senar.
• Consell de diagnòstic: davant de qualsevol problema, recorre la cadena en ordre — l'objecte existeix a l'API? (kubectl get) → té node assignat? (kubectl get pod -o wide) → què diu el kubelet? (kubectl describe pod, secció Events). Aquest ordre replica exactament el recorregut de la secció 5.

Per a cada símptoma observat al clúster de Rutas Norte, indica quin component és el principal sospitós i per què:

1. El pod api-reserves porta 10 minuts en Pending i describe diu 0/3 nodes are available: insufficient memory.
2. kubectl get pods retorna Unable to connect to the server: dial tcp ... connection refused.
3. S'esborra a mà un pod de botiga-web gestionat per un ReplicaSet i no es recrea, però la resta del clúster respon bé.
4. El pod worker-notificacions està ContainerCreating des de fa 5 minuts amb l'esdeveniment failed to pull image ... unauthorized.
5. Un node apareix com a NotReady i al cap de pocs minuts els seus pods apareixen en altres nodes.

Ordena aquests vuit passos, que estan desordenats, i assenyala en quin d'ells el pod passa de Pending a ContainerCreating:

• a) El kubelet demana al runtime que creï el contenidor via CRI.
• b) L'apiserver escriu l'objecte a etcd.
• c) RBAC comprova els permisos de l'usuari.
• d) El scheduler escriu spec.nodeName.
• e) kubectl envia la petició HTTPS.
• f) S'executen els admission controllers.
• g) L'apiserver respon 201 Created.
• h) El kubelet rep l'esdeveniment del watch.

Rutas Norte vol un clúster propi per a rutas-norte-pro que toleri la caiguda d'una màquina completa del pla de control. Indica: quants nodes de control faries servir, quants membres d'etcd, com s'accedeix a l'apiserver, en quin mode treballen scheduler i controller-manager, i explica en dues línies què passaria amb la botiga web durant els 3 minuts en què el pla de control estigués completament caigut.

Solució 1

1. kube-scheduler (juntament amb la capacitat dels nodes). El pod es va crear correctament a l'API, però cap node no passa la fase de filtratge per manca de memòria. La solució és reduir els requests del pod o afegir capacitat.
2. kube-apiserver (o la xarxa cap a ell). connection refused significa que kubectl ni tan sols arriba a autenticar-se: el procés no escolta o l'endpoint del kubeconfig és incorrecte.
3. kube-controller-manager. El controlador de ReplicaSet és qui recrea les rèpliques; si la resta funciona però no es reconcilia res, el sospitós és el controller-manager (o la seva elecció de líder).
4. kubelet i runtime de contenidors, amb causa arrel a les credencials del registre. El pod ja té node assignat; la fallada és en descarregar la imatge (falta l'imagePullSecret).
5. kubelet d'aquell node (o la xarxa del node). En deixar de reportar, el controlador de nodes el marca NotReady i, passat el període de tolerància, desallotja els seus pods perquè es recreïn en un altre lloc. Comportament esperat, no un error.

Solució 2

Ordre correcte: e → c → f → b → g → d → h → a.

• e) petició HTTPS
• c) autenticació i autorització RBAC
• f) admissió (mutació i validació)
• b) escriptura a etcd → el pod existeix en Pending
• g) resposta 201 Created a kubectl
• d) el scheduler assigna node → continua Pending, però ja amb destinació
• h) el kubelet rep l'esdeveniment
• a) el kubelet crea el contenidor → aquí el pod passa a ContainerCreating i després a Running

Solució 3

• 3 nodes de pla de control i 3 membres d'etcd (topologia apilada): amb quòrum de 2, es tolera la pèrdua d'1 màquina.
• Accés a l'apiserver a través d'un balancejador o IP virtual (keepalived + HAProxy) que reparteixi entre les tres rèpliques; el kubeconfig apunta a aquest punt únic, no a una màquina concreta.
• kube-scheduler i kube-controller-manager en actiu-passiu, amb elecció de líder mitjançant Lease: els tres processos corren, però només el líder reconcilia, per evitar duplicar accions.
• Durant 3 minuts sense pla de control, la botiga web continua funcionant amb normalitat: els pods ja corren als nodes i kube-proxy conserva les seves regles de xarxa. El que no passa en aquests 3 minuts és canvi: no es poden desplegar versions, ni escalar, ni recrear pods caiguts, ni executar kubectl.

Un clúster de Kubernetes és un conjunt de processos amb responsabilitats molt estrictes que es comuniquen exclusivament a través del kube-apiserver, amb etcd com a única font de veritat. El pla de control decideix (apiserver, scheduler, controller-manager, cloud-controller-manager) i els nodes executen (kubelet, kube-proxy, runtime via CRI). El pegament conceptual és el bucle de reconciliació: comparar l'estat desitjat que tu declares amb l'estat real observat i actuar fins que coincideixin, de manera contínua i idempotent. Amb aquest mapa mental ja pots raonar sobre incidències en lloc d'endevinar, i saps per què la caiguda del pla de control atura els canvis però no el servei.

Tenim l'arquitectura; ens falta el vocabulari. A les properes lliçons apareixeran constantment termes com pod, ReplicaSet, Service, PVC o namespace, i convé tenir un mapa clar de què és cada cosa i com es relacionen entre si abans de fer-los servir. Això és el que ordena la lliçó següent: Conceptes i Terminologia Clau.