Ya sabes qué hace Kubernetes, cómo está construido por dentro y qué significa cada término del vocabulario. Todo eso ha sido teoría necesaria, pero Kubernetes no se aprende leyendo: se aprende rompiendo cosas en un clúster propio. Esta lección tiene dos partes. Primero, un panorama honesto de las opciones reales para conseguir un clúster —local, autogestionado o gestionado en la nube— con criterios para elegir en un proyecto profesional. Y después, la guía práctica paso a paso para montar el clúster de prácticas que usarás durante los doce módulos del curso, donde desplegaremos la plataforma Rutas Norte. Al terminar tendrás un entorno funcional, sabrás pararlo, reanudarlo y destruirlo sin miedo, y conocerás las causas de los fallos de arranque más habituales.

1. Las tres vías para conseguir un clúster
2. El clúster de prácticas del curso: requisitos
3. Instalación de minikube y del driver
4. Arranque del clúster con recursos suficientes
5. Addons necesarios para el curso
6. Verificación del clúster
7. Ciclo de vida: parar, reanudar, destruir
8. Alternativa con kind y clúster multinodo
9. Resolución de fallos de arranque habituales

Criterios prácticos para decidir:

• ¿Estás aprendiendo o desarrollando? Local. Sin discusión: es gratis, rápido de recrear y no te expone.
• ¿Tienes un equipo de plataforma con guardias 24×7? Si la respuesta es no, evita autogestionar producción. Mantener etcd, rotar certificados y actualizar tres veces al año no es un trabajo pequeño.
• ¿Hay restricciones de soberanía del dato o hardware especial? Autogestionado, con kubeadm o una distribución comercial.
• ¿Producción normal de una empresa normal? Gestionado. Rutas Norte terminará aquí: el plano de control es un problema del proveedor y el equipo se concentra en la plataforma.

Cada vía tiene su lección propia más adelante: Minikube y Entornos Locales con kind, Kubeadm y Kubernetes Gestionado: EKS, AKS y GKE. Aquí solo montamos lo necesario para tener entorno de trabajo.

Elegimos minikube como opción principal porque trae de serie, mediante addons, dos cosas que necesitaremos mucho: un Ingress Controller (módulo 4) y un aprovisionador de almacenamiento dinámico (módulo 5). Instalarlas a mano en otras herramientas es trabajo extra que no aporta aprendizaje en este punto. Damos también la receta equivalente con kind, que es más ligero y permite clústeres multinodo con facilidad.

Rutas Norte terminará con seis componentes desplegados a la vez más los complementos de observabilidad, así que conviene no quedarse corto de recursos.

También necesitas kubectl, cuya instalación y uso se cubren en detalle en la siguiente lección, La CLI de Kubernetes: kubectl. Si aún no lo tienes, minikube puede ejecutarlo por ti con minikube kubectl -- <comando>, aunque lo normal es instalarlo aparte.

minikube crea el clúster dentro de algo: un contenedor o una máquina virtual. Ese "algo" es el driver.

Usaremos docker. Comprueba que lo tienes y que tu usuario puede usarlo sin sudo:

Si el segundo comando falla con permission denied, añade tu usuario al grupo docker y vuelve a iniciar sesión:

Linux (x86_64):

macOS (con Homebrew):

Windows (con winget, en PowerShell):

Verifica la instalación:

Este es el comando que define tu entorno de trabajo para todo el curso:

Qué hace cada opción, y por qué:

Salida esperada (abreviada):

Dos detalles importantes de esa salida:

• La última línea indica que minikube ha modificado tu kubeconfig y ha creado y activado un contexto llamado rutas-norte. Eso es lo que hace que kubectl hable con este clúster.
• Ya se han habilitado dos addons por defecto: default-storageclass y storage-provisioner. Son los que nos permitirán pedir volúmenes persistentes en el módulo 5 sin infraestructura real.

Si tu máquina tiene menos recursos, arranca con --cpus=2 --memory=4096 y tenlo presente: en el módulo 7 tendrás que apagar componentes para hacer sitio.

Los addons son componentes preempaquetados que minikube instala en el clúster. Habilita estos tres desde ya:

