Laboratorio de Kubernetes: un clúster k3s de un nodo para cada alumno en una VM Ubuntu privada

Este laboratorio da a cada alumno un clúster de Kubernetes propio. k3s, un Kubernetes pequeño, funciona en la única VM Ubuntu del alumno como un solo nodo, y el alumno trabaja con el kubectl de verdad: pone en marcha servidores web con un Deployment, ve cómo Kubernetes devuelve un pod que se ha borrado, da un solo nombre a los pods con un Service, les pasa un ConfigMap y averigua por qué un pod no arranca.

No se instala nada en el ordenador del alumno y no se comparte nada con otros alumnos: un error cuesta un clúster, y el laboratorio se puede volver a empezar.

Qué aprenden los alumnos

Qué hace Kubernetes: tú dices qué debe estar funcionando y él lo mantiene funcionando. En cinco partes. Primero un recorrido por el clúster, su nodo, sus espacios de nombres y los pods que Kubernetes arranca por sí mismo. Después un Deployment de tres servidores web, que se escala hacia arriba y hacia abajo y al que se borra un pod para verlo volver. Después un Service, que da a los pods un solo nombre que otro pod encuentra con el DNS propio del clúster. Después un ConfigMap, cuyas palabras acaban en cada página, y el hecho de que un pod en marcha no ve un cambio hasta que se sustituye. Por último tres Deployments rotos, cada uno a su manera, que hay que arreglar leyendo kubectl describe y kubectl logs.

Qué hay en la máquina

Un nodo, k3s versión 1.35, instalado por el script del laboratorio desde las versiones públicas del proyecto k3s en GitHub. Los archivos se fijan por sus sumas de comprobación, las que publica la versión, y cualquier otro archivo se rechaza. Traefik, el balanceador de servicios y el servidor de métricas están desactivados para caber en la memoria, así que no hay Ingress ni kubectl top. Están kubectl, crictl y ctr.

La VM del alumno llega al archivo de paquetes de Ubuntu, PyPI, npm y GitHub, y a ningún registro de imágenes. Por eso todos los pods de este laboratorio ejecutan la única imagen que viene con k3s, busybox versión 1.37.0, que tiene sh, httpd, wget y nslookup, y es todo lo que las lecciones necesitan. Un pod que pide una imagen como nginx se queda en ImagePullBackOff, algo que el README dice en sus primeras líneas.

Ejecútalo en tu navegador

Los laboratorios VM se ponen como tarea de laboratorio en un módulo, y el ejemplo está en la página del laboratorio. La máquina pide 2 CPU, 2 GB de memoria y 10 GB de disco. k3s usa alrededor de medio gigabyte cuando no corre nada en él, y el resto es para los pods y Ubuntu.

  1. Añadir el laboratorio. En un módulo que impartas, añade una tarea y elige la tarjeta de laboratorio VM Ubuntu. La página muestra una descripción corta de la máquina en lugar de un archivo compose.
  2. Empezar desde el ejemplo. La página ofrece laboratorios ya hechos. Elige Kubernetes con k3s. Usar un ejemplo sustituye el texto, y Deshacer devuelve el tuyo.
  3. Publicar y arrancar tu propia copia. Publica y luego pulsa Iniciar. El script de preparación del laboratorio descarga k3s de sus versiones públicas en GitHub la primera vez que arranca la VM, unos 270 MB, y escribe el comando k3slab, los dos archivos de trabajo y el README. El clúster está listo unos minutos después.
  4. Abrir el terminal. Abre su terminal, ejecuta k3slab status hasta que diga que el clúster está listo y lee README.md en la carpeta personal: explica qué hacer en cinco partes y no da ninguna respuesta.

Quién puede ejecutarlo

El laboratorio necesita los 2 GB, que es la máquina de una cuenta de centro. En una cuenta gratuita la máquina es de 1 GB: el laboratorio no arranca k3s por sí solo y lo dice, y sudo k3slab install --anyway es para el alumno que quiera probar, sin promesa de que aguante. Un visitante sin cuenta tiene 1 GB y solo llega al archivo de Ubuntu, así que no se puede descargar k3s. Pon el laboratorio a una clase de un centro.

Una lección básica en este laboratorio

Kubernetes Basics es una lección pequeña que se da en este laboratorio, una VM Ubuntu. Tiene un gancho, un objetivo «puedo», palabras clave, un calentamiento, una comprobación tras cada idea, un error frecuente y una comprobación final, y cada paso tiene un botón Ejecutar que escribe su comando en el terminal de la máquina. El alumno lee el nodo y los pods del sistema, crea un Deployment de tres pods, borra los pods y ve aparecer tres nuevos, y escala a cinco.

