¿Cuál es la mejor distribución de Kubernetes para un homelab?

La mejor distribución de Kubernetes para un homelab son K3s o MicroK8s.

Comparación de distribuciones de Kubernetes para un homelab de 3 nodos

Elegir la mejor variante de Kubernetes para nuestro homelab

Índice

Estoy comparando variantes de Kubernetes autohospedadas que se adaptan a un homelab basado en Ubuntu con 3 nodos (16 GB de RAM, 4 núcleos cada uno), centrándome en la facilidad de instalación y mantenimiento, soporte para volúmenes persistentes y LoadBalancers.

Escenario: Tenemos tres nodos Ubuntu (16 GB de RAM, 4 núcleos de CPU cada uno) en un homelab. La alta disponibilidad (HA) y el soporte para CPU ARM no son prioridades. Queremos un clúster de Kubernetes fácil de instalar y de bajo mantenimiento (ya sea de un solo nodo o de 3 nodos) con soporte para volúmenes persistentes (PV) y LoadBalancer (LB) (para que las aplicaciones nativas en la nube que requieren almacenamiento o direcciones IP externas funcionen de forma fluida). Nos centraremos en opciones de clúster de 3 nodos sin requisitos de HA o compatibilidad con CPU ARM.

kubernetes homelab

A continuación, comparamos distribuciones de Kubernetes ligeras populares – K3s, MicroK8s, Minikube, y kubeadm (Kubernetes puro) – y cómo se comparan en los criterios clave (funcionalidades, instalación/mantenimiento, soporte para PV/LB, requisitos de recursos, configuración del clúster y herramientas). También daremos algunas recomendaciones sobre qué elegir según el escenario del homelab.

K3s (Kubernetes ligero de Rancher)

Funciones clave: K3s es una distribución de Kubernetes certificada por CNCF diseñada para un uso mínimo de recursos (puede funcionar con tan solo 512 MB de RAM). Empaqueta toda la plataforma de control de Kubernetes en un solo binario y proceso, usando componentes ligeros (por ejemplo, almacén de datos SQLite por defecto en lugar de etcd, flannel para la red). Incluye configuraciones predeterminadas como un controlador de entrada integrado (Traefik) y un balanceador de carga simple. K3s elimina características legadas/alpha para reducir el volumen.

Facilidad de instalación y mantenimiento: Muy sencillo - podemos instalarlo con un script de una línea (curl ... | sh) o mediante herramientas como K3sup. El servidor se inicia con componentes predeterminados de forma inmediata. Añadir nodos es sencillo (ejecutar el agente de K3s con un token del servidor). Las actualizaciones son fáciles (reemplazar el binario o usar el script de instalación para una nueva versión). No se requiere una configuración separada de etcd (a menos que elijamos un entorno HA multi-maestro). K3s está diseñado para requerir un mínimo de ajustes una vez instalado, lo que lo hace popular en IoT y homelabs.
Soporte para volúmenes persistentes: Integrado. Por defecto, K3s incluye la clase de almacenamiento local-path de Rancher, que proporciona PVs dinámicamente en el sistema de archivos del host para cada PVC. Esto significa que cualquier PVC se cumplirá automáticamente creando un volumen hostPath en el nodo. Es una solución de almacenamiento de un solo nodo (cada volumen está en el disco de un nodo), pero funciona de forma inmediata para aplicaciones estatales. Para almacenamiento más avanzado, podemos agregar algo como Longhorn de Rancher (almacenamiento en bloques distribuido), que K3s soporta, pero para un homelab, el proveedor local-path predeterminado suele ser suficiente.
Soporte para LoadBalancer: Integrado. K3s incluye un controlador ligero llamado ServiceLB (anteriormente “Klipper LB”) que permite a los servicios de tipo LoadBalancer obtener una IP/puerto en el host sin necesidad de un proveedor en la nube externo. Cuando creamos un servicio LoadBalancer, K3s despliega un DaemonSet de pequeños pods de LB (svc-...) en cada nodo, que usan puertos del host para reenviar el tráfico al servicio. En esencia, K3s reutiliza la IP del nodo (interna o externa) para servir como IP del LB y usa rutas de iptables en los pods del LB para enviar el tráfico al ClusterIP del servicio. Esto funciona sin configuración – los servicios no se quedarán “pendientes” (a diferencia del Kubernetes puro en hardware bare metal). El intercambio es que la IP externa del LB será una de nuestras IPs de nodo (o todas las IPs de los nodos) y debemos asegurarnos de que el puerto esté libre. Para la mayoría de los usos en un homelab (exponer unos pocos servicios en puertos HTTP/HTTPS), esto es perfectamente aceptable. Si es necesario, podemos deshabilitar el LB integrado e instalar MetalLB manualmente, pero la mayoría de los usuarios se quedan con el conveniente predeterminado.
Requisitos de recursos: Muy bajos. K3s puede funcionar incluso en hardware de baja gama. Oficialmente, 512 MB de RAM y unos pocos cientos de MB de disco son suficientes para un nodo servidor. En la práctica, un pequeño clúster podría usar unos pocos cientos de MB de memoria para la plataforma de control. Su binario es <100 MB. El sobrecoste de CPU es mínimo (K3s usa un poco más de CPU cuando está inactivo en comparación con MicroK8s, pero no por una gran diferencia). Nuestros nodos (16 GB cada uno) son más que suficientes para ejecutar K3s cómodamente.
Un solo nodo vs. múltiples nodos: Adecuado para ambos. K3s puede funcionar en un solo nodo (todo el plano de control y cargas de trabajo en una sola máquina) o en múltiples nodos. Para una configuración de 3 nodos, podríamos ejecutar 1 servidor (maestro) y 2 agentes, o incluso hacer que los 3 sean servidores para HA (no es necesario aquí ya que la HA no es un objetivo). Unir agentes es trivial con el token. El almacén de datos predeterminado de SQLite de K3s funciona para un solo servidor; para HA con múltiples servidores, cambiaríamos a etcd integrado (K3s puede hacerlo automáticamente cuando se inician múltiples nodos de servidor).
Herramientas CLI y UI: Interactuamos con K3s igual que con cualquier Kubernetes – mediante kubectl. K3s incluye su propia construcción de kubectl (podemos ejecutar k3s kubectl ... o simplemente usar un kubectl estándar apuntando a la kubeconfig de K3s). No hay una CLI específica de K3s más allá de los comandos de instalación; está diseñado intencionalmente de forma minimalista. No se incluye una interfaz web integrada (el Dashboard upstream no se instala por defecto). Sin embargo, podemos desplegar manualmente el Dashboard de Kubernetes u otras herramientas en K3s como en cualquier clúster estándar. Rancher (la herramienta de gestión GUI por la misma empresa) también puede instalarse sobre K3s si se desea una interfaz completa, pero no forma parte de K3s en sí. En esencia, K3s proporciona las APIs de k8s básicas y añadimos extras según sea necesario (ingreso, almacenamiento, etc. – algunos de los cuales ya están empaquetados como se mencionó).

MicroK8s (Kubernetes de bajo mantenimiento de Canonical)

Funciones clave: MicroK8s es la distribución ligera de Kubernetes de Canonical, entregada como un paquete snap. Instala un clúster de Kubernetes completamente conforme (binarios upstream) con un solo comando y está diseñado para un uso fácil (“bajo mantenimiento”) en una sola máquina o clúster pequeño. Destaca por un enfoque de “baterías incluidas” – obtenemos muchas funciones opcionales que se pueden habilitar con comandos simples. MicroK8s se predispone a una experiencia de Kubernetes puro (todos los APIs estándar) pero con complementos convenientes para necesidades comunes. Soporta tanto despliegues de un solo nodo como múltiples nodos (podemos formar un clúster al “unir” nodos), e incluso tiene un modo HA para el plano de control (usando Dqlite – un SQLite distribuido – cuando tenemos 3 maestros).

Facilidad de instalación y mantenimiento: Muy fácil también – simplemente snap install microk8s --classic en una máquina Ubuntu configurará un nodo de Kubernetes. Es un solo paquete que incluye todos los componentes. MicroK8s se mantiene mediante el sistema de snap de Ubuntu, lo que significa que las actualizaciones son atómicas y pueden ser automáticas (podemos seguir un canal para versiones de Kubernetes). Esta capacidad de actualización automática es única entre estas opciones – podemos optar por recibir parches de seguridad y actualizaciones menores mediante actualizaciones de snap. El manejo de MicroK8s se hace mediante el comando microk8s, que tiene subcomandos para habilitar/deshabilitar funciones. En general, es muy sencillo: no hay contenedores ni VMs que gestionar (se ejecuta nativamente en el host), y no hay etcd externo que configurar (usa un almacén de datos interno). El mantenimiento es principalmente actualizar el snap cuando sea necesario y usar microk8s.status para monitorear.
Soporte para volúmenes persistentes: Disponible mediante complemento. Por defecto, MicroK8s no provisiona PVs automáticamente hasta que habilitamos el complemento “hostpath-storage”. Al habilitarlo (con microk8s enable hostpath-storage) se crea una clase de almacenamiento predeterminada que asigna volúmenes desde un directorio en el host. Esto es esencialmente un proveedor dinámico de hostPath, similar en concepto al local-path de K3s. Una vez habilitado, cualquier PVC se vinculará a un PV de hostpath en el nodo de MicroK8s. (En un clúster de MicroK8s con múltiples nodos, el PV de hostpath residirá en un solo nodo – adecuado para pruebas o uso en homelab pero no para almacenamiento distribuido). MicroK8s también ofrece Mayastor y otros complementos de almacenamiento si queremos almacenamiento más avanzado en múltiples nodos, pero para simplicidad el almacenamiento de hostpath funciona bien. Nota: El complemento no está habilitado por defecto (para mantenerlo ligero), así que querremos habilitarlo para que los PVCs funcionen. Canonical señala que esto no es para uso en producción HA (ya que no está replicado), pero para un homelab es perfecto.
Soporte para LoadBalancer: Disponible mediante complemento. MicroK8s no incluye un balanceador de carga predeterminado, pero proporciona MetalLB como un complemento fácil de usar. Ejecutando microk8s enable metallb:<start-IP>-<end-IP> se despliega MetalLB en modo Layer 2 y nos permite especificar una piscina de IPs de nuestra LAN para usar con servicios LoadBalancer. Una vez habilitado, cualquier servicio de tipo LoadBalancer obtendrá automáticamente una IP de ese rango (y MicroK8s la anunciará mediante ARP en la LAN). Esto da una experiencia en la nube en hardware bare metal. (Si no habilitamos MetalLB, un servicio LoadBalancer permanecerá pendiente, ya que MicroK8s por sí solo no implementa uno – igual que Kubernetes upstream.) En un homelab, MetalLB es sencillo y nos permite acceder a servicios en nuestra red local. Necesitaremos elegir una subred o rango de IPs libre en nuestra red para ello. El comando de habilitación de MicroK8s hace que la configuración sea sencilla, pero sigue siendo un paso separado. (En contraste, K3s funciona de forma inmediata para LB pero con la limitación de usar IPs/puertos de nodo.) Muchos usuarios de MicroK8s simplemente habilitan MetalLB como parte de su configuración inicial para un LB funcional.
Requisitos de recursos: MicroK8s es bastante ligero, aunque ligeramente más grande que K3s. Ejecuta todos los servicios principales (servidor API, controlador, programador, kubelet, etcd o Dqlite) nativamente. El uso en estado inactivo suele ser de ~500–600 MB de RAM para la plataforma de control, dependiendo de qué complementos estén habilitados. Canonical menciona un uso de memoria de ~540 MB como base. El uso de CPU es bajo en estado inactivo, y nuestros nodos de 16 GB tienen más que suficiente margen. El requisito de espacio en disco es pequeño (snap ~ 200 MB más datos de etcd). En resumen, MicroK8s puede ejecutarse en hardware modesto (incluso se ofrece para Raspberry Pis), y en nuestro escenario las máquinas lo acomodan con facilidad. Si se habilitan varios complementos (dashboard, monitoreo, etc.), el uso de recursos aumentará en consecuencia.
Un solo nodo vs. múltiples nodos: MicroK8s funciona bien para ambos. Podemos usarlo para un clúster de un solo nodo (por ejemplo, en una máquina de desarrollo o un solo servidor) o crear un clúster de múltiples nodos al “unir” nodos. La documentación de MicroK8s proporciona un comando para agregar un nodo (obtenemos un token de unión del primer nodo y lo usamos en los demás). En una configuración de múltiples nodos sin HA, un nodo será el plano de control principal. Con 3 nodos, también tenemos la opción de habilitar el modo ha-cluster (haciendo el plano de control HA al ejecutar Dqlite en 3 nodos), aunque en nuestro caso no se necesita HA. Ya sea un solo nodo o tres nodos, la experiencia es la misma API de Kubernetes. El MicroK8s de múltiples nodos es un poco más nuevo que el enfoque de K3s, pero ahora es bastante estable. Es una buena opción si queremos una “nube micro” de unas pocas máquinas Ubuntu ejecutando k8s con poco esfuerzo.
Herramientas CLI y UI: MicroK8s viene con la herramienta de línea de comandos microk8s, que es muy útil. Por ejemplo, microk8s enable <addon> activa/desactiva varios servicios (DNS, ingreso, almacenamiento, metallb, dashboard, etc.), y microk8s status muestra qué está en ejecución. También incluye un kubectl integrado: podemos usar microk8s kubectl ... (o aliasarlo), que se comunica con el clúster – esto es útil porque no necesitamos configurar un kubeconfig. Para la UI, MicroK8s proporciona el Kubernetes Dashboard como complemento (microk8s enable dashboard), que desplegará la interfaz web estándar. Una vez habilitado, podemos acceder a él (funciona en el puerto 10443 o mediante proxy). MicroK8s no tiene una GUI propia – depende del Dashboard de Kubernetes u otras herramientas – pero la facilidad de habilitarlo es un plus. En resumen, MicroK8s enfatiza una experiencia de un solo comando para tareas comunes y una filosofía de “funciona de inmediato”, abstrayendo mucha complejidad (a costa de ocultar algunos internos). Esto lo hace muy amigable para homelabs para quienes quieren un clúster de Kubernetes sin la configuración manual de cada componente.