Comprueba que el controlador de Ingress ha arrancado antes de seguir:

Los dos pods en Completed no son un error: son Jobs de instalación que ya terminaron su trabajo (recuerda de la lección anterior que un Job termina, no se queda corriendo). El importante es el tercero, en Running y 1/1.

Tres comprobaciones que conviene hacer siempre después de crear un clúster.

1. El nodo está listo:

Lo relevante: STATUS: Ready (el kubelet reporta y el plugin de red funciona) y ROLES: control-plane (en minikube el mismo nodo hace de plano de control y de trabajador, algo que en producción nunca ocurriría).

2. Los componentes del sistema están sanos:

Reconoce esta lista: son exactamente los componentes de la lección Arquitectura de Kubernetes, ahora corriendo de verdad en tu máquina. Fíjate en que en minikube el plano de control se ejecuta como pods dentro del propio clúster (static pods gestionados por el kubelet), y que aparece coredns, el servidor DNS interno que estudiaremos en el módulo 4.

3. La API responde y sabes a qué clúster hablas:

Si las tres comprobaciones pasan, tienes un clúster operativo.

Un clúster local consume recursos aunque no lo uses. Estos son los cuatro comandos que necesitas:

Consejo de método: que minikube delete no te dé miedo es precisamente el objetivo. Si todos tus manifiestos están versionados en el directorio k8s/ del repositorio —como haremos desde la lección 01-07— recrear el clúster y volver a aplicarlos debería costarte cinco minutos. Si te da miedo borrarlo, es señal de que hay estado importante que no está en Git.

También te resultará útil:

kind (Kubernetes IN Docker) crea cada nodo como un contenedor Docker. Es más ligero que minikube y su gran ventaja es lo fácil que resulta montar un clúster multinodo, algo que te vendrá bien cuando estudiemos planificación y afinidad (módulo 6). Su desventaja: no trae addons, así que Ingress y almacenamiento requieren pasos extra.

Instalación en Linux:

Fichero de configuración con un nodo de control y dos trabajadores, preparado además para Ingress:

Explicación de las partes que importan:

• nodes: cada entrada es un contenedor Docker que actuará como nodo. Aquí tendremos tres.
• extraPortMappings: sin esto, el puerto 80 del clúster no sería accesible desde tu navegador. Es el equivalente al minikube tunnel.
• labels en los workers: etiquetas de nodo que usaremos para practicar afinidad y antiafinidad en el módulo 6, simulando dos zonas de disponibilidad.

Creación y verificación:

Instalar el Ingress Controller (kind no lo trae) y borrar el clúster cuando ya no haga falta:

Qué elegir: si dudas, minikube. Usa kind cuando necesites varios nodos o cuando montes Kubernetes dentro de un pipeline de integración continua, donde su rapidez de creación es decisiva.

Comandos de diagnóstico de propósito general cuando algo va mal en el arranque:

El tercero es especialmente valioso y lo usaremos mucho: los eventos son el diario del clúster y casi siempre contienen la explicación en texto plano de por qué algo no ha funcionado.

• Arrancar con los valores por defecto (2 CPU, 2 GiB). Funciona para los primeros módulos y se queda corto en cuanto añadas observabilidad. Es mejor dimensionar bien desde el principio que recrear el clúster a mitad de curso.
• No usar --profile. Si trabajas con varios clústeres locales, el perfil por defecto se convierte en una fuente de confusión: acabas aplicando manifiestos en el clúster equivocado. Nombrar el perfil rutas-norte deja siempre claro dónde estás.
• Cambiar la versión de Kubernetes entre sesiones. Si un día arrancas con 1.30 y otro sin fijar versión, cambian comportamientos y APIs. Fija la versión en el comando y anótala en el repositorio.
• Confundir "el clúster arrancó" con "el clúster está listo". minikube start retorna antes de que los addons estén operativos. Comprueba siempre con kubectl get pods -A que no hay nada en Pending o ContainerCreating.
• Esperar que Service de tipo LoadBalancer obtenga IP externa. En local no hay cloud-controller-manager (lo vimos en 01-02): se queda en <pending>. Se resuelve con minikube tunnel, y lo trataremos en el módulo 4.
• Dejar el clúster corriendo permanentemente. Consume CPU y batería. minikube stop al terminar la sesión conserva absolutamente todo.
• Consejo: guarda tu comando de creación de clúster en el propio repositorio (por ejemplo, en k8s/entorno-local/README o un script crear-cluster.sh). Forma parte de la documentación del proyecto tanto como los manifiestos.

