Fonaments de Kubernetes
Què és Kubernetes i per què l'hem d'aprendre?
Quan parlem de Kubernetes (que veureu escrit sovint com K8s, on el 8 representa les 8 lletres entre la K i la s), estem parlant d'una de les eines més importants en el món del desenvolupament i desplegament d'aplicacions modernes. Però anem a començar des del principi per entendre per què aquesta tecnologia s'ha convertit en un estàndard de la indústria.
Imagineu que teniu una aplicació web, per exemple una botiga online. Aquesta aplicació funciona molt bé quan teniu pocs usuaris, però què passa quan de sobte teniu un pic de trànsit? Potser per Black Friday, o perquè heu sortit a les notícies i tothom vol veure la vostra aplicació. El vostre servidor comença a saturar-se, l'aplicació va lenta, i alguns usuaris fins i tot reben errors. Aquest és un problema clàssic d'escalabilitat.
Tradicionalment, la solució passaria per tenir diversos servidors, configurar un balancejador de càrrega, assegurar que tots els servidors tenen la mateixa versió de l'aplicació, i gestionar què passa si un servidor falla. Tot això de forma manual pot ser un malson. Aquí és on entra Kubernetes.
Kubernetes és una plataforma de codi obert que automatitza el desplegament, l'escalat i la gestió d'aplicacions que funcionen dins de contenidors (com Docker). Va ser creat originalment per Google basant-se en la seva experiència interna gestionant milers de milions de contenidors, i actualment està mantingut per la Cloud Native Computing Foundation (CNCF), una organització que agrupa empreses com Google, Microsoft, Amazon i moltes altres.
El que fa especial Kubernetes és que et permet declarar com vols que sigui el teu sistema (per exemple, "vull que sempre hi hagi 3 instàncies de la meva aplicació funcionant"), i Kubernetes s'encarrega de fer que això sigui una realitat constantment. Si una instància falla, Kubernetes en crea una de nova automàticament. Si necessites més capacitat, només has de dir-li que vols 10 instàncies en lloc de 3, i ell ho gestiona.
Versions i suport de Kubernetes
És important entendre com funciona el cicle de versions de Kubernetes perquè en un entorn professional haureu de mantenir els vostres clústers actualitzats. Al moment d'escriure aquest document, a l'octubre de 2025, la versió més recent i estable de Kubernetes és la v1.34, que es va llançar l'agost de 2025. Aquesta versió va introduir 58 millores noves, de les quals 23 van passar a ser funcionalitats estables.
Kubernetes segueix el que s'anomena una política de suport N-2. Això significa que sempre mantenen amb suport les tres versions més recents. Actualment, aquestes són la v1.34, v1.33 i v1.32. Cada versió rep suport durant 14 mesos en total, que es divideixen en 12 mesos de suport actiu més 2 mesos addicionals de perióde d'actualització. Això vol dir que teniu temps suficient per planificar i executar les actualitzacions sense pressa, però també vol dir que no podeu ignorar les actualitzacions indefinidament, per no arribar al end of life de la versió.
Kubernetes llança una nova versió menor aproximadament cada quatre mesos. La propera versió, la v1.35, està prevista per desembre de 2025. Cada versió porta un nom temàtic, com les distribucions de linux Ubuntu/Debian. Per exemple, la v1.33 es deia "Octarine", i la v1.34 es diu "Of Wind & Will".
Com funciona l'arquitectura de Kubernetes per dins
Per entendre bé Kubernetes, hem de comprendre com està organitzat internament. Kubernetes funciona amb una arquitectura que tradicionalment s'anomena mestre-esclau, però que actualment es coneix amb els termes més moderns de "control plane" (pla de control) i "worker nodes" (nodes de treball). Penseu en això com una empresa: teniu un equip directiu que pren decisions i planifica, i teniu els treballadors que executen el treball real.
El Control Plane: el cervell del clúster
El control plane és el cervell de Kubernetes. És el conjunt de components que prenen totes les decisions sobre què passa al clúster. Per exemple, decideix on col·locar cada aplicació, quan escalar-les, i què fer quan alguna cosa va malament. El control plane no executa les vostres aplicacions, només les gestiona.
Dins del control plane trobem diversos components, cadascun amb una responsabilitat específica. El primer i més important és el kube-apiserver, que és literalment la porta d'entrada a tot el sistema. Cada vegada que voleu fer alguna cosa amb Kubernetes, ja sigui desplegar una aplicació, veure l'estat del clúster, o eliminar recursos, ho feu parlant amb l'API server. Aquest component exposa una API REST sobre HTTPS, i absolutament tot al clúster passa per ell. Tant vosaltres com a usuaris, com la resta de components de Kubernetes, parlen amb l'API server per saber què està passant i per demanar canvis.
El següent component fonamental és etcd, que és la memòria del clúster. Etcd és una base de dades distribuïda de tipus clau-valor que guarda tota la informació sobre l'estat del clúster. Aquí s'emmagatzema quins pods s'estan executant, quines configuracions teniu definides, quin és l'estat de cada node, i bàsicament tot el que Kubernetes necessita recordar. És extremadament important, i per això en entorns de producció sempre es fa servir amb replicació per assegurar que no es perdi mai aquesta informació.
El kube-scheduler és el component responsable de decidir on executar cada pod. Quan creeu un pod nou, el scheduler mira tots els nodes disponibles al clúster i decideix quin és el millor lloc per col·locar-lo. Té en compte moltes coses: quants recursos CPU i memòria necessita el pod, quants recursos té disponibles cada node, si hi ha requisits especials com "ha d'executar-se al mateix node que un altre pod" o "no pot executar-se en nodes de determinat tipus". És com un gestor de recursos humans que decideix quin treballador és el més adequat per a cada tasca.
El kube-controller-manager és en realitat un conjunt de controladors diferents que s'executen junts. Cada controlador té una feina específica: hi ha un controlador que vigila els nodes i detecta quan un node deixa de funcionar, un altre que s'assegura que sempre tingueu el nombre correcte de rèpliques dels vostres pods, un altre que gestiona els serveis, etc. Els controladors segueixen un patró molt simple però molt potent: observen constantment l'estat actual del clúster, el comparen amb l'estat desitjat que heu definit, i prenen accions per fer que l'estat actual s'assembli a l'estat desitjat.
Finalment, hi ha el cloud-controller-manager, que és opcional i només cal si esteu executant Kubernetes en un proveïdor de núvol com AWS, Google Cloud o Azure. Aquest component s'encarrega d'integrar Kubernetes amb els serveis del núvol, per exemple creant balancejadors de càrrega del proveïdor quan els necessiteu, o gestionant els volums d'emmagatzematge.
Els Worker Nodes: on realment s'executen les aplicacions
Mentre que el control plane pren totes les decisions, els worker nodes són on realment s'executen les vostres aplicacions. Cada node és un servidor (físic o virtual) que forma part del clúster. Podeu tenir tres nodes, deu nodes, o mil nodes, depenent de les vostres necessitats.
Cada worker node té tres components principals. El primer és el kubelet, que és com l'agent de Kubernetes al node. El kubelet s'executa com un daemon al sistema operatiu (no com un contenidor) i és el responsable d'assegurar que els contenidors que se suposa que han d'executar-se al node realment s'estan executant. Parla amb l'API server per rebre instruccions sobre quins pods ha d'executar, i després treballa amb el container runtime per posar en marxa aquests contenidors. També monitoritza constantment la salut dels pods i reporta l'estat a l'API server.
El kube-proxy és el component responsable de la xarxa dins del clúster. Gestiona les regles de xarxa que permeten que els pods es puguin comunicar entre ells i amb el món exterior. Quan definiu un Service a Kubernetes (que veurem més endavant), kube-proxy és el que fa la màgia de fer que aquest servei funcioni, redirigint el trànsit de xarxa als pods correctes i fent balanceig de càrrega entre ells.
Finalment, necessitem un container runtime, que és el motor que realment executa els contenidors. Docker va ser el més popular durant molt de temps, però actualment containerd (la part de Docker que realment executa contenidors) és l'opció més comuna, i també es fa servir CRI-O. Aquest component és el que agafa una imatge de contenidor, la descarrega si cal, i la posa en marxa.
Tota aquesta arquitectura està documentada en detall a:
