Tanquem el mòdul 9 amb un diagnòstic incòmode: la plataforma Rutas Norte ja sap escalar sola, resistir el pont de maig i protegir-se durant els manteniments, però el directori k8s/ s'ha convertit en més de 120 fitxers YAML duplicats entre dev, pre i pro que algú aplica a mà des del seu portàtil. El mòdul 10 va precisament d'això: de les eines que envolten Kubernetes i que converteixen un munt de manifestos solts en un sistema operable.

Comencem per la baula més propera a l'equip de desenvolupament: el clúster local. Abans de plantillar res amb Helm (10-03), superposar res amb Kustomize (10-04) o reconciliar res amb Argo CD (10-05), cal un lloc barat i llencable on provar els canvis. Al mòdul 1 vam aixecar el clúster de pràctiques amb minikube start --profile=rutas-norte gairebé com un tràmit, i vam dir que hi tornaríem. Ha arribat el moment: en aquesta lliçó anem a fons amb minikube, coneixem kind (l'eina preferida en integració contínua), comparem les cinc alternatives més habituals i, sobretot, aprenem què es pot validar en un clúster local i què no, que és l'arrel del clàssic «a la meva màquina funciona».

1. Per què tot equip necessita un clúster llencable
2. Minikube a fons: perfils i controladors
3. Dimensionament, versió de Kubernetes i clústers multinode
4. El catàleg d'addons
5. Treballar amb imatges locals sense registre
6. Accés al clúster: tunnel, service, dashboard, mount i ssh
7. El cicle de vida: stop, start, delete i logs
8. kind a fons: nodes com a contenidors
9. Taula comparativa: minikube, kind, k3d, Docker Desktop i Rancher Desktop
10. Les diferències amb producció que provoquen «a la meva màquina funciona»
11. Recepta reproduïble: l'entorn complet de Rutas Norte en local
12. Errors comuns i consells
13. Exercicis
14. Conclusió

A Rutas Norte S.L. hi ha tres entorns reals: rutas-norte-dev, rutas-norte-pre i rutas-norte-pro. Tots tres viuen en clústers compartits. Això vol dir que quan una desenvolupadora vol provar si la seva nova NetworkPolicy trenca la connexió entre api-reserves i postgres-reserves, té dues opcions dolentes:

• Aplicar-la a rutas-norte-dev i arriscar-se a bloquejar la feina dels altres sis companys que comparteixen aquell namespace.
• No provar-la i descobrir-ho a pre, amb el cicle d'espera que això implica.

Un clúster local resol el dilema. És seu, gratuït, ràpid de recrear i, si el trenca, minikube delete i tornem a començar en tres minuts.

La regla pràctica: el clúster local valida la correcció dels teus manifestos i la lògica de la teva aplicació; no valida el rendiment, la topologia ni la integració amb el núvol.

minikube és una eina que aixeca un clúster de Kubernetes d'un sol node (o de diversos) dins d'una màquina virtual o un contenidor del teu equip. L'hem fet servir des del mòdul 1; ara entendrem què fa per dins.

Un perfil és un clúster independent amb el seu propi nom, la seva pròpia configuració i el seu propi context de kubectl. És la raó per la qual al mòdul 1 vam escriure --profile=rutas-norte i no simplement minikube start.

Sortida típica:

Sense --profile, minikube fa servir el perfil minikube. Pots fixar el perfil actiu per no repetir-lo a cada ordre:

Consell: fixar el perfil és còmode però perillós, perquè és un estat invisible. Als scripts de l'equip Rutas Norte fem servir sempre --profile=rutas-norte explícit.

Cada perfil crea també el seu context de kubectl amb el mateix nom:

El controlador (driver) decideix on s'executa el node de minikube. És la decisió més important en començar.

Com triar, en tres preguntes:

1. Tens Docker o Podman funcionant? Fes servir --driver=docker (o podman). És el més ràpid i el que menys memòria consumeix, perquè no hi ha una VM completa pel mig.
2. Necessites provar mòduls del kernel, un CNI exigent o iptables de debò? Fes servir kvm2 a Linux. Un contenidor comparteix kernel amb l'amfitrió i algunes coses no es poden aïllar.
3. Estàs a Windows sense WSL2 o en un entorn corporatiu restringit? hyperv o virtualbox són la sortida.

