Módulo 1: Why Kubernetes And The Continuity Challenge

4. Manos a la obra: instalando `kind` y `kubectl`

Siguiente →

Descripción

Todo lo que sigue en esta guía —desde el primer clúster hasta el capstone completo del Módulo 8— corre sobre dos herramientas, ninguna opcional: kind, que crea un clúster de Kubernetes real dentro de contenedores Docker en tu propia máquina, y kubectl, la interfaz de línea de comandos con la que vas a hablarle a cualquier clúster de Kubernetes, sea kind local o EKS en producción. Esta lección instala ambas, de verdad, en tu máquina, y confirma la versión exacta que vas a usar durante el resto de la guía — todo lo que ves aquí corrió para escribir esta lección, con el detalle honesto de que tu propia salida va a variar en la arquitectura de tu procesador y en detalles menores del empaquetado de tu sistema operativo.

Conexión con el módulo

La lección 3 te dejó con el criterio y el reto de continuidad resueltos, sin haber tocado una terminal todavía. Esta lección es la primera pieza física del laboratorio: sin kind y kubectl instalados, la lección 5 (tu primer clúster) no puede empezar.

Antes de instalar nada: confirma que Docker está corriendo

kind no reemplaza a Docker — lo usa. Cada "nodo" de un clúster kind es, por debajo, un contenedor Docker corriendo una imagen especial (kindest/node) que empaqueta un sistema Kubernetes completo adentro. Sin un motor de Docker corriendo, kind no tiene dónde crear nada.

docker info --format '{{.ServerVersion}}'

Qué esperar (la versión exacta de tu Docker es tu valor variable — lo que importa es que el comando devuelva una versión, no un error de conexión):

29.6.1

Si este comando falla con un error de conexión (Cannot connect to the Docker daemon), abre Docker Desktop (macOS/Windows) o arranca el servicio docker (Linux) antes de seguir — nada de lo que sigue en esta guía funciona sin esto.

Paso 1 — Instala kind

kind (kubernetes-in-docker) es un proyecto oficial de kubernetes-sigs —el mismo espacio de organización de GitHub donde vive el proyecto Kubernetes— pensado específicamente para correr clústeres locales de pruebas y de CI, no como un simulador aparte sino como Kubernetes real empaquetado de forma conveniente. El método de instalación cambia según tu sistema operativo:

macOS o Linux, con Homebrew instalado:

brew install kind

Qué esperar (ejecutado — la ruta exacta de instalación depende de tu configuración de Homebrew, pero la versión del paquete es la misma para todos):

==> Fetching downloads for: kind
✔︎ Bottle kind (0.32.0)
==> Would install 1 formula:
kind
🍺  /opt/homebrew/Cellar/kind/0.32.0: 10 files, 10MB

Linux, sin Homebrew (binario directo):

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.32.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Si tu arquitectura no es amd64 (por ejemplo, un servidor ARM), cambia el sufijo del binario a kind-linux-arm64 — la propia documentación de kind publica un binario por combinación de sistema operativo y arquitectura, nunca un instalador universal.

Windows, con Chocolatey:

choco install kind

En los tres casos, el objetivo es el mismo: un único binario kind en tu PATH. La documentación oficial (enlazada en Recursos) mantiene la lista completa y actualizada de métodos, incluido go install para quien ya tiene una cadena de herramientas de Go configurada.

Verifica la versión

kind version

Qué esperar (go1.26.3 y darwin/arm64 son tu plataforma específica — variable; v0.32.0 es la versión que esta guía usa y verificó, y debe ser esa o más reciente):

kind v0.32.0 go1.26.3 darwin/arm64

Si tu versión es anterior a v0.32.0. No es necesariamente un problema —muchos comandos de esta guía funcionan igual en versiones un poco más viejas—, pero si algo se comporta distinto a lo que describe una lección posterior, actualiza primero (brew upgrade kind o el equivalente de tu gestor de paquetes) antes de reportar el comportamiento como un error de la guía.

Paso 2 — Instala kubectl

kubectl no es específico de kind — es la CLI oficial de todo Kubernetes, el mismo binario que vas a usar contra un clúster EKS real en el Módulo 7. Esta es, de hecho, la razón pedagógica central de que esta guía invierta tanto tiempo en kind: lo que aprendes contra kind transfiere sin traducción a EKS, porque el cliente es idéntico.

macOS o Linux, con Homebrew:

brew install kubectl

Cualquier plataforma, binario directo (el método que documenta kubernetes.io como universal):

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