La lección trabaja en un espacio de nombres propio y lo borra, y deja al alumno la tarea del laboratorio, el Service, el ConfigMap y los Deployments rotos, así que no da respuestas.

Cómo se califica

El laboratorio tiene una comprobación. Se ejecuta en una copia de la máquina guardada tras un arranque nuevo, espera a que k3s arranque con el trabajo del alumno todavía dentro y pregunta al clúster, no a los archivos. El Deployment web debe tener tres pods listos y el Service web debe enviar el puerto 80 al puerto 8080 de los tres. Luego un pod del clúster pide http://web doce veces: el nombre debe funcionar, las respuestas deben venir de más de un pod y cada página debe mostrar las palabras del ConfigMap. Después la comprobación cambia el ConfigMap por una palabra que nadie ha visto y borra un pod: el Deployment debe traer uno cuya página muestre la palabra nueva, algo que una página escrita en el Deployment nunca consigue. Por último los tres Deployments rotos deben funcionar, y el tercero debe decir en su registro que está listo. La primera línea de lo que imprimió la comprobación dice por qué no pasó.

La comprobación dispone de tres minutos, así que el alumno debe parar el laboratorio con el clúster en marcha y dejar que arranque.

  1. Repartirlo. Asigna el laboratorio como cualquier tarea, con fecha de entrega si quieres. Cada alumno tiene su propia VM, conservada entre sesiones, y el clúster está en su disco.
  2. Ejecutar la comprobación. En la fila de un alumno en la lista de la clase, pulsa Ejecutar la comprobación. Arranca una copia de su máquina guardada que no se vuelve a guardar, espera a que el clúster arranque, le pregunta y muestra si ha pasado, qué imprimió y cuándo. Al alumno no se le comunica el resultado.
  3. Calificarlo. Lee la primera línea de lo que imprimió la comprobación: dice qué no está bien, por ejemplo que no hay un Service llamado web, una página que no muestra el ConfigMap o un Deployment roto que sigue sin funcionar. Devuelve el trabajo con un motivo si necesita más.

La definición en GitHub

El archivo es toda la definición del laboratorio, el mismo texto que ejecuta la plataforma: tamaño, script de preparación, el comando k3slab, los dos archivos de trabajo, README y comprobación. Cópialo y cambia los Deployments, o las averías de broken.yaml, para hacer un laboratorio más largo.

Prueba este laboratorio, y lo que cuesta

Con una cuenta personal gratuita puedes seguir las lecciones básicas de este laboratorio, con crédito gratuito suficiente cada mes para seguir la mayoría de las lecciones y sin tarjeta. Para una clase, un centro tiene gratis sus primeros 365 días, hasta 50 alumnos, y después paga por alumno y año, con todos los laboratorios incluidos y el profesorado gratis.

Preguntas frecuentes

¿El laboratorio de Kubernetes necesita una licencia?
No. k3s es software libre con licencia Apache 2.0 y se descarga de las versiones del propio proyecto k3s cuando arranca la VM del alumno; nosotros no distribuimos nada. Las imágenes de su paquete son las del proyecto y no se modifican.
¿Por qué los pods usan busybox y no nginx?
La VM del alumno no llega a ningún registro de imágenes, así que un pod solo puede ejecutar una imagen que la máquina ya tiene. k3s trae un pequeño conjunto, y busybox es la que sirve para algo: sirve una página web, descarga una y resuelve nombres. Todo lo de los Deployments, Services y ConfigMaps es igual sea cual sea la imagen.
¿Pueden los alumnos estropear algo?
Solo su propia copia. El clúster es un nodo dentro de la VM, que llega al archivo de Ubuntu, PyPI, npm y GitHub y a nada más. Si un alumno rompe el clúster, k3slab files devuelve los dos archivos a su sitio, y kubectl delete namespace lab empieza otra vez los ejercicios.
¿Puede usarlo un alumno con cuenta gratuita?
No de forma fiable. La máquina de una cuenta gratuita tiene 1 GB y k3s necesita unos 2 GB con algunos pods, así que el laboratorio no lo arranca por sí solo en esa máquina. La máquina de una cuenta de centro tiene 2 GB, que es lo que pide el laboratorio.
¿Se probó el laboratorio en una VM de alumno real?
La preparación con sus descargas reales, los comandos de la lección y la comprobación, con todas las formas de engañarla, se ejecutaron en un Ubuntu 26.04 real con k3s en marcha, en un contenedor que hace de VM. Una VM de alumno realmente arrancada, que inicia k3s desde una unidad de systemd, con 2 GB y el proxy de red de la plataforma, merece una prueba antes de una clase.