Com muntar un entorn local de proves Kubernetes amb k3s, kind o minikube: avantatges i limitacions

Muntar un entorn local de Kubernetes per a proves i desenvolupament no és tan trivial com sembla en la documentació oficial. L’habitual és que un comenci amb qualsevol de les opcions més conegudes —k3s, kind o minikube— i, al cap d’uns dies, comencin a sortir les esquerdes: colls d’ampolla en el rendiment, problemes amb volums persistents, diferències de comportament respecte a entorns reals, o simplement una pèrdua de temps cada vegada que es necessita reiniciar tot per alguna configuració mal entesa.

A continuació, es revisen aquestes tres eines, no des de la teoria sinó des de l’experiència pràctica: quan convé cadascuna, quins problemes poden donar, quines dreceres estalvien temps i quines decisions convé evitar, fins i tot si semblen “l’estàndard”.

1. k3s: Kubernetes lleuger, però amb lletra petita

Avantatges reals

k3s té molt sentit quan es busca un entorn local més proper a producció quant a arquitectura (sense dependre de Docker-in-Docker, com kind), però amb menys sobrecàrrega que un cluster complet amb kubeadm. En estar empaquetat en un binari únic, es redueix el nombre de peces soltes. I no depèn de la informació, cosa que simplifica bastant en entorns no convencionals (WSL, Alpine, etc.).

Un avantatge concret: permet córrer control plane i workloads en el mateix node sense conflictes notables, una cosa que en minikube de vegades acaba malament si s’activen massa addons.

On comencen els problemes

Tot i que es ven com a “lleuger”, no significa “mínim”. A partir de cert nombre de pods concurrents (~50-60 en un node amb 4 CPU), k3s comença a mostrar limitacions en el scheduler i al consum de memòria de l’agent local. En proves amb CI locals, això es tradueix en colls d’ampolla si s’executen tests end-to-end en paral·lel.

El suport de storage class és enganyosament simple. Per defecte, k3s inclou local-path com a classe d’emmagatzematge, però té un comportament molt limitat: no és dinàmic en sentit real i tendeix a deixar escombraries en disc si es fan proves amb volums persistents (PVC) que es creen i destrueixen freqüentment. S’acumulen directoris sota /opt/local-path-provisioner sense neteja automàtica, la qual cosa porta a errors en tests posteriors si els PV queden penjats.

Decisió clau

Desactivar el trafik embegut des del començament (–dissable traefik) és gairebé obligatori si es té previst provar Ingress Controllers de forma explícita. Deixar-lo activat per inèrcia genera conflictes: redireccions inesperades, ports ja ocupats i un cluster que “funciona”, però amb comportaments erràtics.

Configuracions que ajuden

• Instal·lar-lo via k3d (el wrapper Docker-based de k3s) per mantenir entorns aïllats reproduïbles. Permet destruir i recrear clusters en segons sense tocar res del host.
• Desactivar el servidor de metrics si no es necessita (–dissable metrics-server), per reduir consum de CPU en màquines amb pocs recursos.
• Mapejar directoris del host com a volums persistents en desenvolupament local. No usar volums en /tmp, perquè en reiniciar el node es poden perdre dades sense avís.

2. kind: fidelitat al control plane, amb restriccions pràctiques

Avantatges reals

kind (Kubernetes IN Docker) es va dissenyar per a testejar Kubernetes, no per desenvolupar sobre ell. Això fa que tingui un avantatge estructural: el cluster té un comportament molt predictible. És perfecte si es vol reproduir escenaris que depenen del control plane, com tests d’operadors, validacions de CRDs o experimentació amb els controls. Tot això sense desviacions “màgiques” de la distribució, com passa amb minikube o k3s.

Funciona bé en CI/CD, sobretot en runners amb privilegis reduïts. És fàcil aixecar un cluster a GitHub Actions amb kind i Docker sense instal·lar res al host.

Problemes pràctics

És lent. No perquè consumeixi molt, sinó perquè tot passa per Docker-in-Docker. Els I/O són especialment pesats quan es tracta de volums persistents. Si es munta un PV backed per un hostPath simulat, les escriptures van a través de capes d’overlayfs, cosa que en proves de bases de dades o sistemes amb molts writes (Redis, Mongo, etc.) genera latències enganyoses. Es perd completament la referència respecte a producció.