Amb el controlador docker, el node és literalment un contenidor. Pots veure-ho:

Aquest kicbase és la imatge que conté systemd, containerd, el kubelet i les eines necessàries perquè un contenidor es comporti com un node.

Per defecte minikube demana 2 CPU i 2 GB de memòria. Per a Rutas Norte això es queda curt tan bon punt instal·lem Prometheus (07-03) i cert-manager (04-05):

Explicació de cada opció:

• --cpus=4: nombre de CPU virtuals assignades al node. Amb menys de 4, el kube-apiserver i Prometheus competeixen i el clúster es percep lent.
• --memory=8192: memòria en MiB (8 GB). També pots escriure 8g. Compte: aquesta memòria es reserva davant del teu sistema; si el teu portàtil té 16 GB, no li'n donis 12.
• --disk-size=40g: mida del disc del node. Les imatges de contenidor s'acumulen ràpid; 20 GB s'esgoten en un parell de setmanes de feina real.

Aquests valors es recorden per perfil. Si demà executes minikube start --profile=rutas-norte sense flags, respecta el que ja vas configurar. Per canviar-los cal esborrar i recrear el perfil (o fer servir minikube config set abans).

Un advertiment important: --cpus i --memory no es poden canviar en calent amb el controlador de VM. Si et quedes curt, minikube delete --profile=rutas-norte i torna a crear-lo amb els valors nous. Per això convé tenir l'script de creació versionat (apartat 11).

Aquesta és una de les pràctiques més rendibles i més oblidades. Si rutas-norte-pro corre Kubernetes 1.30 i el teu minikube corre 1.32, pots escriure manifestos que funcionen al teu portàtil i són rebutjats en producció, o al revés: pots no detectar una API obsoleta.

Sortida:

Regla de l'equip de plataforma de Rutas Norte: el fitxer de l'script d'arrencada local declara la mateixa versió menor que producció. Quan pro puja de versió, l'script s'actualitza en el mateix canvi.

Un sol node no permet provar res relacionat amb la planificació: afinitats (06-05), topologySpreadConstraints (09-05), DaemonSets amb diversos objectius (06-02) o el drenatge d'un node. minikube en sap crear diversos:

Fixa't que --cpus i --memory s'apliquen per node: tres nodes de 2 CPU i 4 GB consumeixen 6 CPU i 12 GB de l'amfitrió. És fàcil ofegar el portàtil sense adonar-se'n.

Pots afegir o treure nodes després:

I etiquetar els nodes per simular zones i provar la distribució topològica de 09-05:

Això és una simulació útil per verificar que el selector funciona, però recorda: continuen estant a la mateixa màquina física, així que no prova la tolerància real a la caiguda d'una zona.

Els addons són components preempaquetats que minikube sap instal·lar i mantenir per tu. És el que evita haver d'aplicar a mà els manifestos del controlador d'Ingress o del metrics-server.

Els que fa servir aquest curs i per què:

Cada addon és, per dins, un conjunt de manifestos que minikube aplica al namespace kube-system (o a un de propi). Pots veure'ls:

Avís important: l'addon ingress de minikube instal·la ingress-nginx amb una configuració pensada per a un sol node. En producció, el teu equip de plataforma probablement l'instal·la amb Helm i amb valors molt diferents (rèpliques, PDB, recursos). El comportament de les regles és el mateix; el de la disponibilitat, no.

Aquest és, a la pràctica diària, el punt on més temps es perd. Has construït api-reserves:dev-local al teu portàtil i el pod es queda a ImagePullBackOff, perquè el node de minikube té el seu propi magatzem d'imatges, separat del Docker de la teva màquina.

Hi ha tres maneres de resoldre-ho.

Al manifest, la clau és evitar que Kubernetes intenti descarregar-la del registre:

Parany clàssic: si l'etiqueta de la imatge és latest, Kubernetes aplica per defecte imagePullPolicy: Always i sempre intentarà descarregar-la, ignorant la còpia local. No facis servir mai latest (ja ho vam veure a 08-05); aquí a més et trenca el flux local.