Contraste entre K3s y MicroK8s: Ambos son bastante similares en objetivos y capacidades – ligeros, fáciles de usar, capaces de múltiples nodos. K3s tiende a ser un poco más “DIY” al agregar extras (dependiendo de gráficos Helm o manifiestos manuales para lo que no se incluye), mientras que MicroK8s ofrece complementos integrados mediante su CLI. MicroK8s también es un Kubernetes más “puro” bajo el capó (componentes upstream, simplemente empaquetados como snap), mientras que K3s usa algunos binarios personalizados y un solo servicio para todo. Ambos son buenas opciones para un homelab; la decisión suele depender de preferencias: si Ubuntu/snaps y una sensación integrada son preferibles, MicroK8s es excelente, mientras que si preferimos un enfoque minimalista con un poco más de control manual, K3s es excelente. (Proporcionaremos recomendaciones al final.)

Minikube (K8s local de un solo nodo)

Funciones clave: Minikube es principalmente una herramienta para ejecutar Kubernetes localmente (a menudo en una PC o laptop de un desarrollador) en lugar de un clúster tradicional en múltiples máquinas. Crea un clúster de Kubernetes de un solo nodo en una VM o contenedor en nuestra máquina. Minikube es conocido por su amplio soporte de entornos – puede ejecutarse en Linux, macOS, Windows y soporta varios hipervisores (VirtualBox, KVM, Hyper-V, driver de Docker, etc.). Está mantenido por los SIGs de Kubernetes y se usa comúnmente para pruebas y aprendizaje. Aunque Minikube puede forzarse a una configuración de múltiples nodos, está diseñado principalmente para clústeres de un solo nodo (el modo “multi-nodo” de Minikube en realidad solo inicia múltiples nodos en el mismo host usando runtimes de contenedores – útil para simular un clúster, pero no para ejecutar en máquinas físicas separadas).

