Poques tecnologies han canviat tant la manera d’operar infraestructura com Kubernetes. El que va començar com un projecte intern de Google avui és l’estàndard de facto per desplegar aplicacions en contenidors, i tot plegat descansa sobre els fonaments del nucli Linux. T’has preguntat mai com una sola plataforma pot gestionar milers de contenidors repartits per desenes de màquines sense que un humà vigili cadascun? La resposta té un nom: orquestració.
De Borg a Kubernetes
Kubernetes va sortir de l’experiència de Google executant contenidors a una escala que poques organitzacions assoleixen. Durant anys, Google va gestionar les seves càrregues internes amb un sistema anomenat Borg, desenvolupat a mitjans de la dècada del 2000. D’aquell coneixement acumulat va sorgir Kubernetes, que Google va anunciar com a projecte de codi obert el 6 de juny de 2014, data que molts prenen com el seu aniversari oficial.
El projecte va créixer de pressa. Coincidint amb la versió 1.0, l’any 2015 Google va donar Kubernetes a la nova Cloud Native Computing Foundation (CNCF), sota el paraigua de la Linux Foundation. Aquesta cessió a una fundació neutral va marcar la diferència: va donar una governança independent de qualsevol fabricant i va atraure una comunitat enorme. El nom, que molts abreugen com a K8s (la K, vuit lletres i la s), ve del grec per a “timoner” o “pilot”. Encaixa amb una cosa que dirigeix flotes de contenidors.
Per què tot depèn del nucli Linux
Aquí hi ha el detall que molta gent passa per alt: Kubernetes no inventa l’aïllament de processos. S’aprofita de les mateixes primitives que qualsevol contenidor Linux fa servir des de fa anys. Els namespaces del nucli aïllen el que cada contenidor pot veure (processos, xarxa, sistema de fitxers, identificadors d’usuari), i els cgroups (control groups) limiten i comptabilitzen els recursos que consumeix: CPU, memòria i entrada/sortida.
Un contenidor, en el fons, és un procés Linux normal amb aquestes barreres aplicades. Kubernetes opera un nivell per damunt: decideix en quina màquina arrenca cada contenidor, quantes còpies manté vives i com les connecta entre si. Per això els nodes de treball d’un clúster són, gairebé sempre, màquines Linux. Distribucions com Ubuntu i Debian abunden en aquests nodes, i en entorns empresarials amb suport comercial és molt comú RHEL o les seves bases comunitàries AlmaLinux i Rocky Linux.
Anatomia d’un clúster
Un clúster de Kubernetes es divideix en dos plans. El pla de control és el cervell: conté el servidor d’API amb què parles, el planificador que decideix on col·locar cada càrrega, el magatzem d’estat (etcd) i els controladors que vigilen que la realitat coincideixi amb el que has demanat. Els nodes de treball són els músculs: executen els contenidors reals mitjançant un agent anomenat kubelet.
La unitat mínima de desplegament no és el contenidor solt, sinó el pod: un grup d’un o més contenidors que comparteixen xarxa i emmagatzematge. Sobre els pods es construeixen abstraccions de més alt nivell com els Deployments, que mantenen un nombre desitjat de rèpliques i permeten actualitzacions graduals sense tallar el servei.
Desplegament, escalat i autoreparació
La gràcia de Kubernetes rau en el seu model declaratiu. No li ordenes pas a pas què ha de fer; li descrius l’estat final que vols (“vull cinc rèpliques d’aquesta aplicació”) i el sistema treballa sense descans per assolir-lo i mantenir-lo. Si un node cau, Kubernetes reprograma els seus pods en una altra màquina sana. Si un contenidor es bloqueja, el reinicia. Això és l’autoreparació.
L’escalat funciona en totes dues direccions: pots afegir rèpliques a mà o configurar un autoescalador que reaccioni a la càrrega real, aixecant més còpies quan puja el trànsit i retirant-les quan baixa. Per a entorns amb recursos ajustats o imatges minimalistes, Alpine Linux és una elecció popular com a base de contenidors per la seva mida reduïda, cosa que accelera descàrregues i arrencades.
Container runtimes: el motor sota el capó
Kubernetes no executa contenidors directament; delega aquesta tasca en un container runtime que compleixi la interfície CRI (Container Runtime Interface). Durant anys el més conegut va ser Docker, però el projecte va evolucionar cap a runtimes més lleugers i alineats amb l’estàndard. A la versió 1.24, llançada el maig de 2022, Kubernetes va treure definitivament el component dockershim, l’adaptador que permetia parlar amb Docker directament.
Avui les opcions dominants són containerd (el mateix motor que Docker feia servir internament) i CRI-O, fet a mida per a Kubernetes. Tant és que les teves imatges es construïssin amb Docker: continuen funcionant, perquè compleixen el format OCI estàndard. Qui necessitava conservar Docker com a runtime va passar a un adaptador anomenat cri-dockerd.
On practicar sense trencar res
No cal un centre de dades per aprendre Kubernetes. Eines com Minikube o kind aixequen un clúster complet a la teva pròpia màquina dins de contenidors. Sobre qualsevol distribució d’escriptori moderna, ja sigui Fedora, openSUSE o Pop!_OS, pots experimentar amb desplegaments, escalats i errors simulats sense cost ni risc.
Kubernetes no substitueix Linux: l’amplifica. Pren les peces que el nucli porta dècades polint i les orquestra a una escala que seria impossible de gestionar a mà. Entendre aquesta relació és el primer pas per dominar la infraestructura moderna.