Si hi ha diversos nodes, image load la copia a tots automàticament.

Aquesta opció reapunta el teu client Docker al dimoni que corre dins del node de minikube. El que construeixis queda directament disponible per al kubelet, sense pas de còpia.

Avantatge: és més ràpid al bucle editar-construir-provar, perquè no hi ha còpia. Desavantatge: només funciona amb el runtime docker; si el perfil fa servir containerd, no s'aplica. I és un estat del terminal fàcil d'oblidar (has construït dins del node i després no trobes la imatge a la teva màquina).

Aixeca un registre dins del clúster. És l'opció més semblant a producció, però també la que més passos exigeix (cal empènyer la imatge, resoldre el nom des del node). Per a la feina diària, l'opció A guanya gairebé sempre.

Quan declares un Service de tipus LoadBalancer (04-02), Kubernetes demana a un controlador del proveïdor de núvol que aprovisioni un balancejador. Al teu portàtil no hi ha proveïdor de núvol, així que el Service es queda per sempre a <pending>:

minikube tunnel simula aquest balancejador: crea rutes a la teva màquina i assigna una IP externa.

Ara, en un altre terminal:

Punts que confonen tothom la primera vegada:

• El procés ha de seguir viu. Si tanques el terminal, la IP torna a <pending>.
• No és un balancejador real: no hi ha comprovacions de salut del proveïdor, ni distribució entre zones, ni regles de tallafocs de núvol. Només encamina.
• A macOS i Windows amb el controlador docker, tunnel també és necessari per arribar a l'Ingress.

Per a Services de tipus NodePort (o fins i tot ClusterIP amb --url), aquesta és la via ràpida:

Activa l'addon dashboard si no ho estava, aixeca un proxy i obre el navegador. Útil per explorar visualment el clúster mentre aprens; en el dia a dia professional kubectl i k9s són més ràpids.

De vegades vols que el pod vegi un directori del teu portàtil: un bolcat SQL de dades de prova per a postgres-reserves, o els fitxers estàtics de botiga-web.

Al pod es fa servir un hostPath (05-01) apuntant a /dades-prova, que ara existeix dins del node:

Advertiment: hostPath està prohibit per les Pod Security Standards del nivell restricted (08-03). En local és acceptable per a dades de prova; a rutas-norte-pro seria rebutjat, i amb raó.

Et deixa dins del node. Útil per a:

En un clúster multinode, tria el node:

--purge esborra a més el directori ~/.minikube amb la configuració i la memòria cau d'imatges de Kubernetes. Fes-lo servir quan minikube estigui en un estat estrany que no aconsegueixes explicar; és l'equivalent a apagar i encendre.

Quan minikube start falla o el clúster arrenca a mitges:

Aquest tipus de missatge gairebé sempre significa que el node es va quedar sense recursos o que l'estat de xarxa del contenidor va quedar corrupte després d'una aturada brusca. minikube delete && minikube start ho resol, i és exactament per això que un clúster local ha de ser llencable.

kind (Kubernetes IN Docker) té un enfocament diferent i una filosofia més estreta: cada node del clúster és un contenidor de Docker que executa containerd i el kubelet. No hi ha addons, no hi ha tunnel, no hi ha dashboard. Només Kubernetes, molt ràpid i molt reproduïble.

Precisament per aquesta austeritat, és l'eina que el mateix projecte Kubernetes fa servir per a les seves proves i l'elecció habitual en integració contínua.

Triga uns 25 segons. El context es diu kind-rutas-norte (amb el prefix kind-).

Aquí hi ha la veritable potència de kind: el clúster es declara en un fitxer versionable.

Repassem els camps clau:

• extraPortMappings: publica un port del contenidor-node a la teva màquina. És la solució de kind al problema de l'accés extern. Amb hostPort: 80, un cop instal·lat ingress-nginx, curl -H "Host: www.rutasnorte.example" http://localhost arriba a botiga-web. Només es pot definir en crear el clúster: si l'oblides, cal recrear-lo.
• extraMounts: l'equivalent a minikube mount, però declaratiu i sense procés en primer pla. Molt més còmode.
• kubeadmConfigPatches: kind fa servir kubeadm per dins (ho veurem a 10-02). Aquest camp et deixa modificar-ne la configuració; aquí el fem servir per posar l'etiqueta ingress-ready=true que el manifest d'ingress-nginx per a kind espera al seu nodeSelector.
• image: fixa la versió de Kubernetes. Igual que amb minikube, iguala-la a producció.
• labels: etiquetes de node aplicades des del principi, sense kubectl label posterior.

Ara sí:

Igual que a minikube, la imatge es copia a tots els nodes. I també aquí cal imagePullPolicy: IfNotPresent i evitar l'etiqueta latest.

També pots carregar un fitxer d'imatge exportat, pràctic en canalitzacions on la construcció i la càrrega estan en passos diferents:

Un pas típic a la canalització ci-rutasnorte es redueix a: kind create cluster --config kind-ci.yaml --wait 120s, construir i carregar la imatge, kubectl apply -k k8s/entorns/dev (això és Kustomize, ho veurem a 10-04), esperar el rollout, executar les proves de fum i kind delete cluster al final passi el que passi.

Notes per triar:

• k3s (el motor de k3d i Rancher Desktop) és una distribució lleugera i conforme, però substitueix algunes peces: fa servir Traefik com a Ingress, SQLite en comptes d'etcd per defecte i desactiva components de núvol. És perfecte per desenvolupar; és enganyós si vols comprovar un comportament fi del pla de control.
• Docker Desktop amb Kubernetes activat és el més còmode si ja el tens, però és un sol node, no configurable, i la seva llicència és de pagament per a empreses per sobre de certa mida. Rutas Norte S.L. és petita, així que no l'afecta, però és un factor real en decisions d'equip.
• La recomanació d'aquest curs: minikube per a la feina diària (pels addons, que estalvien molta instal·lació manual) i kind a la canalització ci-rutasnorte (per velocitat i reproduïbilitat). Que siguin dues eines diferents no és un problema si el manifest que desplegues és el mateix.

Aquest apartat és el més important de la lliçó. Cada punt és un incident real esperant a passar.

En local, type: LoadBalancer no fa res sense minikube tunnel. A rutas-norte-pro, aquest mateix Service aprovisiona un balancejador de veritat, amb la seva IP pública, el seu cost mensual i el seu temps d'aprovisionament de diversos minuts.