A més, el networking és limitat. No hi ha un CNI real. Si es fan proves que depenen de polítiques de xarxa (network policies, DNS intern, etc.), kind no és fiable: les coses funcionen fins i tot quan no haurien de fer.

Errors comuns

• Assumir que es poden exposar serveis LoadBalancer sense més. kind no té integració nativa per a això. Cal fer servir port-forwarding o configurar un Ingress manualment.
• Fer servir imatges locals sense carregar-les explícitament al cluster. kind load docker-image és obligatori; en cas contrari, els pods fallen sense logs clars perquè el node no té accés al host registry.
• Aixecar múltiples nodes i esperar comportament realista de schedulers. Els workers són containers també, i el temps que tarden a arrencar dona lloc a errors de sincronització que no ocorren en clusters reals.

Per evitar inconsistències, convé definir sempre els clusters kind amb un kind-config.yaml explícit. Evita sorpreses com ports que no estan oberts, storage que no persisteix entre reinicis o noms de nodes que canvien entre execucions.

3. minikube: flexibilitat total, a costa de manteniment

Punts forts

minikube té un ventall ampli de possibilitats: es pot aixecar amb Docker, amb virtualbox, amb KVM, amb Hyperkit… i això és tant un avantatge com una font de caos. Si es tria bé el driver, pot donar una experiència propera a un entorn bare-metal. Per exemple, amb –driver=none, corre directament sobre el sistema operatiu i ofereix un rendiment acceptable en I/O. També té un sistema força complet d’ addons que permeten simular entorns més complexos: Ingress, metrics-server, dashboard, CSI, etc.

Una característica útil: permet fer minikube mount per mapejar directoris de l’host directament, sense passar per volums. Per a desenvolupament actiu, això estalvia temps si es recompilen imatges freqüentment o es munten carpetes locals com a font de configuració.

Problemes

El sistema d’addons és fràgil. S’activen fàcil, però s’espatllen fàcil també. El dashboard, el metrics-server i l’espai de nginx tenen dependències internes que no sempre queden netes en fer un minikube delete. Queden pods penjant, configmaps duplicats, o ports en conflicte en reinicis posteriors.

Un altre problema comú: el DNS intern pot fallar si la configuració de xarxa de l’host canvia. Això passa molt en fer servir VPNs o proxies corporatius. Quan coredns comença a resoldre amb latència, les aplicacions dins del cluster fallen amb timeouts difícils de rastrejar. Reiniciar minikube no sempre ho arregla; cal resetejar la configuració de xarxa completa (minikube stop && minikube delete && minikube start –clean-config).

Errors per inèrcia

• Triar VirtualBox com a driver per costum. Al 2025, és innecessari en gairebé tots els casos. Docker o KVM són més ràpids i menys propensos a conflictes amb firewalls o configuracions de xarxa d’ empresa.
• Deixar tots els addons actius. En entorns de prova, cada addon és una font potencial de bugs laterals. El recomanable és activar-los un a un, i només quan es provi una cosa que ho requereixi explícitament.
• Assumir que els canvis sobreviuen entre reinicis. El driver Docker, en particular, perd configuracions de xarxa, volums i certificats amb facilitat.

Configuracions que estalvien temps

• Fer servir minikube cache add <imatge> per evitar pulls repetits en clusters efímers.
• Activar minikube tunnel només quan es necessiten serveis LoadBalancer reals, però no deixar-ho corrent. Consumeix recursos fins i tot sense trànsit i genera conflictes amb serveis al port 443 del host.
• Establir perfils (–profile) per separar entorns: desenvolupament, testing, proves amb storage, etc. És més net que reciclar un únic cluster i perdre reproducibilitat.

Comparativa directa: quan triar cadascú?

No hi ha una resposta única, però es poden traçar línies clares segons el cas d’ ús i el context tècnic.