Facilidad de instalación y uso: Minikube es muy fácil de empezar en una sola máquina. Instalamos el binario de minikube, aseguramos que tengamos un driver de VM (o Docker) y ejecutamos minikube start. Esto configurará una VM/contenedor local y lanzará Kubernetes dentro de ella. Es probablemente la forma más sencilla de obtener un clúster de Kubernetes en funcionamiento por primera vez. La CLI (minikube) proporciona comandos para interactuar con la VM (iniciar, detener, eliminar) y para habilitar complementos. Dado que Minikube está diseñado para uso local, no es un “daemon de larga duración” – normalmente lo iniciamos cuando lo necesitamos y lo detenemos cuando terminamos, aunque podemos mantenerlo en ejecución continuamente en un servidor de homelab si lo deseamos. El mantenimiento/actualización es fácil: simplemente actualizamos la versión de minikube y reiniciamos el clúster (Minikube también puede actualizar la versión de Kubernetes que ejecuta con una bandera). Sin embargo, una limitación es que Minikube está diseñado para un solo nodo (añadir más nodos significa iniciar instancias VM adicionales en el mismo host, no unir hosts reales separados). Por lo tanto, usar Minikube en tres máquinas físicas separadas significaría ejecutar tres clústeres de un solo nodo independientes, lo cual probablemente no es lo que queremos. Minikube destaca para desarrollo y pruebas en una sola máquina, pero no está pensado para gestionar un clúster distribuido en múltiples servidores físicos.
Soporte para volúmenes persistentes: Integrado (hostPath). Los clústeres de Minikube incluyen automáticamente una clase de almacenamiento predeterminada que usa un proveedor de hostPath. De hecho, Minikube ejecuta un pequeño controlador que crea dinámicamente PVs de hostPath dentro de la VM cuando se solicitan PVCs. Esto significa que podemos crear PersistentVolumeClaims y se cumplirán usando el almacenamiento del sistema de archivos de la VM de Minikube (normalmente bajo /tmp/hostpath-provisioner o similar). Esto funciona de forma inmediata – no se requiere configuración para el uso básico de PV. Por ejemplo, la clase de almacenamiento “standard” predeterminada en Minikube se mapea al almacenamiento de hostPath en el nodo. Una advertencia: si reiniciamos o eliminamos la VM de Minikube, esos volúmenes de hostPath podrían perderse (Minikube intenta preservar ciertos directorios entre reinicios – por ejemplo, /data, /var/lib/minikube, /tmp/hostpath* se conservan). Pero en general, para un entorno no de producción esto es aceptable. Si queremos simular más, Minikube también tiene un addon de controlador de hostpath CSI que soporta instantáneas y puede funcionar en modo multi-nodo, pero eso es más para experimentar. En resumen: Minikube soporta PVs por defecto mediante hostPath, lo cual es suficiente para una prueba de aplicaciones estatales en un homelab.
Soporte para LoadBalancer: Soportado mediante tunelización (o addon de MetalLB). En la nube, un servicio LoadBalancer obtiene un balanceador de carga en la nube con una IP externa. En Minikube, obviamente no hay proveedor en la nube, así que Minikube proporciona dos mecanismos:
- Minikube Tunnel: Podemos ejecutar minikube tunnel en un proceso separado que creará una ruta de red en nuestro host y asignará una IP a nuestro servicio LoadBalancer. En esencia, usa nuestro host para actuar como el “balanceador de carga externo”. Cuando creamos un servicio LoadBalancer, Minikube mostrará una “IP externa” (normalmente de la subred del clúster) y el proceso minikube tunnel enrutarán esa IP al servicio. Esto requiere que el proceso de tunelización siga ejecutándose (y normalmente permisos de root para crear rutas). Es un paso manual, pero Minikube imprime un recordatorio si tenemos un servicio LoadBalancer sin un proceso de tunelización en ejecución (“IP externa pendiente” hasta que iniciamos el tunel).
- Addon de MetalLB: Las versiones más recientes de Minikube también incluyen un addon de MetalLB. Podemos hacer minikube addons enable metallb y configurar un rango de IPs (Minikube nos preguntará). Esto desplegará MetalLB dentro del clúster de Minikube, que luego manejará los servicios LoadBalancer como lo haría en cualquier Kubernetes en hardware bare metal. Es una solución más “dentro del clúster” y no requiere un proceso de tunelización separado después de la configuración inicial.
Ambas opciones funcionan, y la elección depende de nosotros. Para exponer rápidamente un servicio, minikube tunnel es rápido y efímero. Para una configuración más permanente, el addon de MetalLB puede habilitarse para que los LBs obtengan IPs reales (por ejemplo, podríamos darle un rango como 10.0.0.240-250 en un Minikube con red puenteada). Recuerda que Minikube es típicamente de un solo nodo, así que en efecto el “balanceador de carga” no equilibra entre múltiples nodos – solo proporciona acceso externo al servicio del solo nodo. Esto está bien para el desarrollo. En un homelab, si solo usamos uno de nuestros nodos y ejecutamos Minikube en él, podríamos usar estos para acceder a nuestras aplicaciones. Pero si queremos aprovechar los 3 nodos, el enfoque de Minikube para LB no está pensado para ese escenario.
Requisitos de recursos: Minikube en sí mismo es ligero, pero ya que normalmente ejecuta un Kubernetes de un solo nodo (en una VM), el uso de recursos es similar al de un clúster pequeño normal. El mínimo recomendado es 2 GB de RAM y 2 CPUs para la VM. Por defecto, Minikube suele asignar 2 GB de RAM para su VM. En nuestro caso, con 16 GB por máquina, eso es trivial. Minikube (Kubernetes) en estado inactivo podría usar ~600 MB de memoria. Una cosa a considerar es que Minikube se ejecutará sobre nuestro sistema operativo – ya sea como una VM mediante un hipervisor o un contenedor Docker – lo que añade algunos sobrecostos. En un servidor de homelab, podríamos ejecutar Minikube con el driver “none” (que instala directamente los componentes de Kubernetes en el host). Sin embargo, el driver “none” (también conocido como bare-metal) es esencialmente similar a usar kubeadm en ese nodo, y requiere limpieza manual, así que no es tan popular. La mayoría usan un driver de VM o Docker. En resumen, cualquier uno de nuestros nodos de homelab puede ejecutar Minikube fácilmente. La única restricción es que Minikube no usará los recursos de los 3 nodos – se limitará al solo host en el que se ejecuta (a menos que usemos el modo multi-nodo experimental dentro de un solo host).
Un solo nodo vs. múltiples nodos: Principalmente un solo nodo. Minikube es ideal para un clúster de un solo nodo en una sola máquina. Tiene una función para simular múltiples nodos (por ejemplo, minikube start --nodes 3 con el driver Docker iniciará 3 nodos de Kubernetes como contenedores en un solo host), pero esto es solo para pruebas. No podemos usar Minikube para crear un clúster real de múltiples nodos en 3 servidores físicos separados. Si tenemos 3 máquinas, tendríamos que ejecutar 3 instancias independientes de Minikube (no en un solo clúster). Eso no es una experiencia real de clúster (no se conocerán entre sí). Por lo tanto, Minikube no se recomienda si nuestro objetivo es utilizar los tres nodos en un solo clúster de Kubernetes – es mejor para escenarios donde solo tenemos una máquina (nuestra PC o un solo servidor) y queremos ejecutar K8s en ella. También es excelente para aprender los fundamentos de Kubernetes y hacer desarrollo local.
Herramientas CLI y UI: La CLI minikube es la interfaz principal. La usamos para iniciar/parar el clúster, y tiene atajos útiles: por ejemplo, minikube dashboard habilitará el Dashboard de Kubernetes y lo abrirá en nuestro navegador. minikube addons enable <addon> puede habilitar una variedad de componentes opcionales (ingreso, metallb, servidor de métricas, etc.). Minikube configura automáticamente el acceso a kubectl (configura un contexto “minikube” en nuestro kubeconfig). Para la UI, como se mencionó, el Dashboard de Kubernetes es fácilmente accesible mediante el comando dashboard. Minikube no tiene su propia interfaz web única; depende de herramientas estándar. El depurado de Minikube también es fácil ya que podemos minikube ssh para acceder al nodo VM si es necesario. En general, las herramientas son muy amigables para un escenario de un solo nodo.

Kubeadm (Kubernetes puro en nuestros propios nodos)

Funciones clave: Kubeadm no es una “distribución”, sino más bien la herramienta oficial para crear un clúster de Kubernetes desde cero. Usar kubeadm significa que estamos desplegando componentes estándar de Kubernetes en nuestros máquinas. Es esencialmente cómo “hacemos nuestro propio” clúster, siguiendo buenas prácticas pero sin los extras que incluyen las distribuciones. Kubeadm configurará un nodo de control (que ejecuta etcd, servidor de API, controlador manager, programador) y unirá nodos de trabajo a él. El resultado es un clúster de Kubernetes completamente estándar idéntico al que obtendríamos en máquinas virtuales en la nube. Este enfoque nos da un control total y flexibilidad – elegimos el plugin de red, el proveedor de almacenamiento, etc. – pero también requiere el mayor esfuerzo manual inicial y conocimiento. Se usa con frecuencia en entornos de producción o de aprendizaje para entender los internos de Kubernetes.