Monta el clúster de prácticas con el perfil rutas-norte, 4 CPU, 8 GiB y Kubernetes 1.30, habilita los addons ingress y metrics-server, y responde:

1. ¿Cuántos nodos tiene y qué rol tienen?
2. ¿Cuántos pods hay en el namespace kube-system y cuáles se corresponden con componentes del plano de control que estudiaste en la lección 01-02?
3. ¿Cuál es la IP del nodo?
4. ¿Qué contexto de kubectl está activo?

Crea el namespace de desarrollo del proyecto, para el clúster, reanúdalo y comprueba si el namespace sigue existiendo:

Explica por qué el resultado es el que es, mencionando dónde se guarda ese objeto. Después, indica qué comando haría desaparecer ese namespace junto con todo lo demás.

Crea con kind un clúster llamado rutas-norte-multi con un nodo de control y dos trabajadores etiquetados como zona: norte y zona: sur. Comprueba que los tres nodos están Ready y muestra únicamente los nodos de la zona norte. Explica en dos líneas por qué este clúster te será útil en el módulo 6 y por qué no lo usamos como entorno principal del curso.

Solución 1

1. Un solo nodo, con rol control-plane. En minikube ese mismo nodo ejecuta también las cargas de usuario, algo que en producción no se hace: el plano de control se reserva mediante taints.
2. Alrededor de ocho pods. Se corresponden con la arquitectura: etcd, kube-apiserver, kube-scheduler, kube-controller-manager (plano de control), kube-proxy (nodo), más coredns (DNS interno), storage-provisioner y metrics-server. No aparece cloud-controller-manager porque no hay proveedor de nube.
3. minikube ip --profile=rutas-norte → típicamente 192.168.49.2.
4. kubectl config current-context → rutas-norte.

Solución 2

El namespace sigue existiendo después de stop y start. La razón es que stop no destruye nada: apaga el contenedor o la VM del nodo conservando su disco, y en ese disco está etcd, que es donde vive el objeto Namespace. Al reanudar, el apiserver vuelve a leer de la misma etcd y todo el estado declarado reaparece.

El comando que sí lo destruiría todo es minikube delete --profile=rutas-norte, que elimina el nodo y su disco, etcd incluida. Por eso los manifiestos deben vivir en Git: recrear el clúster es entonces un trámite.

Solución 3

Será útil en el módulo 6 porque la afinidad, la antiafinidad, los taints y la dispersión por topología solo se pueden practicar de verdad con varios nodos: en un clúster de un solo nodo el scheduler no tiene ninguna decisión que tomar. No lo usamos como entorno principal porque kind no incluye addons: habría que instalar a mano el Ingress Controller y un aprovisionador de almacenamiento, trabajo que en este punto del curso distrae del objetivo.

Ya tienes un clúster de Kubernetes funcionando en tu máquina, con el perfil rutas-norte, la versión 1.30 fijada, recursos suficientes para todo el curso y los addons de Ingress, métricas y almacenamiento dinámico habilitados. Has visto también el panorama completo de opciones —local, autogestionado con kubeadm, gestionado en la nube— y los criterios para elegir una u otra en un proyecto real, además de una alternativa multinodo con kind para cuando lleguemos a la planificación. Y, sobre todo, sabes pararlo, reanudarlo y destruirlo sin miedo, porque la verdad operativa del curso es que el clúster es reemplazable y los manifiestos no.

Tienes el entorno, pero apenas has usado la herramienta con la que vas a hablar con él. En la siguiente lección, La CLI de Kubernetes: kubectl, dominaremos kubectl a fondo: el fichero kubeconfig y los contextos, los verbos que usarás todos los días, los formatos de salida, la selección por etiquetas y los trucos de productividad que marcan la diferencia entre pelearse con el clúster y trabajar con soltura.