Criteri tècnic	kind	k3s / k3d	minikube
Testeig d’ operadors, CRDs, control plane personalitzat	Molt fiable	Algunes desviacions	Massa capes
Entorns amb recursos limitats (portàtils, WSL, etc.)	Pesat per Docker-in-Docker	Molt lleuger	Depèn del driver
Reproducció d’ entorns reals amb CNI i PVCs	Limitat	Acceptable si s’ afina	Configurable, però fràgil
Volums persistents per a bases de dades en proves	Mal rendiment I/O	Només si es controla neteja	Millor amb –driver=none o KVM
Ús intensiu en CI/CD local	Excel·lent en runners	Bon equilibri	Lent, alt manteniment
Exposició realista de serveis (LoadBalancer, Ingress)	Requereix configuració manual	Funciona bé amb Metallb	Bon suport, però addons fràgils

Pràctiques que eviten pèrdues de temps (independentment de l’entorn)

Al marge de l’eina escollida, hi ha certs patrons que convé repetir sempre per evitar problemes típics en entorns locals Kubernetes.

1. Fer servir imatges locals amb etiquetes versionades

No convé fer servir :latest ni etiquetes genèriques. Encara que el tag estigui ben definit al Dockerfile, la majoria d’entorns (especialment kind) necessiten que es carregui explícitament en el cluster. kind load docker-image my-app:dev-20250730 garanteix que aquesta versió està disponible i no es resol des d’un registry extern.

2. Desplegar els mateixos manifests que a staging

Encara que sembli redundant, desplegar en local els mateixos YAMLs (o Helm charts) que a staging redueix la distància operativa. Molts problemes sorgeixen per tenir manifestos simplificats “només per a local” que després divergeixen. Si alguna cosa requereix sobreescriptura (com StorageClass o tolerations), millor fer servir kustomize o overlays dedicats.

3. Netejar volums i xarxes en destruir

Esborrar un cluster no significa alliberar-ho tot. En minikube, els volums persistents continuen ocupant espai fins que es destrueix el driver o es netegen els discos virtuals manualment. En k3d, els contenidors Docker de vegades es queden aturats però no esborrats. És bona pràctica incloure una neteja explícita (docker system prune –volumes) en entorns efímers.

4. Monitorització simple amb eines conegudes

Instal·lar Prometheus, Loki o Grafana en local pot semblar exagerat, però tenir encara que sigui mètriques bàsiques visibles en proves complexes (com reconciliacions lentes o problemes de xarxa) permet distingir entre “l’app està malament” i “l’entorn s’està ofegant”. Si no es vol instrumentar tot, almenys fer servir kubectl top i stern per a seguir logs agrupats per label.

Consideracions no tècniques, però inevitables

Suport d’ equip

No tothom té les mateixes capacitats locals. Si l’equip és mixt (Linux, macOS, Windows), kind i k3d tenen millor portabilitat. minikube amb VirtualBox pot ser l’origen de molts bugs compartits. En aquests casos, fer servir Docker com a driver comú és més sostenible.

Ús en remot

Algunes proves requereixen integració amb serveis externs (OAuth, APIs privades, etc.). minikube té l’avantatge de permetre minikube tunnel per simular LoadBalancers reals, mentre que en kind cal muntar proxies o fer servir eines com ngrok. Si es necessiten proves reals amb callbacks o webhooks, això és determinant.

Compatibilitat amb eines de tercers

Certes plataformes (com Skaffold, Tilt o Garden) tenen integracions més completes amb minikube o k3d que amb kind. Si es fa servir alguna d’aquestes eines com a part del flux de desenvolupament, convé validar primer amb quin entorn treballen millor, o es perdran hores en configuracions que “gairebé” funcionen.

Conclusió

Cap de les tres opcions és clarament superior. L’entorn correcte depèn del que s’ha de provar, amb quina freqüència, en quines condicions i amb quin pressupost de temps. El que sí que es pot afirmar és que:

• kind és excel·lent per a clústers d’un sol ús, reproduïbles i CI/CD sense acoblaments amb el host.
• k3s (especialment via k3d) és útil quan es busca un clúster lleuger però més proper al comportament real.
• minikube continua tenint sentit si es necessita flexibilitat, accés directe al host i simulació raonable de features de cloud.

Triar bé significa evitar dies perduts ajustant configuracions que no encaixen. I, sobretot, tenir clar què es vol provar abans de llençar el primer start. Si l’entorn s’assembla al de producció, els bugs apareixen abans. Si se simula malament, apareixen després i amb menys context. Aquesta diferència pesa molt més que 500MB de RAM o uns segons d’arrencada.