Facilidad de instalación y mantenimiento: En comparación con los demás, kubeadm es el más involucrado. Tenemos que instalar manualmente las dependencias (runtime de contenedores como containerd, kubeadm, kubelet, kubectl) en cada nodo. Luego ejecutamos kubeadm init en el maestro, y kubeadm join en los trabajadores con el token que proporciona. También necesitamos configurar un CNI (plugin de red) después de la inicialización (Calico, Flannel, etc.) ya que kubeadm no instala uno por defecto. Hay pasos bien documentados para todo esto (el proceso no es difícil, pero tiene muchos pasos) – esencialmente, kubeadm nos da un clúster de inicio pero espera que nosotros manejen los complementos. En cuanto al mantenimiento, somos responsables de las actualizaciones (kubeadm sí tiene un comando de actualización, pero debemos drenar nodos, actualizar binarios, etc. manualmente), así como monitorear la salud de etcd, renovaciones de certificados, etc. En resumen, kubeadm es potente pero manual. A menudo se llama “la forma difícil” (aunque no tan difícil como compilar desde la fuente). Para un entusiasta de homelab que disfruta aprender, kubeadm es una gran manera de entender profundamente Kubernetes. Pero si nuestra prioridad es “fácil y de bajo mantenimiento”, kubeadm será más trabajo que K3s/MicroK8s. Cada actualización o cambio requerirá esfuerzo manual. Dicho esto, una vez configurado, es el auténtico trato: un clúster de Kubernetes estándar sin abstracciones ocultas.
Soporte de Volumen Permanente: Ninguno por defecto (debe agregarse manualmente). Un clúster instalado con kubeadm es esencialmente un Kubernetes vacío – no incluye una StorageClass por defecto ni un proveedor de provisionamiento dinámico de serie. En entornos en la nube, el proveedor de la nube normalmente proporciona una StorageClass por defecto (por ejemplo, AWS EBS, etc.), pero en un entorno de homelab en hardware físico, tendremos que instalar nuestra propia solución. Enfoques comunes:
- Provisionador HostPath: Podemos replicar lo que hacen K3s/Minikube instalando algo como el Rancher Local Path Provisioner (que es un pequeño controlador + StorageClass que crea PVs de hostPath). Este es un complemento simple (solo un manifiesto YAML) y nos da almacenamiento dinámico local.
- NFS o NAS: Algunos usuarios de homelab configuran un servidor NFS (o usan un NAS) y luego usan PVs estáticos o un driver de provisionamiento NFS CSI para su configuración.
- OpenEBS/Longhorn/Ceph: Hay opciones más complejas como desplegar Longhorn o Ceph RBD a través de Rook si queremos almacenamiento distribuido entre nodos. Estas requieren más recursos y complejidad.
El punto clave es que kubeadm no “resuelve” el almacenamiento para nosotros – debemos decidir y configurarlo. Si la facilidad es la prioridad, la ruta más simple es instalar un provisionador de hostPath o usar NFS. Por ejemplo, el provisionador local-path de Rancher puede instalarse en unos cuantos comandos kubectl apply y replicará el comportamiento de K3s (creando volúmenes bajo /var/lib/rancher/ en cualquier nodo). Pero esto es un paso manual. Hasta que lo hagamos, cualquier PVC que creamos permanecerá en estado Pendiente porque Kubernetes no tiene un provisionamiento por defecto. Así que, aunque kubeadm ciertamente soporta Volumenes Permanentes (es un Kubernetes completo), el soporte para PV dinámico es tan bueno como el esfuerzo que pongamos para configurarlo.
Soporte de LoadBalancer: Ninguno por defecto (debe agregarse manualmente). Historia similar aquí: en un clúster tradicional en premisa, no tenemos una implementación de LoadBalancer integrada. Si creamos un Servicio de tipo LoadBalancer en un clúster kubeadm puro, permanecerá en estado pendiente para siempre hasta que despleguemos un controlador para manejarlo. La solución común es instalar nosotros mismos MetalLB. MetalLB puede instalarse mediante manifiesto o chart de Helm – configuraríamos un rango de IP y luego asignaría esas IPs para servicios de LoadBalancer (al igual que en MicroK8s). Existen muchas guías para instalar MetalLB en clústeres kubeadm. Otra alternativa que algunos usan es kube-vip para VIP de control-plane y servicios LB, pero MetalLB es más simple para servicios. En esencia, con kubeadm tenemos la libertad (o la carga) de configurar cualquier mecanismo de balanceo de carga que se adapte a nuestras necesidades. Si no configuramos nada, estaremos limitados a servicios NodePort para el acceso externo. Para un homelab, instalar MetalLB se recomienda altamente – es sencillo y nos da esa funcionalidad de IP de servicio como en la nube. Pero nuevamente, eso es un paso adicional que debemos realizar (a diferencia de K3s que funciona de forma nativa o MicroK8s con un simple enable).
Requisitos de Recursos: Kubernetes estándar es un poco más pesado que las versiones recortadas. Cada nodo ejecutará un kubelet y kube-proxy, y el maestro ejecutará etcd y componentes de control-plane. Un solo nodo de control-plane puede ejecutarse con 2 GB de RAM, pero normalmente querríamos un poco más si vamos a ejecutar pods en él. La guía de padok sugiere 2 GB para el maestro, 2 GB para el trabajador mínimo. En nuestro escenario (16 GB por nodo), está bien. Etcd y servidor de API en estado de inactividad pueden usar unos pocos cientos de MB de memoria cada uno. No hay una gran diferencia en tiempo de ejecución entre un clúster kubeadm y MicroK8s – después de todo, MicroK8s es esos mismos componentes. La diferencia es solo lo que se ejecuta por defecto (MicroK8s podría habilitar DNS y almacenamiento por defecto, mientras que en kubeadm instalaríamos esos). Por lo tanto, en cuanto a recursos, kubeadm puede ser tan delgado o pesado como configuremos. Sin nada extra instalado, podría ser bastante delgado. Con una configuración típica (digamos que añadimos CoreDNS, Dashboard, etc.), se espera que se use ~1 GB o así para sobrecargas del sistema. Tenemos suficiente RAM, así que los recursos no son un problema. Es más sobre el tiempo y recursos humanos necesarios para gestionarlo en lugar de CPU/RAM.
Un solo nodo vs. múltiples nodos: Kubeadm puede hacer ambos, con toda flexibilidad. Podemos inicializar un clúster de un solo nodo (e incluso decirle a kubeadm que permita que el solo nodo ejecute cargas de trabajo quitando el taint del maestro). O podemos tener un maestro y unir dos trabajadores (una configuración común de 3 nodos). Incluso podríamos configurar 3 maestros y 3 trabajadores, etc. – cualquier topología. En nuestro caso, una configuración probable de kubeadm sería 1 nodo de control-plane y 2 trabajadores (ya que no se necesita HA, no necesitamos múltiples maestros). Eso nos da un clúster funcional de 3 nodos. El proceso para múltiples nodos está bien documentado: esencialmente, instalar Kubernetes en todos, inicializar uno, unir los demás. El resultado es idéntico al que daría un clúster gestionado u otra distribución: nuestros 3 nodos aparecen en kubectl get nodes, etc. Así que kubeadm ciertamente cumple con el requisito de “poder usar los 3 nodos”.
Herramientas CLI y UI: Con kubeadm, la única herramienta CLI especial es kubeadm en sí misma, usada para los pasos de configuración y (más tarde) actualización. En la vida cotidiana, usamos kubectl para gestionar el clúster. No hay una CLI de gestión integrada más allá de lo que proporciona Kubernetes. Para la UI, nada está incluido por defecto – podemos instalar manualmente el Dashboard de Kubernetes o cualquier otra herramienta (al igual que en cualquier clúster). Esencialmente, kubeadm nos da un lienzo de Kubernetes en blanco. Es nuestra responsabilidad pintar en él – lo que incluye instalar conveniencias como dashboard, controladores de ingreso, clases de almacenamiento, etc. Muchas dashboards de terceros (Lens, Octant, etc.) también pueden conectarse a un clúster kubeadm si queremos una experiencia de gestión con interfaz gráfica, pero esas son herramientas externas. En resumen, con kubeadm obtenemos un entorno de Kubernetes puro – máxima flexibilidad, pero también la necesidad de configurar todo como si fuera un clúster de producción.
Kubespray Ver también cómo instalar esta versión de Kubernetes con Kubespray.