Cambia darwin/arm64 por tu combinación de sistema operativo y arquitectura (linux/amd64, windows/amd64, etc.) — la documentación oficial de Kubernetes publica la URL exacta para cada una.

Verifica la versión

kubectl version --client

Qué esperar (v1.36.1 es la versión que esta guía usa; Kustomize Version acompaña a kubectl desde hace varias versiones, integrado por defecto):

Client Version: v1.36.1
Kustomize Version: v5.8.1

Fíjate en la bandera --client: sin ella, kubectl version intenta también reportar la versión del servidor —el clúster contra el que estés conectado— y, en este punto de la guía, todavía no creaste ningún clúster. Confírmalo tú mismo:

kubectl version

Qué esperar (el mensaje exacto de error cuando no hay ningún clúster configurado — vas a resolver esto en la lección 5):

Client Version: v1.36.1
Kustomize Version: v5.8.1
The connection to the server localhost:8080 was refused - did you specify the right host or port?

localhost:8080 es la dirección por defecto que kubectl intenta cuando no encuentra ningún archivo de configuración de clúster (~/.kube/config) — literalmente "no sé a quién preguntarle", no un error de tu instalación. La lección 5 resuelve esto exactamente: al crear un clúster con kind, la propia herramienta escribe la configuración necesaria en ese archivo, y este mismo comando (sin --client) va a reportar también la versión del servidor.

Analogía: comprar los tacos y el silbato antes del primer entrenamiento

Instalar kind y kubectl es como comprarte el equipo antes de la primera práctica de un deporte de equipo: los tacos (kind, que va a crear el terreno de juego) y el silbato (kubectl, con el que vas a dar cada instrucción al equipo completo, sin importar si el partido es de práctica en un campo local o el partido real en el estadio grande). Nada de esto es todavía el partido — no vas a ver ningún clúster corriendo hasta la lección 5 —, pero sin este equipo, ni siquiera puedes pisar la cancha. Y, exactamente como un silbato de árbitro sirve igual en cualquier estadio, kubectl funciona idéntico contra el campo de práctica de esta guía (kind) y contra el estadio real de producción (EKS, Módulo 7).

Errores comunes

Instalar el binario de la arquitectura equivocada en Linux o Windows (de instalación, silencioso hasta que falla de forma confusa). Qué pasa: alguien en un servidor con procesador ARM descarga el binario kind-linux-amd64 (el más común en tutoriales, pensado para x86_64), y el binario simplemente no ejecuta, o ejecuta con un comportamiento errático. Por qué pasa: la mayoría de las guías genéricas en internet asumen amd64 porque sigue siendo la arquitectura más común en servidores, pero cada vez más máquinas —incluidas las Mac con Apple Silicon y muchas instancias cloud ARM— usan arm64. Cómo detectarlo: el comando kind version falla con un error de "exec format error" o simplemente "command not found" después de una instalación aparentemente exitosa. Cómo corregirlo: confirma tu arquitectura con uname -m (x86_64 = amd64; aarch64/arm64 = arm64) antes de elegir el binario, y descarga el que corresponde exactamente.

Confundir la ausencia de --client con un error de instalación (conceptual, directamente relacionado con el Paso 2 de esta lección). Qué pasa: alguien corre kubectl version (sin la bandera) inmediatamente después de instalar, ve el error de "connection refused", y concluye que la instalación de kubectl falló. Por qué pasa: el mensaje de error no menciona explícitamente "no tienes ningún clúster todavía" — solo dice que no pudo conectarse a una dirección específica, lo cual suena a un problema de instalación. Cómo detectarlo: si kubectl version --client (con la bandera) sí funciona y muestra la versión correcta, tu instalación está bien — el error solo aparece sin --client, porque ahí kubectl intenta también reportar la versión del servidor. Cómo corregirlo: usa --client hasta que tengas un clúster real (lección 5); después de eso, kubectl version sin la bandera va a funcionar completo, mostrando cliente y servidor.

Olvidar Docker corriendo, y culpar a kind cuando el error real es de Docker (de secuencia, el más común de esta lección completa). Qué pasa: alguien instala kind y kubectl correctamente, pero Docker Desktop está cerrado (o el servicio docker de Linux está detenido), y al intentar cualquier operación de kind en la lección 5, obtiene un error confuso sobre no poder crear contenedores. Por qué pasa: kind version y kubectl version --client —los dos comandos de verificación de esta lección— no necesitan Docker corriendo para funcionar, así que es fácil terminar esta lección pensando que "todo está listo" sin haber confirmado el requisito más importante. Cómo detectarlo: el comando docker info de la sección "Antes de instalar nada" de esta lección falla con un error de conexión. Cómo corregirlo: antes de avanzar a la lección 5, vuelve a correr docker info --format '{{.ServerVersion}}' — si no devuelve una versión limpia, arranca Docker Desktop o el servicio docker de tu sistema antes de continuar.

