Caso destacado · Infraestructura · Desarrollo activo · Repositorio público
Un laboratorio Kubernetes de tres nodos diseñado para mostrar sus propios límites.
Convertí hardware reutilizado en un clúster k3s de arquitectura mixta y construí una pequeña aplicación basada en colas junto con observabilidad para estudiar la planificación, el autoescalado y los fallos bajo límites reales.
- nodos físicos
- 3
- workers de cola
- 1–5
- estado deseado
- GitOps
- retención de métricas
- 2 días
01 · Contexto
Un lugar para practicar decisiones operativas, no solo despliegues.
Los tutoriales de cloud permiten crear recursos sin sentir el coste de las máquinas subyacentes. Quería un laboratorio donde la arquitectura de CPU, la memoria, el almacenamiento, la red y la recuperación fueran imposibles de ignorar.
El resultado es un pequeño clúster k3s con servicios reales y una carga llamada KubePets. Git contiene el estado deseado y el clúster devuelve información mediante métricas, estado de pods y presión provocada de forma controlada.
02 · Restricciones
El hardware heterogéneo convierte la ubicación en una decisión arquitectónica.
El clúster combina máquinas ARM64 y AMD64 con perfiles de memoria y almacenamiento muy distintos. El nodo menos potente tiene unos 905 MB de memoria, la Pi 5 es el único nodo con NVMe y el servidor HP ejecuta las cargas que necesitan más margen.
- — Nodos ARM64 y AMD64
- — Worker de 905 MB
- — Almacenamiento persistente local
- — Sin puertos entrantes en el router
- — Repositorio público con secretos cifrados
- — Límites ajustados a hardware reutilizado
03 · Arquitectura
Dos flujos convergen en el clúster: estado deseado y tráfico real.
Git y Flux controlan lo que debe existir. Cloudflare Tunnel y Traefik controlan cómo llega el tráfico seleccionado. Las reglas de planificación colocan cada carga donde el hardware puede soportarla o tensionarla de forma deliberada.
Clúster k3s
04 · Implementación
El repositorio describe el sistema desde la entrega hasta la observación.
Flux reconcilia manifiestos de Kubernetes y releases de Helm desde Git. GitHub Actions construye las imágenes, incluidas imágenes multi-arquitectura cuando las cargas pueden ejecutarse en nodos ARM64 o AMD64.
Traefik gestiona el ingreso al clúster. Cloudflare Tunnel aporta conectividad pública solo saliente, cert-manager administra certificados y SOPS mantiene los secretos cifrados en el repositorio público. Prometheus, Grafana, kube-state-metrics, node-exporter y Headlamp muestran el comportamiento sin publicar las interfaces de administración.
Registro de decisiones
Por qué estas elecciones encajan en el laboratorio
Escalar por cola, no por CPU
El worker espera trabajos en Redis, por lo que la CPU no refleja bien el trabajo acumulado. KEDA lee directamente el backlog.
Hacer explícita la planificación
El estado sigue al NVMe de la Pi 5, las interfaces con más consumo usan el HP y los workers de prueba permanecen en la Pi 3B.
Mantener Git público sin publicar secretos
Los manifiestos cifrados con SOPS conservan GitOps mientras el material secreto permanece ilegible en el repositorio.
Usar un túnel solo saliente
Cloudflare Tunnel evita redirigir puertos y permite mantener TLS hasta Traefik para los servicios seleccionados.
05 · Pruebas de fallo
Una cola convierte la presión en algo medible.
KubePets incluye una ruta de carga controlada que publica una ráfaga de eventos en Redis. Los workers consumen la cola y actualizan PostgreSQL. KEDA observa el backlog real en vez de la CPU, porque un worker bloqueado puede usar poca CPU aunque el trabajo se acumule.
El worker está fijado deliberadamente al nodo Raspberry Pi de 905 MB. Así, la presión de memoria y las expulsiones aparecen en Grafana y en el estado de Kubernetes en vez de quedar ocultas en la máquina más capaz.
- 01Publicar una ráfaga controlada de hasta 5.000 eventos en la cola hunger de Redis.
- 02Observar cómo KEDA aumenta el deployment desde una réplica hacia su límite de cinco.
- 03Seguir la cola, los pods y la presión de memoria de la Pi 3B en los paneles provisionados.
- 04Confirmar que los workers vuelven a una réplica al vaciarse la cola y terminar la ventana de 60 segundos.
06 · Resultado
El laboratorio demuestra comportamiento, no solo una lista de herramientas.
Un cambio en el repositorio puede reconciliarse en el clúster, las imágenes se construyen para el hardware previsto, la profundidad de la cola controla las réplicas y los paneles muestran el efecto sobre el nodo limitado. El tráfico público llega a servicios seleccionados sin abrir puertos entrantes en la red doméstica.
El repositorio también registra por qué se fija cada carga, por qué la retención de métricas es corta, por qué algunas imágenes tienen una sola arquitectura y dónde el diseño deja de aspirar a alta disponibilidad de producción.
Evidencia en el repositorio
Sigue la implementación, no una afirmación publicitaria.
Estos enlaces abren la configuración pública exacta que sustenta las afirmaciones principales. Los valores secretos permanecen cifrados y las interfaces privadas no se exponen.
minReplicaCount: 1
maxReplicaCount: 5
pollingInterval: 15
triggers:
- type: redis
metadata:
listName: hunger-queue
listLength: "100"07 · Reflexión
Las limitaciones también forman parte de la evidencia.
No es una plataforma de producción con alta disponibilidad. Tiene un único control plane, el almacenamiento local vincula el estado a una máquina y el worker de poca memoria es frágil a propósito. Explicar estas restricciones resulta más útil que describir el clúster como universalmente resiliente.
Las siguientes mejoras importantes son una ruta de backup y restauración probada, objetivos de recuperación claros y almacenamiento que sobreviva a la pérdida de un nodo. Un segundo control plane solo tendría sentido después de resolver esos fallos más inmediatos.