Conseqüències que només veus al núvol: anotacions específiques del proveïdor (tipus de balancejador, certificats, llistes d'accés), comprovacions de salut pròpies, i el fet que esborrar el Service esborra el balancejador. Ho veurem a 10-06.

Mitigació: en local, fes servir Ingress (04-04) i no LoadBalancer als manifestos de l'aplicació. Deixa el LoadBalancer només per al controlador d'Ingress, que en local es publica per NodePort o extraPortMappings.

A minikube, la StorageClass standard és un directori del node servit per storage-provisioner. A rutas-norte-pro, postgres-reserves fa servir una StorageClass de disc de xarxa amb IOPS provisionades (05-04).

Aquest últim punt és traïdor: en producció el PV no es crea fins que el pod es planifica, i això canvia l'ordre dels esdeveniments. Un StatefulSet que arrenca bé en local pot quedar-se a Pending al núvol per una afinitat de zona incompatible.

Aquest és el més perillós perquè falla en silenci. Escrius una NetworkPolicy que aïlla postgres-reserves perquè només api-reserves hi pugui parlar (04-06), l'apliques al teu minikube, l'objecte es crea sense error... i no fa absolutament res, perquè el CNI per defecte no la implementa.

Sembla que funciona. Però:

Connecta. La política es va ignorar.

Com detectar-ho: kubectl get pods -n kube-system -o wide | grep -Ei 'calico|cilium|flannel|kindnet'. kindnet (el de kind per defecte) i el bridge bàsic no implementen NetworkPolicies; calico i cilium sí.

Mitigació: a minikube, --cni=calico. A kind, disableDefaultCNI: true amb podSubnet: "192.168.0.0/16" i aplicar després el manifest de Calico.

I la regla d'or: una NetworkPolicy no està provada fins que has verificat que una cosa que abans connectava, ara no connecta. Provar només que el que està permès continua funcionant no demostra res.

topologySpreadConstraints (09-05) amb topologyKey: topology.kubernetes.io/zone en un clúster d'un node se satisfà trivialment. Etiquetar els nodes d'un clúster multinode simula zones i verifica que el selector i les etiquetes són correctes, però no prova la tolerància a fallades.

Igual amb el Cluster Autoscaler (09-03): en local no hi ha grup de nodes elàstic, així que un pod Pending per falta de recursos es queda Pending per sempre. En producció apareixeria un node nou en dos minuts. El símptoma en local és idèntic a una fallada greu en producció, cosa que despista.

El pitjor d'un entorn local és que cada persona de l'equip el tingui diferent. La solució és un script versionat al repositori, al costat dels manifestos.

Explicació de les decisions de l'script:

• set -euo pipefail: avorta a la primera ordre que falli, en comptes de continuar deixant un clúster a mitges.
• Versió de Kubernetes en una variable a dalt: quan pro puja de versió, es canvia una línia.
• --cni=calico: la diferència entre provar de debò les NetworkPolicies i enganyar-se.
• --dry-run=client -o yaml | kubectl apply -f -: el patró idempotent de 01-06; crea el namespace si no existeix i no falla si ja existeix.
• kubectl wait: l'script no acaba fins que el clúster és realment usable. Sense això, qui l'executa prova de desplegar i falla perquè l'Ingress encara no hi és.
• L'avís final sobre /etc/hosts: els dominis www.rutasnorte.example i api.rutasnorte.example no existeixen en cap DNS; cal resoldre'ls a mà contra la IP del node.

L'equivalent amb kind és encara més curt, perquè tota la configuració del clúster ja és a kind-rutas-norte.yaml: n'hi ha prou amb kind create cluster --config ... --wait 180s, aplicar Calico i ingress-nginx, esperar el controlador i carregar les imatges amb kind load docker-image. I no cal tocar /etc/hosts: gràcies a extraPortMappings, l'Ingress respon a http://localhost amb la capçalera Host adequada.

1. Donar a minikube gairebé tota la memòria del portàtil. Amb 16 GB físics, --memory=12288 deixa el sistema operatiu sense marge i tot va a batzegades. Regla: no més de la meitat de la RAM física, i recorda que en multinode el valor es multiplica pel nombre de nodes.

2. Oblidar que --cpus i --memory queden gravats al perfil. Executes minikube start --profile=rutas-norte --memory=8192 un dia, i l'endemà minikube start --profile=rutas-norte sense flags: continua fent servir 8192. Si creus que vas canviar el valor i no va canviar res, és això. Per canviar-ho cal recrear el perfil.

3. ImagePullBackOff amb una imatge que "sí que has construït". Gairebé sempre són dues causes: no vas fer minikube image load / kind load docker-image, o l'etiqueta és latest i l'imagePullPolicy implícit és Always. Fes servir etiquetes explícites (dev-local) i imagePullPolicy: IfNotPresent.

4. Creure que una NetworkPolicy aplicada està funcionant. Comprova sempre el CNI i fes la prova negativa: intenta la connexió que ha d'estar bloquejada i verifica que dona timeout. Sense aquesta prova, no has provat res.

5. Tancar el terminal de minikube tunnel o minikube mount. Tots dos són processos en primer pla. Si desapareix la IP externa o el directori muntat, mira si el procés continua viu abans de buscar causes exòtiques.

6. Descobrir tard que faltava un extraPortMapping a kind. No es poden afegir a un clúster ja creat. Tingues el fitxer de configuració amb els ports 80, 443 i potser algun més des del principi.

7. Fer servir latest de la imatge del node. Tant kindest/node com la versió de minikube han d'estar fixades. Un company amb v1.31 i tu amb v1.29 produïu resultats diferents sobre els mateixos manifestos.

8. Acumular perfils oblidats. Cada perfil aturat continua ocupant disc. minikube profile list de tant en tant i minikube delete --profile=X del que no facis servir.

9. Tractar el clúster local com si fos valuós. Si dubtes que alguna cosa estigui en un estat estrany, esborra'l i recrea'l. L'script de l'apartat 11 fa que això costi tres minuts; investigar un estat corrupte costa una tarda.

10. Provar el rendiment en local. Un benchmark de postgres-reserves al teu SSD no diu res del disc de xarxa de producció. Per a això hi ha rutas-norte-pre i k6 (09-06).

Crea un perfil de minikube anomenat rutas-norte-topologia amb 3 nodes, Kubernetes v1.30.4 i Calico com a CNI. Etiqueta els dos nodes de treball com a zona-a i zona-b. Desplega api-reserves amb 4 rèpliques i un topologySpreadConstraint que reparteixi entre zones amb maxSkew: 1, i comprova amb kubectl get pods -o wide que el repartiment és 2 i 2.

Crea dos clústers de kind: un amb el CNI per defecte (kindnet) i un altre amb disableDefaultCNI: true i Calico instal·lat. En tots dos, aplica una NetworkPolicy de denegació total d'entrada al namespace rutas-norte-dev i comprova, amb un pod busybox intentant connectar a un Service, quin dels dos la respecta de debò.

Amb el perfil rutas-norte en marxa, construeix una imatge registry.rutasnorte.example/botiga-web:dev-local, carrega-la a minikube i desplega-la amb un Ingress per a www.rutasnorte.example. Després, canvia el contingut de la pàgina, reconstrueix amb la mateixa etiqueta, torna a carregar la imatge i aconsegueix que el pod serveixi el contingut nou. Explica per què un simple kubectl apply no n'hi ha prou.

Solució 1

Han de sortir 2 pods a -m02 i 2 a -m03. El node del pla de control no rep pods perquè té el taint corresponent (06-05).

Solució 2

A sense-netpol retorna l'HTML de nginx: la política es va ignorar. A amb-netpol dona timeout: Calico l'aplica.

Solució 3

Per què kubectl apply no n'hi ha prou: el manifest no ha canviat (la mateixa etiqueta d'imatge), així que l'objecte a l'API és idèntic i el Deployment no genera un nou ReplicaSet. rollout restart afegeix una anotació amb la marca de temps a la plantilla del pod, cosa que sí que provoca el desplegament. Aquesta és exactament la raó per la qual en producció es fan servir etiquetes immutables amb digest (08-05): la imatge nova té un identificador nou i el canvi es propaga sol.

