Si ja saps construir una imatge amb Docker i executar un contenidor, tens mig camí fet: saps empaquetar programari. El que Kubernetes resol és l'altra meitat, la que apareix quan aquell contenidor deixa d'estar sol al teu portàtil i passa a ser un dels quaranta que han d'estar vius, accessibles i actualitzats a les tres de la matinada d'un divendres de pont. Aquesta lliçó explica exactament quin problema resol l'orquestració de contenidors, d'on ve Kubernetes, què aporta enfront de les alternatives i —molt important— quan no convé fer-lo servir. És la lliçó que dona sentit a totes les altres: sense entendre el problema, les solucions dels propers onze mòduls semblen complicacions gratuïtes.

1. Del contenidor solt a la flota
2. El salt des de Docker i Docker Compose
3. Breu història: de Borg a la CNCF
4. Què aporta Kubernetes exactament
5. Kubernetes enfront de les alternatives
6. Quan NO convé fer servir Kubernetes
7. L'escenari del curs: Rutas Norte S.L.

Un contenidor resol un problema molt concret: empaquetar una aplicació amb les seves dependències perquè s'executi igual en qualsevol màquina amb un runtime de contenidors. Això és enorme, però és només l'envàs.

Tan bon punt passes a producció apareixen preguntes que el contenidor, per si sol, no respon:

• Ubicació: tinc 5 servidors i 40 contenidors. Quin va on? I quan hi afegeixi el sisè servidor?
• Supervivència: el procés ha mort a les 03:14. Qui el torna a aixecar? I si la màquina sencera s'ha apagat?
• Escalat: avui necessito 3 rèpliques de l'API i el divendres de Setmana Santa en necessitaré 20. Qui les arrenca i qui les apaga després?
• Descobriment: l'API s'ha reiniciat i ara té una altra IP. Com se n'assabenta el frontend?
• Repartiment de càrrega: si hi ha 20 rèpliques, qui decideix a quina va cada petició?
• Desplegament sense tall: vull publicar la versió 2.4.0 sense que cap client vegi un error 502.
• Configuració i secrets: la contrasenya de la base de dades no pot estar a la imatge ni al git log.
• Recursos: un contenidor que es torna boig no pot tombar els altres nou de la mateixa màquina.

Cadascuna d'aquestes preguntes, resolta a mà, es converteix en un script. La suma d'aquests scripts, mantinguda per una persona que se'n va de vacances, és la raó per la qual existeix l'orquestració de contenidors.

Un orquestrador és, en una frase: un sistema al qual descrius l'estat que vols i que s'encarrega permanentment que la realitat s'assembli a aquella descripció. Tu dius "vull 5 rèpliques de l'API en la versió 2.4.0, accessibles a api.rutasnorte.example"; l'orquestrador s'encarrega de decidir on caben, arrencar-les, vigilar-les, substituir les que morin i encaminar el trànsit.

Aquest és el concepte que més costa al principi i el que més rendiment dona després.

Docker és fonamentalment imperatiu (docker run). Kubernetes és fonamentalment declaratiu: escrius un fitxer que descriu el que vols, el lliures al clúster, i a partir d'aquí el clúster treballa per a tu de manera permanent. Si algú esborra un contenidor, torna. Si un servidor cau, les seves càrregues reapareixen en un altre. Aquest mecanisme s'anomena bucle de reconciliació i l'estudiarem a fons a la lliçó Arquitectura de Kubernetes.

Convé aclarir una confusió molt habitual: Kubernetes no substitueix Docker, substitueix el que feies al voltant de Docker.

• Docker (o qualsevol eina compatible amb OCI) continua sent el que fas servir per construir imatges.
• El registre d'imatges continua existint.
• El que canvia és qui executa i governa aquests contenidors.

Docker Compose és el pas intermedi natural. Amb un docker-compose.yml descrius diversos serveis, les seves xarxes i volums, i amb una ordre aixeques tot l'stack. És declaratiu... dins d'una sola màquina. Aquí hi ha el seu sostre:

El que aquest fitxer no pot fer:

1. Repartir aquests serveis entre 5 màquines.
2. Tornar a arrencar l'stack en un altre servidor si l'actual s'apaga.
3. Escalar api-reserves a 20 rèpliques repartides i balancejades.
4. Substituir la imatge 2.3.1 per la 2.4.0 de manera progressiva i amb marxa enrere automàtica si falla.
5. Aïllar entorns (dev, pre, pro) amb permisos i quotes diferents.

Kubernetes fa exactament aquestes cinc coses, i aquest és el salt. El preu és una corba d'aprenentatge i una capa de conceptes nous, que és justament el que aquest curs et donarà.

Kubernetes no va néixer com un experiment. És la tercera generació d'una idea provada durant més d'una dècada.

La dada rellevant per a tu com a professional: en estar sota la CNCF amb governança neutral, Kubernetes és l'única capa d'orquestració que s'executa pràcticament igual al teu portàtil, en un centre de dades propi i a AWS, Azure o Google Cloud. Aquesta portabilitat és un argument de negoci, no només tècnic.

Concretem les capacitats, perquè "orquestrar" és massa vague.