Ejercicios

Ejercicio 1 — Reconstruye el propósito de cada herramienta sin mirar la lección. En una frase cada una, explica qué hace kind y qué hace kubectl, y por qué son dos herramientas separadas en vez de una sola.

Ver solución

kind crea clústeres de Kubernetes reales dentro de contenedores Docker en tu máquina — es la herramienta que construye el terreno de juego. kubectl habla con cualquier clúster de Kubernetes ya existente, sea creado por kind, por EKS, o por cualquier otro método — es la herramienta que da instrucciones. Son dos herramientas separadas porque resuelven problemas distintos: una es específica de crear clústeres locales de prueba (solo tiene sentido en un contexto de desarrollo/CI), mientras que la otra es universal a cualquier clúster de Kubernetes que exista, sin importar quién ni cómo lo creó — de hecho, kubectl funciona exactamente igual contra un clúster EKS real que nunca usó kind para nada.

Ejercicio 2 — Diagnostica un error real. Un compañero instala kind y kubectl, corre kubectl version (sin --client), y ve: The connection to the server localhost:8080 was refused. Sin mirar la solución de esta lección, explica si esto significa que su instalación falló, y qué comando usarías para confirmar tu diagnóstico.

Ver solución

No significa que la instalación falló — significa que todavía no existe ningún clúster configurado en ~/.kube/config, así que kubectl intenta conectarse a la dirección por defecto (localhost:8080) y, lógicamente, no encuentra nada ahí. El comando que confirma el diagnóstico es kubectl version --client: si ese comando muestra la versión del cliente sin ningún error, la instalación de kubectl está perfectamente bien, y lo único que falta es crear un clúster — exactamente lo que resuelve la lección 5.

Ejercicio 3 — Explica la transferencia de conocimiento a un colega. Un colega pregunta: "si voy a aprender contra kind, local y gratis, ¿ese conocimiento me sirve para trabajar con EKS real en un trabajo?". Respóndele en dos o tres frases, basándote en lo que aprendiste sobre kubectl en esta lección.

Ver solución

Una respuesta completa suena, más o menos, así: "Sí, casi por completo. kubectl es la CLI oficial de Kubernetes en general, no una herramienta específica de kind — el mismo binario, con la misma sintaxis, habla con cualquier clúster de Kubernetes, incluido EKS real. Lo que cambia entre kind y EKS no es cómo interactúas con el clúster (eso es idéntico), sino quién administra el plano de control detrás y cómo se consigue el cómputo — eso lo cubre a fondo el Módulo 7 de esta guía."

Resumen y siguiente paso

En esta lección instalaste, de verdad, las dos herramientas sobre las que corre el resto de esta guía: kind (v0.32.0 o más reciente), que crea clústeres de Kubernetes reales dentro de contenedores Docker, y kubectl (v1.36.1), la CLI oficial de Kubernetes que vas a usar sin cambios contra kind local y, en el Módulo 7, contra el modelo de EKS real. Confirmaste ambas versiones con evidencia literal de tu propia terminal, y viste, de primera mano, el mensaje de error exacto que kubectl muestra cuando todavía no existe ningún clúster — el problema exacto que la lección 5 resuelve.

Antes de avanzar deberías poder: explicar la diferencia de propósito entre kind y kubectl; diagnosticar el error de "connection refused" sin asumir que la instalación falló; y confirmar que Docker está corriendo antes de intentar crear un clúster.

La lección 5 usa estas dos herramientas para crear tu primer clúster real: andes-cargo-cluster, con el mismo nombre que aws-serverless-and-containers-guide dejó documentado, ahora corriendo de verdad.

Recursos

  1. kind — Quick Start — la guía oficial de instalación, fuente de los tres métodos del Paso 1.
  2. kind — Releases — el listado oficial de versiones, incluida v0.32.0.
  3. Kubernetes — Install Tools: kubectl — la guía oficial de instalación de kubectl para cada sistema operativo, fuente del Paso 2.
  4. Docker Docs — docker info — referencia oficial del comando usado en la verificación previa de esta lección.
← Anterior3. El reto de continuidad: recogiendo `andes-cargo-status-api` donde quedóSiguiente →5. Manos a la obra: tu primer clúster