Ja saps muntar i destruir clústers locals amb criteri. Els punts que convé endur-se:

• minikube brilla pels seus addons: ingress, metrics-server, storage-provisioner i csi-hostpath-driver t'estalvien instal·lar a mà mitja plataforma. Els perfils permeten tenir diversos clústers alhora, --kubernetes-version iguala el teu entorn a producció, i --nodes obre la porta a provar planificació i topologia.
• kind guanya en velocitat i reproduïbilitat: els nodes són contenidors, tot el clúster es declara en un fitxer versionat amb extraPortMappings i extraMounts, i per això és l'elecció natural de la canalització ci-rutasnorte.
• El bucle de treball amb imatges locals es resol amb minikube image load o kind load docker-image, sempre amb imagePullPolicy: IfNotPresent i etiquetes que no siguin latest.
• I el més important: un clúster local valida correcció, no realisme. No hi ha balancejador de núvol, la StorageClass és una altra, el CNI per defecte pot ignorar les teves NetworkPolicies en silenci, i no hi ha zones ni escalat de nodes. Saber exactament què no estàs provant és el que evita el «a la meva màquina funciona».

Ens queda una pregunta pendent: els clústers locals són joguines controlades, però com es munta un clúster de veritat, en màquines pròpies, sense que ho faci un proveïdor de núvol per tu? A la lliçó següent, Kubeadm, veurem l'eina oficial per arrencar un clúster conforme: preparar les màquines, instal·lar containerd, executar kubeadm init amb un fitxer de configuració, unir nodes, muntar un pla de control en alta disponibilitat, renovar certificats i actualitzar de versió. I descobrirem per què kind, per dins, no és més que kubeadm dins d'un contenidor.