Comparación lado a lado en tabla

A continuación se presenta un resumen comparando las cuatro opciones en puntos clave:

Aspecto	K3s (K8s ligero de Rancher)	MicroK8s (K8s “Low-Ops” de Canonical)	Minikube (K8s de desarrollo en un solo nodo)	Kubeadm (Kubernetes puro)
Instalación	Script de instalación en una línea (único binario). Se ejecuta como un servicio del sistema. Configuración muy rápida.	Instalación en una sola línea mediante snap en Ubuntu. Todos los componentes incluidos. Clustering fácil con `microk8s join`.	Instalar el CLI de minikube, luego ejecutar `minikube start` para lanzar una VM/container local. Multiplataforma y amigable para principiantes.	Instalación manual de kubeadm, kubelet, etc. en cada nodo. Ejecutar `kubeadm init` + `kubeadm join` con requisitos previos. Involucra varios pasos (runtime, plugin de red, etc.).
Mantenimiento y actualizaciones	Actualizaciones manuales (reemplazar binario o usar script de instalación para nueva versión). Simple, ya que es un solo binario; poco que gestionar. No hay actualizaciones automáticas.	Actualizaciones mediante `snap refresh` (pueden ser automáticas). Add-ons y servicios del clúster gestionados mediante CLI `microk8s`. Generalmente de bajo mantenimiento; actualizaciones automáticas disponibles.	Fácil eliminar/recrear clúster para desarrollo. Actualizaciones actualizando la versión de minikube y reiniciando el clúster. Está pensado para uso efímero (menos enfoque en la longevidad de actualizaciones en lugar).	El usuario es responsable de todas las actualizaciones. Usar `kubeadm upgrade` pero debe drenar nodos, manejar respaldos de etcd, etc. Pleno control, pero usted hace el trabajo (sin actualizaciones automáticas).
Versión de K8s	Sigue al upstream con cierta cercanía (a menudo usado en lanzamientos de borde). Conformante con CNCF. Algunas características deshabilitadas por defecto (alpha/legacy).	Sigue las versiones upstream (canales de snap para 1.27, 1.28, etc.). Conformante con CNCF. Básicamente binarios de K8s puros.	Podemos elegir la versión de Kubernetes al iniciar (por ejemplo, `minikube start --kubernetes-version=v1.27`). Por defecto se usa la más reciente estable.	Cualquier versión que queramos (instalar versiones específicas de kubeadm/kubelet). Kubernetes upstream completo – decidimos la versión y cuándo actualizar.
Funciones por defecto	Funcionalidades por defecto empaquetadas: Flannel CNI, CoreDNS, Traefik ingress, balanceador de carga de servicio, clase de almacenamiento local, metrics-server, etc. (Todas pueden deshabilitarse si no son necesarias). Minimal config needed to be functional.	Por defecto mínimo: DNS generalmente activo, otros opcionales. Add-ons fáciles de un solo comando para ingress (NGINX), MetalLB, almacenamiento hostpath, dashboard, etc.. Se puede habilitar modo HA en 3+ nodos.	Empaquetado en VM: generalmente incluye runtime de Docker/containerd, Kubernetes con add-ons por defecto como StorageProvisioner y DNS. Add-ons opcionales (ingress, dashboard, etc.) activables mediante CLI. No multi-nodo por defecto.	Básico: Nada más allá de Kubernetes core. Sin ingress, sin almacenamiento o balanceador por defecto, sin dashboard hasta que lo instalamos. Elegimos el plugin CNI (debe instalarse uno para red). Esencialmente un clúster DIY.
Soporte de Volumen Permanente	Sí – de fábrica. El proveedor dinámico de Rancher local-path incluido, que crea PVs hostPath en el nodo para cualquier PVC. Clase de almacenamiento por defecto “local-path” usa disco local automáticamente.	Sí – add-on fácil. Habilitar `hostpath-storage` para obtener una Clase de Almacenamiento por defecto para PVs dinámicos usando hostPath. Hasta que se habilite, no hay proveedor de PV por defecto. El add-on no es para producción multi-nodo, pero está bien para homelab.	Sí – de fábrica. La Clase de Almacenamiento por defecto usa el proveedor hostPath dentro de la VM de minikube. Los PVCs se cumplen mediante un controlador simple que crea un PV hostPath en el sistema de archivos del nodo. Los datos persisten tras reinicios en ciertas carpetas.	No (manual). No hay proveedor por defecto – el clúster no tendrá ninguna Clase de Almacenamiento inicialmente. El usuario debe instalar una solución de almacenamiento (por ejemplo, local path provisioner, NFS, Ceph, etc.). Enfoque básico: aplicar un YAML de proveedor hostPath para imitar lo que hace K3s/Minikube. Hasta entonces, los PVCs permanecen pendientes.
Soporte de LoadBalancer	Sí – ServiceLB integrado. El controlador servicelb de K3s (Klipper) vigila servicios LoadBalancer y despliega pods en nodos para exponerlos. Usa IP del nodo y puertos host para reenviar tráfico. Funciona de fábrica sin configuración. Adecuado para pequeños clústeres; usa IP interna/externa del nodo para el servicio.	Sí – mediante add-on MetalLB. Habilitar `metallb` con un rango de IP para asignar. Proporciona un balanceador de carga de capa 2 real en hardware. No está habilitado por defecto. Una vez habilitado, cada servicio LoadBalancer obtiene una IP única de nuestra piscina. Requiere un poco de configuración inicial (rango de IP).	Sí – mediante túnel o MetalLB. No hay balanceador de carga en la nube, pero podemos ejecutar `minikube tunnel` para asignar una IP externa a servicios LoadBalancer (crea ruta en el host). Alternativamente, habilitar el add-on MetalLB en minikube para IPs de balanceador automáticas. Por defecto, los servicios LoadBalancer mostrarán “pendiente” hasta que usemos uno de estos métodos.	No (manual). No hay balanceador de carga integrado. Normalmente se instala MetalLB manualmente para funcionalidad de balanceador en hardware. Una vez instalado MetalLB (u otro controlador de balanceador), los servicios LoadBalancer funcionan. Sin él, los servicios LoadBalancer permanecen pendientes indefinidamente.
Red (CNI)	Por defecto = Flannel (red de overlay). K3s también admite reemplazar CNI si es necesario. Viene con CoreDNS desplegado para DNS del clúster. Traefik ingress incluido por defecto (se puede deshabilitar).	Por defecto = Calico (para versiones recientes en modo HA) o un valor por defecto sencillo. (MicroK8s históricamente usó flannel; ahora tiende a usar Calico para confinamiento estricto). CoreDNS habilitado por defecto. NGINX ingress disponible mediante add-on (`microk8s enable ingress`).	Por defecto = kubenet/bridge (depende del driver; a menudo usa una red NAT simple). CoreDNS se ejecuta por defecto. Podemos habilitar un add-on de NGINX ingress si es necesario. La red está confinada a la única VM; NodePort es accesible mediante `minikube ip`.	Elección de CNI. Kubeadm no instala ningún plugin CNI – debemos desplegar uno (Calico, Flannel, Weave, etc.). Tenemos pleno control. La mayoría de guías tienen que aplicar YAML de Calico después de `kubeadm init`. CoreDNS se instala por defecto como DNS del clúster por kubeadm. Controlador de ingreso – elegimos y lo instalamos nosotros mismos (por ejemplo, NGINX o Traefik mediante manifests/Helm).
Clustering multi-nodo	Sí. Diseñado para multi-nodo. Fácil unión con token. Se puede usar base de datos externa o etcd integrado para multi-maestro. Ideal para homelabs de 2-3+ nodos. No se necesitan dependencias adicionales – K3s tiene su propio clustering integrado.	Sí. Soporta clustering de múltiples nodos MicroK8s (con `microk8s join`). Se puede habilitar HA con 3+ maestros (Dqlite). Muy sencillo formar un clúster, especialmente si todos los nodos ejecutan Ubuntu + snap.	No (físico). Por diseño es un solo nodo. Se puede simular multi-nodo en una sola máquina (múltiples nodos en contenedores Docker), pero no puede abarcar múltiples hosts físicos en un solo clúster. Usar instancias Minikube separadas para clústeres separados.	Sí. Soporta plenamente multi-nodo (ese es el punto). Podemos tener 1 maestro + muchos trabajadores, o incluso múltiples maestros (aunque la configuración HA de kubeadm es más compleja). No hay limitación de tamaño de clúster preinstalada.
Sobrecarga de recursos	Muy baja. Plataforma de control ~<0.5 GB memoria en reposo. Un solo proceso para la plataforma de control genera un pequeño footprint. Eficiente en CPU (aunque puede usar ligeramente más CPU en reposo que MicroK8s según algunos informes). Ideal para bajo consumo de energía o muchos recursos disponibles.	Baja. ~0.5–0.6 GB memoria para la plataforma de control en reposo. Ligeramente mayor base de memoria que K3s, pero estable. Usa snap de Ubuntu (puede tener algo de sobrecarga). Aún ligera en comparación con Kubernetes completo.	Moderada. Asignación por defecto de VM 2 GB (uso ~0.6 GB en reposo). Ejecuta un Kubernetes completo en un solo nodo, más la capa de VM. No es un problema en sistemas de 16 GB, pero básicamente consume recursos de un pequeño clúster en una sola máquina.	Moderada. Un solo maestro con un trabajador podría usar ~1 GB en reposo después de agregar add-ons típicos. Cada nodo adicional agrega poca sobrecarga (solo kubelet, proxy). Similar a ejecutar Kubernetes en VMs de la nube de tamaño comparable. En 3 nodos con 16 GB cada uno, la sobrecarga es insignificante en contexto.
Herramientas de CLI	Usar `k3s` para instalación y como envoltura para kubectl (o usar `kubectl` estándar). No hay CLI de gestión separada (K3s es principalmente “configurar y olvidar”). Algunos scripts de ayuda (por ejemplo, `k3s-killall.sh`). Se puede agregar la interfaz gráfica de Rancher si se desea.	CLI `microk8s` rico: por ejemplo, `microk8s enable/disable <addon>`, `microk8s status`. También incluye `microk8s kubectl`. Diseñado para simplificar tareas comunes (no se necesita edición directa de manifiestos del sistema para básicos).	CLI `minikube` para iniciar/parar clúster, gestionar configuración y add-ons, y obtener información (IP, URL del servicio, logs). También proporciona comandos de conveniencia como `minikube dashboard`. Interactuar con el clúster mediante `kubectl` (configuración automática para contexto de minikube).	Solo `kubeadm` para configuración inicial y actualizaciones. Operaciones diarias mediante `kubectl` estándar y otras herramientas de Kubernetes. No hay CLI específica de distribución más allá del bootstrap. Estarás trabajando con comandos de Kubernetes puros y posiblemente herramientas del sistema para mantenimiento.
Interfaz de usuario / Dashboard	No incluido por defecto. Se puede instalar manualmente el Dashboard de Kubernetes o usar herramientas externas (nada específico de Rancher a menos que se agregue Rancher). El enfoque de K3s es la operación sin interfaz.	No incluido por defecto, pero disponible mediante un solo comando: `microk8s enable dashboard` despliega la interfaz gráfica estándar del Dashboard. Acceso fácil al clúster mediante `microk8s dashboard-proxy`. También se integra bien con la interfaz gráfica Lens de Canonical si se desea (Lens puede acceder directamente a MicroK8s).	No habilitado por defecto, pero el comando `minikube dashboard` desplegará y abrirá la interfaz web del Dashboard para nosotros. Esto está pensado para comodidad en desarrollo local – un solo comando y tenemos una interfaz gráfica para ver cargas de trabajo.	No incluido. Podemos instalar el Dashboard (aplicar YAML) si queremos. De lo contrario, usar CLI o aplicaciones de dashboard de terceros. En un homelab, uno podría instalar el dashboard y crear un NodePort o usar `kubectl proxy` para verlo. Kubeadm no se preocupa por interfaces gráficas.

