Kubernetes local sin complicaciones: guía completa de Kind para principiantes
Juan Sebastian Scatularo||11 min de lectura
En la era de la IA, hagamos una pausa para hablar de ingeniería de plataformas.
Desarrollar y probar aplicaciones orientadas a la nube suele ser una carga pesada. Levantar entornos de prueba en proveedores de nube reales como AWS puede volverse caro, lento y difícil de aislar en los flujos de integración continua.
Para los equipos de ingeniería, esto plantea un desafío práctico: ¿cómo conseguir un entorno realista para desarrollar y probar aplicaciones cloud-native sin agregar costos de infraestructura, tiempo de configuración ni complejidad innecesarios?
Por eso, en este artículo vamos a explorar una herramienta esencial para aprender Kubernetes y después daremos un paso más: usaremos Kubernetes como el runtime central para construir nuestro propio clon de AWS, inspirado en LocalStack y Floci.
Se trata de Kind (Kubernetes IN Docker). Es una herramienta oficial del proyecto Kubernetes que permite levantar un clúster completo ejecutando cada nodo como un contenedor de Docker.
En esta serie de artículos vamos a explorar Kind no solo como una herramienta esencial para aprender Kubernetes, sino como el runtime central para construir un proyecto ambicioso: nuestro propio emulador de AWS, ligero y declarativo, inspirado en LocalStack/Floci.
Para los líderes de tecnología, aquí hay una lección de ingeniería más amplia. Las herramientas de infraestructura local como Kind no son simples comodidades para desarrolladores. Pueden ayudar a las organizaciones de ingeniería a crear entornos más reproducibles, acortar los ciclos de retroalimentación de la 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 el desarrollo de software, la ingeniería cloud-native, DevOps, QA, la automatización y la infraestructura. La capacidad de trabajar en todas esas capas importa porque la entrega de software moderna depende cada vez más de qué tan bien interactúan los equipos de aplicaciones con la infraestructura.
Kind es una herramienta que permite levantar un clúster de Kubernetes fácilmente, en minutos y casi sin sobrecarga. Originalmente se diseñó para probar el propio código de Kubernetes, pero puede usarse para mucho más.
Kind frente a Minikube y otras alternativas
Existen varias opciones para iniciar un clúster 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, usa muy pocos recursos y es extremadamente fácil de usar en pipelines de CI.
Minikube:
la opción clásica de siempre. Aunque incluye un driver de Docker, por defecto suele levantar una máquina virtual completa, lo que implica un mayor consumo de CPU y memoria, tiempos de arranque más largos y una sobrecarga innecesaria para nuestro objetivo final.
Docker Desktop:
ofrece un clúster de un solo nodo que se puede activar directamente desde su interfaz. Es muy práctico si ya lo tienes instalado, pero no tiene soporte nativo para topologías complejas de múltiples nodos, por ejemplo.
Si buscas un entorno ligero que simule escenarios reales de producción sin ralentizar tu máquina de desarrollo ni 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 última instancia, un trade-off 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 desarrolladores y los sistemas de CI puedan usarlo sin una sobrecarga excesiva de infraestructura.
Kind resuelve ese trade-off ejecutando los nodos de Kubernetes como contenedores. Eso lo hace especialmente útil cuando los ingenieros necesitan reproducir entornos de Kubernetes de forma local, experimentar con configuraciones de múltiples nodos o integrar pruebas basadas en Kubernetes en flujos de trabajo automatizados.
Para los líderes de tecnología, esto se traduce en una consideración más amplia: la productividad de la 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 a usar Kind, necesitas tener tres herramientas esenciales instaladas y configuradas.
Docker:
el motor que ejecutará los contenedores que funcionan como tus nodos
kubectl:
la herramienta de línea de comandos para interactuar con tu clúster de Kubernetes
kind:
el binario que orquestará la creación de tus clústeres locales
freelens
o
k9s:
CLI de Kubernetes para gestionar tus clústeres con estilo (opcional)
Instalación en Linux
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 clúster básico con un solo nodo que funcione como plano de control y como worker a la vez, simplemente ejecuta:
kind create cluster --name my-cluster
Kind se encargará de descargar la imagen necesaria (que contiene todo el ecosistema de Kubernetes), preparar los certificados, inicializar el plano de control y configurar tu archivo local ~/.kube/config para que kubectl apunte automáticamente a este nuevo clúster.
Este flujo de trabajo sencillo muestra una de las mayores ventajas de Kind: los ingenieros pueden crear un entorno de Kubernetes desechable sin aprovisionar manualmente un stack completo de infraestructura en la nube.
Creación avanzada: configuración de múltiples nodos
Una de las mayores fortalezas de Kind es lo fácil que hace simular topologías de producción realistas en tu máquina local.
Al crear un archivo de configuración YAML, podemos definir exactamente cuántos nodos de plano de control y cuántos workers queremos en nuestro laboratorio.
Este manifiesto le indica a Kind que queremos desplegar un clúster compuesto por tres contenedores: un plano de control y dos nodos worker independientes.
Ahora inicialicemos el clúster usando esta configuración específica:
Cuando termine el arranque, podemos verificar que el clúster se levantó correctamente con comandos de inspección:
# List clusters managed by Kind
kind get clusters
# List nodes detected by Kind
kind get nodes
# Verify node status at the Kubernetes level with kubectl
kubectl get nodes
¿Por qué importa un clúster local de múltiples nodos?
Aquí es donde un entorno local de Kubernetes se vuelve más que una herramienta de aprendizaje.
Un clúster de múltiples nodos permite a los ingenieros experimentar con topologías de infraestructura más cercanas a los entornos distribuidos reales. En lugar de descubrir problemas de configuración o de despliegue cuando una 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 resolución de problemas dependiente de la infraestructura que tiene que hacerse más adelante en el proceso de entrega.
También demuestra una capacidad de ingeniería importante: entender cómo interactúan el comportamiento de la aplicación, la configuración de 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 esa etiqueta de imagen, lo aplicas, y tus Pods quedan atascados indefinidamente en un ciclo con el error ErrImagePull o ImagePullBackOff.
¿Por qué pasa esto? El clúster 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 intenta encontrar y descargar tu imagen my-app:1.0 desde registros públicos en internet, como Docker Hub.
La solución: Kind incluye una utilidad específica que toma la imagen del Docker local de tu host y la inyecta directamente en el motor de Docker interno que corre dentro de los nodos del clúster.
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 exactamente el tipo de interacción con la infraestructura que puede generar fricción en un flujo de trabajo 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 visión de la imagen.
Entender estos límites es parte de una ingeniería cloud-native efectiva.
Para los equipos que construyen y prueban aplicaciones modernas, estos problemas de entorno aparentemente pequeños pueden acumularse hasta convertirse en una fricción de desarrollo significativa. Por eso los entornos reproducibles y los flujos de trabajo bien diseñados para desarrolladores son temas de ingeniería de plataformas, no simples preferencias de herramientas.
5. Recorrido práctico: 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.
Para obtener el estado y verificar que tu Pod y tu Service estén activos y en buen estado:
kubectl get pods
kubectl get svc
Acceso directo con port-forward
Como definimos nuestro servicio como ClusterIP (accesible solo dentro de la red del clúster de Kubernetes), podemos crear un túnel rápido y temporal desde nuestra máquina host con la función nativa de port-forwarding de kubectl:
kubectl port-forward svc/nginx-service 8080:80
Ahora abre tu navegador preferido y entra a:
http://localhost:8080
Deberías ver la clásica pantalla de bienvenida de Nginx, servida de forma nativa desde dentro de tu clúster local de Kind.
¿Qué demostramos realmente?
Aunque este ejemplo es sencillo a propósito, el flujo de trabajo representa un patrón fundamental del desarrollo cloud-native:
La aplicación se describe de forma declarativa mediante manifiestos de Kubernetes, se despliega en un clúster local, se inspecciona con comandos de Kubernetes y se valida desde la máquina del desarrollador.
Esa misma mentalidad se vuelve cada vez más importante a medida que las aplicaciones se vuelven más distribuidas y la infraestructura más automatizada.
Para las organizaciones de ingeniería, el valor no está solo en poder ejecutar Nginx de forma local. El valor está en tener 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 dedicado en la nube para cada iteración.
Por qué esto importa a los líderes de ingeniería
Kind es una herramienta para desarrolladores, pero los problemas de ingeniería que pone en evidencia son relevantes para el liderazgo tecnológico.
1. Los entornos de desarrollo afectan la velocidad de la ingeniería
Cuando los ingenieros tienen que esperar entornos compartidos, reproducir infraestructura manualmente o resolver diferencias entre entornos, el ciclo de retroalimentación del desarrollo se alarga.
Los entornos locales y ligeros de Kubernetes pueden darles 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 clúster puede representarse en una configuración en lugar de recrearse manualmente.
Ese enfoque se alinea con un principio más amplio de la ingeniería de plataformas: 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 pueden apoyar una validación más temprana
Los clústeres de múltiples nodos permiten a los ingenieros reproducir localmente escenarios de despliegue más realistas.
Esto no reemplaza la infraestructura ni las pruebas de producción. En cambio, ofrece otra capa 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
Los ingenieros modernos a menudo necesitan entender algo más que el código de la aplicación.
Los contenedores, Kubernetes, CI/CD, las redes, la configuración de despliegue, la observabilidad, la seguridad y la automatización de la infraestructura influyen cada vez más en cómo se diseña y entrega el software.
Por eso la ingeniería cloud-native no es simplemente una disciplina de infraestructura. Se está convirtiendo en parte del ciclo de vida más amplio de la ingeniería de software.
¿Qué demuestra esto sobre un socio de ingeniería?
Para los líderes de tecnología que evalúan un socio de ingeniería de software, la pregunta importante no es si un equipo puede ejecutar un comando de Kubernetes.
La pregunta más importante 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 afectan la entrega.
En Blue Trail Software, esta perspectiva que abarca todas las capas es parte de cómo abordamos la ingeniería de software. Nuestras capacidades incluyen desarrollo de software a la medida, DevOps y DevSecOps, QA, ingeniería cloud-native, automatización, IA e IoT.
Eso importa porque los problemas de ingeniería modernos rara vez se detienen en el límite 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 desafío de ingeniería a menudo implica las mismas preguntas de fondo:
¿Cómo debería diseñarse la arquitectura del sistema?
¿Cómo se pueden reproducir los entornos de forma confiable?
¿Cómo se pueden validar los cambios antes?
¿Cómo se pueden automatizar los flujos de trabajo 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 la ingeniería de plataformas
El siguiente paso de esta serie lleva la idea mucho más lejos.
Ahora que dominas la creación y gestión de clústeres locales de Kubernetes con Kind, estamos listos para dar un gran salto hacia la ingeniería de plataformas y el desarrollo de controladores nativos.
En el siguiente artículo de la serie, dejaremos de ser simples usuarios de Kubernetes y nos convertiremos 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 con 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 de ejecución para construir abstracciones de infraestructura.
Esa es una idea central de la ingeniería de plataformas: en lugar de que cada equipo de desarrollo tenga que entender y gestionar cada detalle de la infraestructura por su cuenta, los equipos de ingeniería pueden construir plataformas, abstracciones y flujos de trabajo reutilizables que hagan más fácil consumir las capacidades de infraestructura.
6. Desmontaje y limpieza rápidos
Cuando termines tu sesión de desarrollo y quieras recuperar memoria y recursos de CPU en tu máquina local, no hace falta dejar servicios corriendo en segundo plano. Kind limpia todo por sí solo en cuestión de 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 devuelve tu máquina host a su estado original sin dejar rastro.
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, inspeccionar el resultado y eliminar el entorno al terminar.
Conclusión final
Kind es una forma ligera de ejecutar clústeres de Kubernetes de forma local usando contenedores de Docker. Ofrece a los ingenieros un entorno práctico para aprender Kubernetes, probar aplicaciones cloud-native, experimentar con arquitecturas de múltiples nodos e integrar Kubernetes en los flujos de trabajo de desarrollo y de CI.
Pero la lección más importante va más allá de Kind.
A medida que los sistemas de software se vuelven más distribuidos y la infraestructura 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 de tecnología, esa capacidad de ingeniería que abarca todas las capas puede influir directamente en la velocidad de desarrollo, la consistencia de los entornos, la eficiencia de la infraestructura y la capacidad de validar antes las decisiones de arquitectura.
Y esa es, en última instancia, la razón por la que herramientas como Kind importan. No son solo formas de ejecutar Kubernetes en una laptop. Son bloques de construcción prácticos para un enfoque de ingeniería cloud-native más reproducible, automatizado y amigable para los desarrolladores.
En Blue Trail Software, aplicamos esa mentalidad de ingeniería en el desarrollo de software, DevOps/DevSecOps, QA, sistemas cloud-native, automatización y tecnologías emergentes, ayudando a los equipos a convertir requisitos técnicos complejos en software que se pueda construir, probar y evolucionar con confianza.
Blue Trail Software Holding Inc.
Dirección:
182 Howard Street, Suite 226 San Francisco, CA 94105, USA
