Ja saps què fa Kubernetes, com està construït per dins i què significa cada terme del vocabulari. Tot això ha estat teoria necessària, però Kubernetes no s'aprèn llegint: s'aprèn trencant coses en un clúster propi. Aquesta lliçó té dues parts. Primer, un panorama honest de les opcions reals per aconseguir un clúster —local, autogestionat o gestionat al núvol— amb criteris per triar en un projecte professional. I després, la guia pràctica pas a pas per muntar el clúster de pràctiques que faràs servir durant els dotze mòduls del curs, on desplegarem la plataforma Rutas Norte. En acabar tindràs un entorn funcional, sabràs aturar-lo, reprendre'l i destruir-lo sense por, i coneixeràs les causes de les fallades d'arrencada més habituals.

1. Les tres vies per aconseguir un clúster
2. El clúster de pràctiques del curs: requisits
3. Instal·lació de minikube i del driver
4. Arrencada del clúster amb recursos suficients
5. Addons necessaris per al curs
6. Verificació del clúster
7. Cicle de vida: aturar, reprendre, destruir
8. Alternativa amb kind i clúster multinode
9. Resolució de fallades d'arrencada habituals

Criteris pràctics per decidir:

• Estàs aprenent o desenvolupant? Local. Sense discussió: és gratuït, ràpid de recrear i no t'exposa.
• Tens un equip de plataforma amb guàrdies 24×7? Si la resposta és no, evita autogestionar producció. Mantenir etcd, rotar certificats i actualitzar tres vegades l'any no és una feina petita.
• Hi ha restriccions de sobirania de la dada o maquinari especial? Autogestionat, amb kubeadm o una distribució comercial.
• Producció normal d'una empresa normal? Gestionat. Rutas Norte acabarà aquí: el pla de control és un problema del proveïdor i l'equip es concentra en la plataforma.

Cada via té la seva lliçó pròpia més endavant: Minikube i Entorns Locals amb kind, Kubeadm i Kubernetes Gestionat: EKS, AKS i GKE. Aquí només muntem el necessari per tenir entorn de treball.

Triem minikube com a opció principal perquè porta de sèrie, mitjançant addons, dues coses que necessitarem molt: un Ingress Controller (mòdul 4) i un aprovisionador d'emmagatzematge dinàmic (mòdul 5). Instal·lar-les a mà en altres eines és feina extra que no aporta aprenentatge en aquest punt. Donem també la recepta equivalent amb kind, que és més lleuger i permet clústers multinode amb facilitat.

Rutas Norte acabarà amb sis components desplegats alhora més els complements d'observabilitat, així que convé no quedar-se curt de recursos.

També necessites kubectl, la instal·lació i l'ús del qual es cobreixen en detall a la lliçó següent, La CLI de Kubernetes: kubectl. Si encara no el tens, minikube pot executar-lo per tu amb minikube kubectl -- <ordre>, encara que el normal és instal·lar-lo a part.

minikube crea el clúster dins d'alguna cosa: un contenidor o una màquina virtual. Aquest "alguna cosa" és el driver.

Farem servir docker. Comprova que el tens i que el teu usuari el pot fer servir sense sudo:

Si la segona ordre falla amb permission denied, afegeix el teu usuari al grup docker i torna a iniciar sessió:

Linux (x86_64):

macOS (amb Homebrew):

Windows (amb winget, a PowerShell):

Verifica la instal·lació:

Aquesta és l'ordre que defineix el teu entorn de treball per a tot el curs:

Què fa cada opció, i per què:

Sortida esperada (abreujada):

Dos detalls importants d'aquesta sortida:

• L'última línia indica que minikube ha modificat el teu kubeconfig i ha creat i activat un context anomenat rutas-norte. Això és el que fa que kubectl parli amb aquest clúster.
• Ja s'han habilitat dos addons per defecte: default-storageclass i storage-provisioner. Són els que ens permetran demanar volums persistents al mòdul 5 sense infraestructura real.

Si la teva màquina té menys recursos, arrenca amb --cpus=2 --memory=4096 i tingues-ho present: al mòdul 7 hauràs d'apagar components per fer lloc.

Els addons són components preempaquetats que minikube instal·la al clúster. Habilita aquests tres des d'ara:

Comprova que el controlador d'Ingress ha arrencat abans de continuar:

Els dos pods en Completed no són cap error: són Jobs d'instal·lació que ja han acabat la seva feina (recorda de la lliçó anterior que un Job acaba, no es queda corrent). L'important és el tercer, en Running i 1/1.

Tres comprovacions que convé fer sempre després de crear un clúster.

1. El node està llest:

El rellevant: STATUS: Ready (el kubelet reporta i el plugin de xarxa funciona) i ROLES: control-plane (a minikube el mateix node fa de pla de control i de treballador, cosa que en producció no passaria mai).

2. Els components del sistema estan sans:

Reconeix aquesta llista: són exactament els components de la lliçó Arquitectura de Kubernetes, ara corrent de debò a la teva màquina. Fixa't que a minikube el pla de control s'executa com a pods dins del mateix clúster (static pods gestionats pel kubelet), i que apareix coredns, el servidor DNS intern que estudiarem al mòdul 4.

3. L'API respon i saps a quin clúster parles:

Si les tres comprovacions passen, tens un clúster operatiu.

Un clúster local consumeix recursos encara que no el facis servir. Aquestes són les quatre ordres que necessites:

Consell de mètode: que minikube delete no et faci por és precisament l'objectiu. Si tots els teus manifests estan versionats al directori k8s/ del repositori —com farem des de la lliçó 01-07— recrear el clúster i tornar-los a aplicar t'hauria de costar cinc minuts. Si et fa por esborrar-lo, és senyal que hi ha estat important que no és a Git.

També et resultarà útil:

kind (Kubernetes IN Docker) crea cada node com un contenidor Docker. És més lleuger que minikube i el seu gran avantatge és la facilitat per muntar un clúster multinode, cosa que t'anirà bé quan estudiem planificació i afinitat (mòdul 6). El seu desavantatge: no porta addons, així que Ingress i emmagatzematge requereixen passos extra.

Instal·lació a Linux:

Fitxer de configuració amb un node de control i dos treballadors, preparat a més per a Ingress:

Explicació de les parts que importen:

• nodes: cada entrada és un contenidor Docker que actuarà com a node. Aquí en tindrem tres.
• extraPortMappings: sense això, el port 80 del clúster no seria accessible des del teu navegador. És l'equivalent al minikube tunnel.
• labels als workers: etiquetes de node que farem servir per practicar afinitat i antiafinitat al mòdul 6, simulant dues zones de disponibilitat.

Creació i verificació:

Instal·lar l'Ingress Controller (kind no el porta) i esborrar el clúster quan ja no calgui:

Què triar: si dubtes, minikube. Fes servir kind quan necessitis diversos nodes o quan muntis Kubernetes dins d'una canalització d'integració contínua, on la seva rapidesa de creació és decisiva.

Ordres de diagnòstic de propòsit general quan alguna cosa va malament a l'arrencada:

La tercera és especialment valuosa i la farem servir molt: els esdeveniments són el diari del clúster i gairebé sempre contenen l'explicació en text pla de per què alguna cosa no ha funcionat.

• Arrencar amb els valors per defecte (2 CPU, 2 GiB). Funciona per als primers mòduls i es queda curt tan bon punt hi afegeixis observabilitat. És millor dimensionar bé des del principi que recrear el clúster a mig curs.
• No fer servir --profile. Si treballes amb diversos clústers locals, el perfil per defecte es converteix en una font de confusió: acabes aplicant manifests al clúster equivocat. Anomenar el perfil rutas-norte deixa sempre clar on ets.
• Canviar la versió de Kubernetes entre sessions. Si un dia arrenques amb 1.30 i un altre sense fixar versió, canvien comportaments i APIs. Fixa la versió a l'ordre i anota-la al repositori.
• Confondre "el clúster ha arrencat" amb "el clúster està llest". minikube start retorna abans que els addons estiguin operatius. Comprova sempre amb kubectl get pods -A que no hi ha res en Pending o ContainerCreating.
• Esperar que un Service de tipus LoadBalancer obtingui IP externa. En local no hi ha cloud-controller-manager (ho vam veure a 01-02): es queda en <pending>. Es resol amb minikube tunnel, i ho tractarem al mòdul 4.
• Deixar el clúster corrent permanentment. Consumeix CPU i bateria. minikube stop en acabar la sessió conserva absolutament tot.
• Consell: desa la teva ordre de creació de clúster al mateix repositori (per exemple, a k8s/entorn-local/README o un script crear-cluster.sh). Forma part de la documentació del projecte tant com els manifests.

