Kubernetes local sin complicaciones: guía completa de Kind para principiantes
Juan Sebastian Scatularo||10 min de lectura
En plena era de la IA, hagamos una pausa para hablar de platform engineering.
Desarrollar y probar aplicaciones orientadas a la nube suele ser una carga pesada. Levantar entornos de prueba en proveedores cloud reales como AWS puede volverse costoso, lento y difícil de aislar dentro de los flujos de integración continua.
Para los equipos de ingeniería, esto plantea un reto práctico: ¿cómo conseguir un entorno realista para desarrollar y probar aplicaciones cloud-native sin sumar costos de infraestructura, tiempo de configuración o complejidad innecesarios?
En este post vamos a explorar una herramienta esencial para aprender Kubernetes y después daremos un paso más: usar Kubernetes como runtime principal para construir nuestro propio clon de AWS, inspirado en LocalStack y Floci.
Se trata de Kind (Kubernetes IN Docker), una herramienta oficial del proyecto Kubernetes que permite levantar un cluster completo ejecutando cada nodo como un contenedor de Docker.
En esta serie de artículos veremos Kind no solo como una herramienta esencial para aprender Kubernetes, sino como el runtime principal de un proyecto ambicioso: nuestro propio emulador de AWS, ligero y declarativo, inspirado en LocalStack y Floci.
Para los líderes tecnológicos hay aquí una lección de ingeniería más amplia. Las herramientas de infraestructura local como Kind no son solo una comodidad para los developers. Pueden ayudar a las organizaciones de ingeniería a crear entornos más reproducibles, acortar los ciclos de feedback de infraestructura y experimentar con arquitecturas cloud-native antes de comprometer recursos en infraestructura compartida o de producción.
En Blue Trail Software, este tipo de problema de ingeniería se ubica en la intersección entre desarrollo de software, ingeniería cloud-native, DevOps, QA, automatización e infraestructura. La capacidad de trabajar entre esas capas es importante porque la entrega de software moderna depende cada vez más de qué tan bien interactúan los equipos de aplicación con la infraestructura.
Kind es una herramienta que permite levantar un cluster de Kubernetes fácilmente, en minutos y casi sin overhead. Originalmente se diseñó para probar el propio código de Kubernetes, pero puede usarse para mucho más.
Kind vs. Minikube y otras alternativas
Existen varias opciones para iniciar un cluster local de Kubernetes, pero Kind es una opción ligera, certificada y rápida que simplemente funciona en múltiples configuraciones.
Kind: ejecuta los nodos de forma nativa como contenedores de Docker. Arranca en menos de un minuto, consume muy pocos recursos y es extremadamente fácil de usar en pipelines de CI.
Minikube: la opción clásica. Aunque incluye un driver de Docker, por defecto suele levantar una máquina virtual completa, lo que implica mayor consumo de CPU y memoria, tiempos de arranque más largos y un overhead innecesario para nuestro objetivo final.
Docker Desktop: ofrece un cluster de un solo nodo que puede activarse directamente desde su interfaz. Es muy práctico si ya lo tienes instalado, pero no tiene soporte nativo para topologías multinodo complejas, por ejemplo.
Si buscas un entorno ligero que simule escenarios reales de producción sin ralentizar tu máquina de desarrollo o tu servidor de CI, Kind es el claro ganador y nuestra elección.
¿Por qué esta elección importa a los equipos de ingeniería?
Elegir una herramienta de Kubernetes local es, en el fondo, un tradeoff de ingeniería.
Un entorno de desarrollo debe ser lo bastante realista para validar cómo se comporta una aplicación, pero lo bastante ligero para que los developers y los sistemas de CI puedan usarlo sin un overhead excesivo de infraestructura.
Kind resuelve ese tradeoff ejecutando los nodos de Kubernetes como contenedores. Eso lo vuelve especialmente útil cuando los ingenieros necesitan reproducir entornos de Kubernetes de forma local, experimentar con configuraciones multinodo o integrar pruebas basadas en Kubernetes en flujos automatizados.
Para los líderes tecnológicos, esto se traduce en una consideración más amplia: la productividad de ingeniería no depende solo del stack de la aplicación, sino también de los entornos con los que los ingenieros trabajan todos los días.
2. Requisitos previos e instalación
Para empezar con Kind necesitas tener instaladas y configuradas tres herramientas esenciales:
Docker: el motor que ejecutará los contenedores que funcionan como tus nodos.
kubectl: la herramienta de línea de comandos para interactuar con tu cluster de Kubernetes.
kind: el binario que orquestará la creación de tus clusters locales.
freelens o k9s: herramientas para gestionar tus clusters de Kubernetes con estilo (opcional).
Instalación
El método más práctico y recomendado para cualquier entorno es descargar directamente el binario oficial de Kind y moverlo a tu ruta de ejecución local.
Para levantar un cluster básico con un solo nodo que funcione como control plane y worker a la vez, solo ejecuta:
kind create cluster --name my-cluster
Kind se encarga de descargar la imagen necesaria, que contiene todo el ecosistema de Kubernetes, preparar los certificados, inicializar el control plane y configurar tu archivo local ~/.kube/config para que kubectl apunte automáticamente a este nuevo cluster.
Este flujo tan simple muestra una de las mayores ventajas de Kind: los ingenieros pueden crear un entorno de Kubernetes desechable sin aprovisionar manualmente todo un stack de infraestructura cloud.
Creación avanzada: configuración multinodo
Una de las mayores fortalezas de Kind es lo fácil que resulta simular topologías de producción realistas en tu máquina local.
Con un archivo de configuración YAML podemos definir exactamente cuántos nodos de control plane y cuántos workers queremos en nuestro laboratorio.
Crea un archivo llamado config.yaml:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
Este manifiesto le indica a Kind que queremos desplegar un cluster compuesto por tres contenedores: un control plane y dos nodos worker independientes.
Ahora inicializa el cluster con esta configuración específica:
Cuando termine el arranque, podemos verificar que el cluster se levantó correctamente con estos comandos de inspección:
# Listar los clusters gestionados por Kind
kind get clusters
# Listar los nodos detectados por Kind
kind get nodes
# Verificar el estado de los nodos a nivel de Kubernetes con kubectl
kubectl get nodes
¿Por qué importa un cluster local multinodo?
Aquí es donde un entorno local de Kubernetes se convierte en algo más que una herramienta de aprendizaje.
Un cluster multinodo permite a los ingenieros experimentar con topologías de infraestructura más cercanas a entornos distribuidos reales. En lugar de descubrir problemas de configuración o despliegue cuando la aplicación ya llegó a un entorno compartido, los equipos pueden investigar esos comportamientos antes en el ciclo de desarrollo.
Para los líderes de ingeniería esto es importante, porque la validación técnica temprana reduce la cantidad de troubleshooting ligado a la infraestructura que habría que hacer más adelante en el proceso de entrega.
Además, demuestra una capacidad de ingeniería clave: entender cómo interactúan el comportamiento de la aplicación, la configuración del despliegue, la orquestación y la infraestructura.
4. El paso que todos olvidan: cargar imágenes de contenedor locales
Construyes tu aplicación local y compilas su imagen de Docker con:
docker build -t my-app:1.0
Escribes un manifiesto de Kubernetes que hace referencia a ese tag de imagen, lo aplicas y tus Pods se quedan atorados en un loop con el error ErrImagePull o ImagePullBackOff.
¿Por qué pasa esto?
El cluster de Kind se ejecuta dentro de sus propios contenedores aislados y no tiene visibilidad automática del motor de Docker que corre en tu máquina host.
Al intentar levantar el Pod, Kubernetes busca y trata de descargar tu imagen my-app:1.0 desde registros públicos en internet, como Docker Hub.
La solución
Kind incluye una utilidad dedicada que toma la imagen del Docker local de tu host y la inyecta directamente en el motor de contenedores interno que corre dentro de los nodos del cluster.
Ejecuta este comando cada vez que compiles una nueva versión local de tu imagen. Solo así Kubernetes podrá desplegar el Pod correctamente sin intentar descargarlo de internet.
¿Por qué es importante este pequeño detalle?
Este es justo el tipo de interacción con la infraestructura que puede generar fricción en un flujo de desarrollo.
El problema no es la aplicación en sí. El problema es que la aplicación, el runtime de contenedores y el entorno de Kubernetes no comparten automáticamente la misma vista de la imagen.
Entender esos límites es parte de hacer ingeniería cloud-native de forma efectiva.
Para los equipos que construyen y prueban aplicaciones modernas, estos problemas de entorno aparentemente pequeños pueden acumularse y convertirse en una fricción importante. Por eso los entornos reproducibles y los flujos de trabajo bien diseñados para developers son temas de platform engineering, no solo preferencias de herramientas.
5. Guía práctica: despliega tu primera app
Crea un archivo llamado app-deployment.yaml para definir un deployment. Así es como le indicas a Kubernetes cuál es tu estado deseado.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-web
namespace: default
labels:
app: nginx-app
spec:
replicas: 1
selector:
matchLabels:
app: nginx-web
template:
metadata:
labels:
app: nginx-web
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Después, define un archivo llamado app-service.yaml para exponer esta réplica de forma interna mediante un servicio ClusterIP.
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: default
spec:
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
selector:
app: nginx-web
Aplica la configuración
Para aplicar los manifiestos en tu cluster de Kind, ejecuta:
kubectl apply -f app-deployment.yaml
kubectl apply -f app-service.yaml
Para consultar el estado y verificar que tanto tu Pod como tu Service estén activos y saludables:
kubectl get pods
kubectl get svc
Acceso directo con port-forward
Como definimos nuestro servicio como ClusterIP, accesible solo dentro de la red del cluster, podemos crear un túnel rápido y temporal desde nuestra máquina host con la función nativa de port-forwarding de kubectl:
La aplicación se describe de forma declarativa con manifiestos de Kubernetes, se despliega en un cluster local, se inspecciona con comandos de Kubernetes y se valida desde la máquina del developer.
Esa misma mentalidad se vuelve cada vez más importante a medida que las aplicaciones son más distribuidas y la infraestructura está más automatizada.
Para las organizaciones de ingeniería, el valor no está solo en poder correr Nginx de forma local. El valor está en contar con un entorno donde los ingenieros puedan experimentar con conceptos de Kubernetes, validar el comportamiento de los despliegues y desarrollar aplicaciones conscientes de la infraestructura sin necesitar un entorno cloud dedicado para cada iteración.
Por qué esto importa a los líderes de ingeniería
Kind es una herramienta para developers, pero los problemas de ingeniería que expone son relevantes para el liderazgo tecnológico.
1. Los entornos de desarrollo afectan la velocidad de ingeniería
Cuando los ingenieros tienen que esperar entornos compartidos, reproducir infraestructura a mano o resolver diferencias entre entornos, el ciclo de feedback del desarrollo se alarga.
Los entornos locales y ligeros de Kubernetes pueden dar a los equipos otra opción para experimentar y validar de forma temprana.
2. La reproducibilidad reduce la fricción de infraestructura
Las configuraciones de Kind se definen de forma declarativa. Una topología de cluster puede representarse en configuración en lugar de recrearse manualmente.
Ese enfoque se alinea con un principio más amplio de platform engineering: hacer que el comportamiento de la infraestructura sea repetible y más fácil de consumir para los equipos de desarrollo.
3. Los entornos locales permiten validar antes
Los clusters multinodo permiten a los ingenieros reproducir localmente escenarios de despliegue más realistas.
Esto no reemplaza la infraestructura ni las pruebas de producción. Lo que aporta es una capa adicional de validación antes de que los cambios pasen a entornos compartidos.
4. El conocimiento de infraestructura es cada vez más parte de la ingeniería de software
Hoy los ingenieros necesitan entender mucho más que el código de la aplicación.
Contenedores, Kubernetes, CI/CD, redes, configuración de despliegues, observabilidad, seguridad y automatización de infraestructura influyen cada vez más en cómo se diseña y se entrega el software.
Por eso la ingeniería cloud-native no es solo una disciplina de infraestructura. Se está convirtiendo en parte del ciclo de vida completo de la ingeniería de software.
¿Qué demuestra esto sobre un socio de ingeniería?
Para los líderes tecnológicos que evalúan un socio de ingeniería de software, la pregunta importante no es si un equipo sabe ejecutar un comando de Kubernetes.
La pregunta de fondo es si el equipo entiende por qué existe la infraestructura, cómo afecta el desarrollo de la aplicación, dónde la automatización puede eliminar fricción y cómo las decisiones de ingeniería impactan la entrega.
En Blue Trail Software, esta perspectiva entre capas es parte de cómo abordamos la ingeniería de software. Nuestras capacidades abarcan desarrollo de software a la medida, DevOps y DevSecOps, QA, ingeniería cloud-native, automatización, IA e IoT.
Esto importa porque los problemas de ingeniería modernos rara vez terminan en los límites de la aplicación.
Un equipo puede estar construyendo una plataforma de IA, un dispositivo conectado, un producto SaaS o una aplicación distribuida, pero el reto de ingeniería suele girar en torno a las mismas preguntas de fondo:
¿Cómo debería diseñarse la arquitectura del sistema?
¿Cómo pueden reproducirse los entornos de forma confiable?
¿Cómo pueden validarse los cambios antes?
¿Cómo pueden automatizarse los flujos de desarrollo e infraestructura?
¿Cómo pueden los equipos avanzar más rápido sin sacrificar calidad ni seguridad?
Kind es un ejemplo pequeño pero práctico de esta mentalidad de ingeniería más amplia.
Kind y el panorama más amplio de platform engineering
El siguiente paso de esta serie lleva la idea mucho más lejos.
Ahora que dominas la creación y gestión de clusters locales de Kubernetes con Kind, estamos listos para dar un gran salto hacia el platform engineering y el desarrollo de controladores nativos.
En el próximo post de la serie dejaremos de ser simples usuarios de Kubernetes para convertirnos en constructores de infraestructura.
Diseñaremos la arquitectura de nuestro propio clon de AWS, inspirado en LocalStack y Floci.
Construiremos una API ligera y un proxy compatible con AWS CLI que interceptará los comandos de AWS CLI y los traducirá en Pods nativos y declarativos, directamente dentro de nuestro nuevo entorno de pruebas en Kind.
Aquí es donde el objetivo original se vuelve especialmente interesante.
No estamos usando Kubernetes solo para desplegar una aplicación.
Estamos explorando cómo el propio Kubernetes puede convertirse en la base del runtime para construir abstracciones de infraestructura.
Esa es una idea central del platform engineering: en lugar de que cada equipo de desarrollo tenga que entender y gestionar por su cuenta cada detalle de la infraestructura, los equipos de ingeniería pueden construir plataformas, abstracciones y flujos reutilizables que hagan más fácil consumir las capacidades de infraestructura.
6. Desmontaje y limpieza rápida
Cuando termines tu sesión de desarrollo y quieras recuperar memoria y CPU en tu máquina local, no hace falta dejar servicios corriendo en segundo plano. Kind limpia todo por sí solo en segundos.
kind delete cluster --name dev-cluster
Este comando detiene y elimina por completo los contenedores de Docker que funcionan como nodos y todos los pods internos, y deja tu máquina host en su estado original sin rastro alguno.
Esa naturaleza desechable es otra razón por la que los entornos locales de Kubernetes son útiles para experimentar: los ingenieros pueden crear un entorno, probar una idea, revisar el resultado y eliminar el entorno al terminar.
Conclusión
Kind es una forma ligera de ejecutar clusters de Kubernetes localmente usando contenedores de Docker. Ofrece a los ingenieros un entorno práctico para aprender Kubernetes, probar aplicaciones cloud-native, experimentar con arquitecturas multinodo e integrar Kubernetes en sus flujos de desarrollo y CI.
Pero la lección más grande va más allá de Kind.
A medida que los sistemas de software se vuelven más distribuidos y la infraestructura es cada vez más programable, los equipos de ingeniería necesitan entender la relación entre el código de la aplicación, los contenedores, la orquestación, la automatización, las pruebas y la infraestructura.
Para los líderes tecnológicos, esa capacidad de ingeniería entre capas puede influir directamente en la velocidad de desarrollo, la consistencia de los entornos, la eficiencia de la infraestructura y la posibilidad de validar decisiones de arquitectura más temprano.
Y, en definitiva, por eso importan herramientas como Kind. No son solo una forma de correr Kubernetes en una laptop.
Son bloques prácticos para construir un enfoque de ingeniería cloud-native más reproducible, automatizado y amigable para los developers.
En Blue Trail Software aplicamos esa mentalidad de ingeniería en desarrollo de software, DevOps/DevSecOps, QA, sistemas cloud-native, automatización y tecnologías emergentes, y ayudamos a los equipos a convertir requerimientos técnicos complejos en software que puede construirse, probarse y evolucionar con confianza.