Descrius el resultat en un fitxer YAML i el clúster el manté. No executes passos: publiques intencions. Tota la resta d'aquesta llista se'n deriva.

• Si un contenidor acaba amb error, es reinicia.
• Si un contenidor és viu però no respon (ho detecten les sondes, mòdul 7), es reinicia.
• Si un node sencer deixa de respondre, les seves càrregues es recreen en altres nodes.
• Si algú esborra una rèplica a mà, torna a aparèixer.

Pots passar de 3 a 20 rèpliques amb una ordre, o deixar que el clúster ho faci sol segons CPU, memòria o mètriques de negoci (mòdul 9). Per a Rutas Norte, els pics de trànsit de la qual es concentren en ponts i vacances, això és directament diners: no es paga capacitat ociosa al febrer per sobreviure a l'agost.

Les rèpliques neixen i moren amb IP diferents. Kubernetes et dona un nom estable (api-reserves) que es resol per DNS intern i reparteix el trànsit entre les rèpliques sanes. El frontend no coneix mai cap IP. Ho veuràs al mòdul 4.

Canvies la versió de la imatge i el clúster substitueix les rèpliques a poc a poc, comprovant que les noves són sanes abans de retirar les velles. Si alguna cosa va malament, rollback a la versió anterior. Mòdul 2.

La configuració se separa de la imatge (ConfigMaps) i les credencials es gestionen a part, amb control d'accés (Secrets). Com que postgres-reserves desa dades personals de clients, això no és opcional per a Rutas Norte: és compliment normatiu. Mòdul 3.

Els mateixos manifests funcionen a minikube, en un clúster propi amb kubeadm o a EKS/AKS/GKE. Canvien els detalls d'infraestructura (tipus d'emmagatzematge, balancejador), no la descripció de l'aplicació.

Pots afegir els teus propis tipus d'objecte (CRDs) i la teva pròpia lògica de reconciliació (operadors, mòdul 6). Kubernetes no és només un orquestrador: és una plataforma per construir plataformes.

Cap eina és la millor en abstracte. Aquesta taula et serveix per justificar una decisió davant d'un equip o un client.

Lectures ràpides de la taula:

• Docker Compose no competeix amb Kubernetes: hi conviu. El continuaràs fent servir en local.
• Swarm és més simple, però la seva comunitat i el seu ecosistema s'han reduït dràsticament; començar un projecte nou amb Swarm avui és assumir un deute.
• Nomad és l'alternativa seriosa si tens càrregues que no són contenidors.
• Un PaaS pot ser la resposta correcta, i no és cap fracàs admetre-ho. Es paga més per unitat de còmput, però s'estalvia en persones.

Un professional es distingeix per saber quan no aplicar l'eina. Senyals clares que Kubernetes és excessiu:

1. Equip petit sense perfil de plataforma. Kubernetes necessita algú que en tingui cura: actualitzacions cada pocs mesos, certificats, monitoratge, permisos. Si ningú no té aquest temps assignat, el clúster es degrada.
2. Una sola aplicació monolítica amb trànsit estable. Si dues màquines i un balancejador cobreixen la teva càrrega tot l'any, el clúster només afegeix peces que poden fallar.
3. Càrregues trivials o efímeres. Un cron diari que triga 40 segons no justifica un pla de control.
4. Necessitat de resultats immediats. La migració és un projecte de setmanes o mesos. Si el negoci necessita lliurar en dues setmanes, un PaaS lliura abans.
5. Aplicacions fortament lligades a un servidor concret (llicències per màquina, maquinari especial, estat en disc local sense rèplica). Es pot fer, però lluites contra el disseny.
6. Cost real mal calculat. Un clúster gestionat té cost de pla de control, nodes amb capacitat reservada, trànsit i emmagatzematge. Per a tres contenidors, surt car.

Regla pràctica: Kubernetes comença a sortir a compte quan tens diversos serveis, diversos entorns i més d'una persona desplegant. Abans d'això, sol ser una solució buscant un problema.

Tot el curs gira al voltant d'una empresa fictícia: Rutas Norte S.L., que ven bitllets d'autobús per internet a través de la plataforma Rutas Norte. Aquí només la presentem; el detall complet és a la lliçó El Projecte del Curs: la Plataforma Rutas Norte.

La seva situació de partida és la de moltíssimes empreses reals:

• La plataforma corre amb Docker Compose sobre dues màquines llogades.
• Els desplegaments són manuals: algú entra per SSH, fa docker compose pull i up -d. Hi ha tall de servei d'un o dos minuts, així que es desplega de nit.
• En ponts i vacances el trànsit es multiplica; el web s'alenteix i algunes reserves es perden. L'única resposta és contractar una màquina més gran i deixar-la ociosa la resta de l'any.
• Quan un contenidor mor de matinada, ningú no l'aixeca fins l'endemà al matí.
• La contrasenya de la base de dades és en un fitxer .env que s'ha copiat per correu més vegades de les que ningú vol admetre; i aquesta base de dades desa dades personals de clients.

La direcció tècnica ha decidit migrar a Kubernetes per quatre raons, que són exactament les capacitats de la secció 4:

A partir de la propera lliçó anirem construint aquesta plataforma peça a peça, i cada concepte nou es justificarà amb una necessitat concreta de Rutas Norte.

• "Kubernetes substitueix Docker". No. Continues construint imatges igual. El que Kubernetes substitueix és docker run, els scripts d'arrencada i el balancejador manual. Des de la versió 1.24 el clúster parla amb containerd o CRI-O a través de la interfície CRI, no amb el dimoni de Docker: per això va desaparèixer dockershim.
• Traduir docker-compose.yml mecànicament. Existeixen eines de conversió, però el resultat sol ser un mal desplegament: no aprofita sondes, ni límits de recursos, ni configuració externalitzada. Convé redissenyar, no traduir.
• Començar pel clúster de producció. L'ordre correcte és: entorn local (mòdul 1), entendre objectes (mòduls 2 i 3), i només llavors plantejar producció.
• Creure que Kubernetes et fa l'aplicació resilient. El clúster reinicia contenidors; no arregla una aplicació que perd dades en reiniciar-se o que no tolera tenir diverses instàncies. Kubernetes premia les aplicacions ben dissenyades i castiga les que no ho estan.
• Ignorar el cost de les persones. El pressupost d'un clúster no és només infraestructura: és formació, guàrdies i manteniment. Posa-ho per escrit abans de proposar la migració.
• Consell de vocabulari: acostuma't des d'avui a dir "estat desitjat" i "reconciliació". Quan alguna cosa no funcioni al clúster, la pregunta correcta gairebé sempre és: quin estat he declarat i per què el clúster no el pot assolir?

Sense escriure cap manifest, elabora una taula amb els cinc problemes operatius que pateix Rutas Norte avui i, per a cadascun, indica: (a) quina capacitat de Kubernetes el resoldria, i (b) què passaria si l'empresa decidís no migrar i simplement contractar servidors més grans.

Per a cadascun d'aquests tres casos, decideix si recomanaries Kubernetes, un PaaS o Docker Compose, i justifica la decisió en tres línies:

1. Una startup de dues persones amb una aplicació web i una base de dades, que necessita sortir al mercat en un mes.
2. Una asseguradora amb 60 microserveis, tres entorns, requisits d'auditoria i equips en dos països.
3. Un blog corporatiu estàtic amb 200 visites al dia.

Escriu un paràgraf d'un màxim de 150 paraules adreçat a la direcció no tècnica de Rutas Norte explicant per què migrar a Kubernetes, sense fer servir les paraules "pod", "contenidor" ni "clúster". Ha d'esmentar cost, disponibilitat i dades de clients.

Solució 1

Solució 2

1. PaaS. Dues persones no poden mantenir un clúster i sortir al mercat en un mes. La prioritat és lliurar; la dependència del proveïdor és un problema acceptable que es resol més endavant si el producte funciona.
2. Kubernetes. 60 microserveis, tres entorns i auditoria són exactament el punt on el cost operatiu s'amortitza: RBAC, namespaces per entorn, polítiques de xarxa i desplegaments homogenis entre equips i països.
3. Cap dels tres, o Docker Compose com a molt. 200 visites al dia en un lloc estàtic se serveixen amb allotjament estàtic o una CDN. Qualsevol orquestrador és cost pur sense benefici.

Solució 3 (exemple de resposta vàlida)

Avui la venda de bitllets depèn de dues màquines que gestionem a mà. Quan alguna cosa falla de nit, no es recupera fins l'endemà al matí, i en ponts i vacances —just quan més venem— el web s'alenteix i perdem reserves. A més, paguem tot l'any una capacitat que només necessitem unes setmanes. La nova plataforma que proposem vigila el servei de manera contínua i el restableix sola si falla, amplia la capacitat automàticament quan puja la demanda i la redueix quan baixa, i permet publicar millores sense tancar el web. També separa les claus d'accés a les dades dels nostres clients del codi i registra qui les pot consultar, la qual cosa reforça la nostra posició davant d'una auditoria de protecció de dades. El cost inicial és de formació i posada en marxa; l'estalvi és en capacitat no malbaratada i en vendes que avui es perden.

Kubernetes és un orquestrador de contenidors: un sistema al qual declares l'estat que vols i que treballa de manera contínua per mantenir-lo, aportant autoreparació, escalat, descobriment de serveis, desplegaments sense tall i portabilitat entre núvols. Va néixer de l'experiència de Google amb Borg, avui és un projecte neutral de la CNCF i s'ha convertit en l'estàndard de facto, però té un cost operatiu real que el desaconsella per a equips petits i càrregues trivials. Rutas Norte encaixa de ple en el perfil que sí que el justifica: diversos serveis, diversos entorns, pics de demanda pronunciats i dades personals que cal protegir.

Ja saps què fa Kubernetes. La pregunta següent és com ho fa: quines peces componen un clúster, quin és el bucle de reconciliació que sosté tot el model declaratiu i què passa exactament, pas a pas, des que envies un manifest fins que hi ha un contenidor corrent en un node. Això és el que veurem a Arquitectura de Kubernetes.