Fuentes: Los datos anteriores se sintetizaron de documentos oficiales y guías de usuario: por ejemplo, huella de memoria de MicroK8s de su propia comparación, almacenamiento por defecto en documentos de K3s, comportamiento del balanceador de servicio de K3s de la documentación de K3s, detalles de add-ons de MicroK8s de documentos de Canonical, PV y túnel de Minikube de la documentación de Kubernetes, y reportes generales de experiencia. (Ver Referencias para citas completas.)

Recomendaciones

Dado los prioridades (facilidad de instalación/mantenimiento, y soporte integrado para almacenamiento y balanceadores de carga) y el escenario (3 nodos Ubuntu, no preocupados por HA):

Opciones principales: K3s o MicroK8s son las más adecuadas para un homelab con 3 nodos:
- Ambos son muy fáciles de instalar (un solo comando en cada nodo) y requieren un mantenimiento mínimo. Abstraen la mayor parte de la complejidad de ejecutar un clúster.
- Ambos admiten clústeres multiproceso de forma nativa (podemos unir nuestros 3 nodos y ver un clúster unificado).
- Cada uno proporciona una solución para volúmenes persistentes y balanceadores de carga sin mucho esfuerzo: K3s los incluye por defecto (almacenamiento Local Path, Klipper LB) y MicroK8s los hace disponibles mediante simples comandos enable. Esto significa que podemos desplegar aplicaciones típicas (bases de datos con PVCs, servicios con tipo=LoadBalancer) con un mínimo de configuración manual.
- K3s podría atraer si queremos el tamaño de huella absolutamente más pequeño y no nos importa usar sus valores predeterminados (ingreso Traefik, etc.). Es un enfoque “configura y funciona” con valores predeterminados orientados. También es muy popular en la comunidad de homelabs por su simplicidad. Usaremos principalmente kubectl estándar y podemos ajustar o deshabilitar los componentes empaquetados si es necesario. K3s podría ser preferible si no estamos en Ubuntu o si nos gusta el ecosistema de Rancher (o planeamos usar la interfaz de gestión de Rancher más adelante).
- MicroK8s podría atraer si preferimos una solución respaldada por Ubuntu y nos gusta la idea de habilitar características con un solo comando. Es esencialmente Kubernetes puro bajo el capó, lo que algunos encuentran más fácil de extender. Los complementos (como microk8s enable ingress dns storage metallb) pueden darnos una “nube micro” funcional en minutos. MicroK8s también maneja las actualizaciones de forma suave mediante snaps, lo cual puede ser útil para mantener nuestro clúster actualizado sin intervención manual (podemos desactivarlo o controlar el canal para evitar sorpresas). Si ya estamos ejecutando Ubuntu en todos los nodos (lo cual sí es el caso) y no nos importa usar snaps, MicroK8s es una excelente opción para un clúster de bajo mantenimiento.
En resumen: No se puede equivocar con ninguno de K3s o MicroK8s en este escenario. Ambos nos darán un Kubernetes fácil de usar, amigable para homelabs, con las características que necesitamos. Muchos usuarios reportan experiencias positivas con ambos en configuraciones de hogar con 2–3 nodos. MicroK8s podría tener una ligera ventaja en facilidad de uso (debido a los complementos e integración), mientras que K3s podría tener una ligera ventaja en ejecutar con un tamaño mínimo y ser directo bajo el capó.
Cuándo elegir Minikube: Si estuviéramos solo ejecutando en una sola máquina o quisiéramos un clúster de desarrollo temporal, Minikube es fantástico para eso. Es la forma más fácil de levantar Kubernetes en una laptop o un solo nodo para pruebas. Sin embargo, para un clúster permanente de 3 nodos, Minikube no es la herramienta adecuada – no unirá esos 3 nodos en un solo clúster. Terminaríamos subutilizando nuestro hardware o gestionando 3 clústeres separados, lo cual no es deseable. Por lo tanto, en este homelab con múltiples nodos, Minikube no se recomienda como solución principal. Podríamos aún usar Minikube en nuestro propio computador para probar cosas antes de desplegar en el clúster del homelab, pero para el clúster en sí mismo, usaremos algo como K3s/MicroK8s.
Cuándo elegir Kubeadm: Si nuestro objetivo fuera aprender los internos de Kubernetes o tener un control completo y una configuración “similar a producción”, kubeadm es una buena opción. Nos obligará a entender cómo instalar CNI, almacenamiento, etc., y básicamente construiremos el clúster pieza por pieza. En términos de facilidad de uso, sin embargo, kubeadm es el más manual. Cada función que necesitemos (como almacenamiento o LB) tendremos que configurarla. Para un homelab enfocado en el aprendizaje, esto podría ser una ventaja (educativa); para un homelab solo queremos que funcione, es una desventaja. Además, el mantenimiento será más involucrado (especialmente durante las actualizaciones). A menos que específicamente quisiéramos la experiencia de Kubernetes puro para aprender o necesidades específicas personalizadas, usar K3s o MicroK8s nos ahorrará mucho tiempo y dolores de cabeza en un entorno de homelab. Dicho esto, algunos usuarios experimentados prefieren kubeadm incluso en casa para evitar cualquier peculiaridad específica de un proveedor y tener todo bajo su control. Realmente depende de cuánto esfuerzo queramos invertir. Para la mayoría, kubeadm es excesivo para un clúster pequeño donde no se preocupe por alta disponibilidad.
Otras opciones: Hay otras pocas variantes de Kubernetes livianas, como k0s (por Mirantis) y herramientas como kind (Kubernetes en Docker). Para completitud:
- k0s es otro distribución de Kubernetes de un solo binario, con un objetivo similar al de K3s/MicroK8s, que se centra en flexibilidad y un tamaño mínimo. Es relativamente nuevo pero tiene seguidores en la comunidad de homelabs. También puede ejecutarse fácilmente en nuestros 3 nodos. No tiene (actualmente) la misma gran base de usuarios que K3s/MicroK8s, pero es una opción a seguir (especialmente si nos gusta la idea de un Kubernetes abierto, configurable y mínimo – algunos informes incluso muestran que k0s usa ligeramente menos recursos en reposo que K3s/MicroK8s en configuraciones similares).
- kind es principalmente para probar clústeres Kubernetes en contenedores Docker (a menudo usado en pipelines de CI). No es algo que ejecutaríamos como nuestro clúster de homelab siempre encendido – es más para clústeres efímeros rápidos en una sola máquina (similar al propósito de Minikube).
- Rancher Kubernetes Engine (RKE) o K3d o otros también están ahí, pero esos están orientados hacia clústeres contenedorizados (k3d ejecuta un clúster K3s en Docker) o escenarios de despliegue más complejos. En un homelab, K3s y MicroK8s han terminado siendo las soluciones fáciles de facto.

Conclusión: Para un homelab con 3 nodos decentes, MicroK8s o K3s son las opciones recomendadas para obtener un clúster Kubernetes funcional con mínimo esfuerzo. Nos permitirán aprovechar todos nuestros nodos en un solo clúster y proporcionarán soporte integrado para volúmenes persistentes y servicios de LoadBalancer, que es exactamente lo que pedimos. Si preferimos una solución más plug-and-play integrada con Ubuntu, elige MicroK8s. Si prefieres una solución super ligera, probada con el respaldo de Rancher, elige K3s. Tendremos un clúster funcional en minutos cualquiera de las dos opciones. Una vez configurado, podremos desplegar el Dashboard de Kubernetes u otras herramientas para gestionarlo y comenzar a alojar nuestras aplicaciones con almacenamiento persistente y exposición fácil de servicios. Disfruta de tu viaje con Kubernetes en tu homelab!