Munta el clúster de pràctiques amb el perfil rutas-norte, 4 CPU, 8 GiB i Kubernetes 1.30, habilita els addons ingress i metrics-server, i respon:

1. Quants nodes té i quin rol tenen?
2. Quants pods hi ha al namespace kube-system i quins es corresponen amb components del pla de control que vas estudiar a la lliçó 01-02?
3. Quina és la IP del node?
4. Quin context de kubectl està actiu?

Crea el namespace de desenvolupament del projecte, atura el clúster, reprèn-lo i comprova si el namespace continua existint:

Explica per què el resultat és el que és, esmentant on es desa aquest objecte. Després, indica quina ordre faria desaparèixer aquest namespace juntament amb tota la resta.

Crea amb kind un clúster anomenat rutas-norte-multi amb un node de control i dos treballadors etiquetats com a zona: nord i zona: sud. Comprova que els tres nodes estan Ready i mostra únicament els nodes de la zona nord. Explica en dues línies per què aquest clúster et serà útil al mòdul 6 i per què no el fem servir com a entorn principal del curs.

Solució 1

1. Un sol node, amb rol control-plane. A minikube aquest mateix node executa també les càrregues d'usuari, cosa que en producció no es fa: el pla de control es reserva mitjançant taints.
2. Al voltant de vuit pods. Es corresponen amb l'arquitectura: etcd, kube-apiserver, kube-scheduler, kube-controller-manager (pla de control), kube-proxy (node), més coredns (DNS intern), storage-provisioner i metrics-server. No apareix cloud-controller-manager perquè no hi ha proveïdor de núvol.
3. minikube ip --profile=rutas-norte → típicament 192.168.49.2.
4. kubectl config current-context → rutas-norte.

Solució 2

El namespace continua existint després de stop i start. La raó és que stop no destrueix res: apaga el contenidor o la VM del node conservant-ne el disc, i en aquest disc hi ha etcd, que és on viu l'objecte Namespace. En reprendre, l'apiserver torna a llegir de la mateixa etcd i tot l'estat declarat reapareix.

L'ordre que sí que ho destruiria tot és minikube delete --profile=rutas-norte, que elimina el node i el seu disc, etcd inclosa. Per això els manifests han de viure a Git: recrear el clúster és aleshores un tràmit.

Solució 3

Serà útil al mòdul 6 perquè l'afinitat, l'antiafinitat, els taints i la dispersió per topologia només es poden practicar de debò amb diversos nodes: en un clúster d'un sol node el scheduler no té cap decisió a prendre. No el fem servir com a entorn principal perquè kind no inclou addons: caldria instal·lar a mà l'Ingress Controller i un aprovisionador d'emmagatzematge, feina que en aquest punt del curs distreu de l'objectiu.

Ja tens un clúster de Kubernetes funcionant a la teva màquina, amb el perfil rutas-norte, la versió 1.30 fixada, recursos suficients per a tot el curs i els addons d'Ingress, mètriques i emmagatzematge dinàmic habilitats. Has vist també el panorama complet d'opcions —local, autogestionat amb kubeadm, gestionat al núvol— i els criteris per triar-ne una o una altra en un projecte real, a més d'una alternativa multinode amb kind per quan arribem a la planificació. I, sobretot, saps aturar-lo, reprendre'l i destruir-lo sense por, perquè la veritat operativa del curs és que el clúster és reemplaçable i els manifests no.

Tens l'entorn, però tot just has fet servir l'eina amb què hi parlaràs. A la lliçó següent, La CLI de Kubernetes: kubectl, dominarem kubectl a fons: el fitxer kubeconfig i els contextos, els verbs que faràs servir cada dia, els formats de sortida, la selecció per etiquetes i els trucs de productivitat que marquen la diferència entre barallar-se amb el clúster i treballar amb desimboltura.