Kubernetes sin internet: EKS air-gapped con Spinifex

En pocas palabras: Spinifex, plataforma open source de Mulgadc escrita en Go (AGPL-3.0) presentada el 27 de agosto de 2026, corre Kubernetes sin internet: instala un entorno compatible con AWS y EKS desde un tarball y paquetes pre-descargados transferidos por USB, sirviendo imágenes desde un registro ECR-compatible local.

Correr Kubernetes sin internet es más difícil de lo que parece, y Spinifex apunta a resolverlo: una plataforma open source escrita en Go (licencia AGPL-3.0) que instala un entorno compatible con AWS y con EKS gestionado, sin conexión, usando un tarball y paquetes pre-descargados que transferís por USB. El proyecto es de Mulgadc y su documentación salió con la nota técnica del 27 de agosto de 2026.

Kubernetes sin internet es un cluster de Kubernetes que corre en hardware aislado de la red pública, donde ni el proceso de instalación ni los workloads necesitan salir a internet. Spinifex logra esto instalando desde un tarball de release y paquetes pre-staged, y sirviendo las imágenes de contenedores desde un registro local ECR-compatible en la misma LAN. El único punto que sí pide salida temporal es el bootstrap del plano de control de EKS.

¿Qué significa air-gapped en Kubernetes?

Air-gapped significa que la máquina no tiene ninguna ruta hacia internet: ni el instalador ni los servicios pueden llamar afuera. El problema es que Kubernetes está diseñado al revés. Tira imágenes de contenedores desde registros, los componentes del plano de control hacen llamadas durante el bootstrap, y el tooling de configuración de nodos asume que llega a los repositorios de paquetes. Todo el ecosistema se apoya en la conectividad.

Ahora bien, hay grados de desconexión. Y acá está la parte interesante: Spinifex no maneja todos igual.

La plataforma base (el gateway AWS, compute, block storage, object storage, networking e IAM) instala y corre con cero conectividad. Una vez que transferiste el tarball y las dependencias, nada del proceso de instalación toca internet. Hay un flag que hasta suprime el “beacon” de telemetría de instalación, esa primera llamada que muchos instaladores hacen sin avisar.

Eso sí: los clusters EKS tienen una restricción documentada. El plano de control necesita egress durante el bootstrap. La guía de troubleshooting de EKS lo marca como comportamiento esperado del release actual. Una vez que el cluster llega al estado activo, tus workloads corren en una LAN sin rutas externas, siempre que las imágenes estén disponibles localmente (pre-descargadas o servidas desde una instancia ECR de Spinifex en la misma red).

La diferencia entre “sin internet” y “con internet limitado” acá es concreta: la plataforma carece de conectividad de punta a punta, pero EKS pide una ventana breve de salida solo en el arranque del cluster. Después, nada.

¿Para qué sirve Kubernetes en entornos desconectados?

Sirve para correr una plataforma de contenedores productiva en hardware que nunca toca internet, algo obligatorio en defensa, ambientes clasificados e industrias críticas donde el requisito de seguridad es controlar físicamente el equipo. El texto de Mulgadc lo dice directo: entornos “de defensa, industriales y clasificados donde el requisito de seguridad es hardware que poseés y controlás”. Complementá con opciones de infraestructura disponibles.

Ponele que trabajás en una red militar o financiera donde el reglamento prohíbe cualquier ruta hacia afuera. La alternativa clásica son proxies caros y frágiles, o directamente evitar Kubernetes y usar una distro más simple que después no se parece en nada a lo que corrés en la nube. Ninguna de las dos convence.

• Defensa y ambientes clasificados: el dato no puede salir de la red bajo ningún concepto, y el hardware tiene que ser propio y auditable.
• Industria crítica: plantas y sistemas OT donde la conexión externa es un vector de ataque que directamente se elimina.
• Sector financiero: cargas regulatorias que exigen aislamiento de infraestructura sensible.

El punto es que estas organizaciones ya invirtieron en gente que sabe operar AWS. Tirar todo ese conocimiento por la borda para armar un stack paralelo es un costo enorme que casi nadie quiere pagar.

¿Qué es Spinifex y cómo funciona?

Spinifex es una plataforma cloud AWS-compatible, open source, escrita en Go y con licencia AGPL-3.0, desarrollada por Mulgadc. Replica la superficie de API de AWS (gateway, compute, block y object storage, networking e IAM) y provee una implementación compatible con EKS, para que tengas Kubernetes gestionado en hardware que nunca sale de tu red. El código completo está en GitHub.

La lógica de fondo es simple pero potente: si la API, los comandos y el modelo de permisos son idénticos a los de AWS, tu equipo no reaprende nada. Corrés los mismos aws eks, definís los mismos recursos Terraform, usás el mismo modelo IAM. La plataforma en sí no necesita conectividad para operar día a día.

Para cualquiera que haya peleado con distros de Kubernetes que prometían ser “simples” y después no se parecían a nada del mundo real, esto cambia bastante la ecuación. La compatibilidad es el producto.

¿Cómo preparar la instalación offline de Spinifex?

La preparación se hace en dos fases: primero juntás todo en una máquina con internet, después transferís y instalás en el servidor aislado. En la máquina conectada bajás el tarball de release de Spinifex, el script de instalación, el checksum SHA-256, los paquetes APT que el instalador necesita, el AWS CLI v2 y la imagen cloud que vas a usar como sistema operativo invitado para las VMs.

Los paquetes APT no son pocos ni triviales. Según la guía oficial de instalación air-gapped, el instalador pide toda esta lista, que descargás al cache de APT sin instalarla (así no tocás la máquina conectada):

• Virtualización: qemu-system-x86, qemu-utils, ovmf, qemu-efi-aarch64, libvirt-daemon-system, libvirt-clients, libvirt-dev.
• Networking: ovn-central, ovn-host, openvswitch-switch, dhcpcd-base, iproute2, netcat-openbsd.
• Bloques y NBD: nbdkit, nbdkit-plugin-dev, pkg-config.
• Utilidades de build: make, gcc, jq, curl, wget, unzip, xz-utils, file.

La imagen cloud recomendada en la guía es Debian 13 (Trixie) genericcloud amd64. Después armás la estructura de carpetas en el medio de transferencia (tarball, apt-packages, aws, images) y copiás cada cosa a su lugar. Nada glamoroso, pero es el orden que evita que después falte algo en el server aislado.

¿Cómo instalar Spinifex en un servidor air-gapped?

En el servidor desconectado montás el USB, instalás los paquetes APT desde el cache local, instalás el AWS CLI y corrés el instalador apuntándolo al tarball local con las descargas suprimidas. La secuencia usa tres variables clave: INSTALL_SPINIFEX_TARBALL apuntando al tarball, más INSTALL_SPINIFEX_SKIP_APT e INSTALL_SPINIFEX_SKIP_AWS para saltear los pasos de descarga. Tema relacionado: resolver problemas de conectividad.

El truco al instalar los .deb del cache es usar el flag que le dice a apt que resuelva las dependencias pendientes solo con lo que ya está en el cache local. ¿Y qué pasa si falta una dependencia? Simple: la instalación se corta y tenés que volver a la máquina conectada, agregarla al paso de descarga y re-armar el medio. Por eso vale la pena ser prolijo en la fase anterior.

El script setup.sh maneja la escalada de privilegios internamente y termina lanzando un subshell para que tu shell tome la membresía de grupo necesaria (el AWS CLI la precisa para leer los certificados TLS). Después configurás el networking OVN con setup-ovn.sh, inicializás sin telemetría y arrancás los servicios con systemctl start spinifex.target.

Falta importar la imagen cloud desde el USB con spx admin images import. Para verificar que todo quedó bien, corrés dos comandos:

• aws ec2 describe-instance-types: si devuelve data, el gateway AWS está arriba.
• aws ec2 describe-images: si devuelve data, la imagen quedó registrada.

Con las dos respondiendo, tenés una plataforma cloud AWS-compatible funcionando sobre hardware aislado. (Sí, en serio, sin una sola llamada a internet.)

¿Cómo crear y gestionar clusters EKS en Spinifex?

Los clusters se crean con el workflow estándar del AWS CLI: el perfil spinifex apunta todas las llamadas de API al gateway local en el puerto 9999. Antes de crear nada, tenés que confirmar que la imagen del nodo EKS esté registrada, porque Spinifex bloquea la creación del cluster si no está presente. La buscás filtrando por el tag spinifex:managed-by=eks.

Si la imagen del nodo EKS no está en tu catálogo, la stageás en el medio de transferencia junto con las otras imágenes cloud y la importás con spx admin images import antes de seguir. Sin ese paso, ni arrancás.

Con la imagen en su lugar, el aws eks create-cluster lleva un detalle importante: el flag authenticationMode=API es obligatorio, porque Spinifex implementa el modelo de access-entry en vez del viejo enfoque del ConfigMap aws-auth. Los roles IAM van con ARNs tipo eks-cluster-role y eks-node-role, y las subnets son las locales. Esto se conecta con lo que analizamos en arquitecturas DevOps modernas.

Acá aparece el único momento donde la desconexión total no aplica: durante el bootstrap, el plano de control necesita egress. La subnet donde cae tiene que tener una ruta a un internet gateway, o confirmás la ruta de forma temporal. Una vez que el cluster llega al estado activo, el plano de control ya no necesita conectividad para su propia operación. Después creás el nodegroup con aws eks create-nodegroup y actualizás el kubeconfig con aws eks update-kubeconfig.

¿Cómo ejecutar workloads sin conectividad externa?

Una vez que el cluster está activo, la pregunta que traba todo en ambientes desconectados es la disponibilidad de imágenes. Los pods de Kubernetes tiran imágenes cuando arrancan, y sin internet los nodos necesitan llegar a una fuente local. Spinifex incluye un registro de contenedores ECR-compatible para hostear imágenes en la misma red que el cluster.

El flujo es directo: pusheás las imágenes a una instancia ECR local de Spinifex, configurás los pod specs para que tiren de ahí, y listo. Todo el ciclo de vida del workload, desde el push de la imagen hasta el deployment, se queda dentro de la red local. Cero dependencia de Docker Hub, GitHub Container Registry o cualquier registro externo.

Pensalo así. Subís la imagen al ECR local, la referenciás en el pod spec, el nodo la tira desde la misma LAN, el pod arranca, todo sin que un solo byte salga de la red, que es exactamente lo que un ambiente clasificado necesita para dormir tranquilo. Esa oración larga es todo el modelo mental que precisás.

Spinifex frente a otras opciones de Kubernetes aislado

La ventaja diferencial de Spinifex es la continuidad operativa: quien opera EKS en AWS opera EKS en Spinifex sin curva de reaprendizaje. La tabla resume cómo se posiciona frente a los enfoques típicos que se usan hoy para air-gap.

Enfoque	Compatibilidad AWS/EKS	Conectividad en install	Curva de reaprendizaje
Spinifex	Idéntica (CLI, Terraform, IAM)	Cero (solo bootstrap EKS pide egress)	Nula para equipos AWS
Distro K8s simple + proxies	Ninguna	Proxies caros y frágiles	Alta (stack paralelo)
Mirror de registros manual	Parcial	Requiere sincronización periódica	Media

El valor no está en una feature suelta. Está en que la API, los comandos CLI, los tipos de recurso Terraform y el modelo IAM son iguales a los de AWS. Eso evita armar un cuerpo de conocimiento separado o vivir con un set de features recortado.

Errores comunes al montar Kubernetes sin internet

El air-gap castiga los descuidos. Estos son los tropiezos que aparecen una y otra vez: En configurar DNS en redes aisladas profundizamos sobre esto.

• Asumir que EKS bootstrapea 100% offline: no. El plano de control pide egress durante el arranque. Corregí planificando una ruta temporal por internet gateway en esa subnet y sacándola después.
• Stagear paquetes APT incompletos: si falta una dependencia, el install se corta en el server aislado. Corregí agregándola al paso de descarga en la máquina conectada y re-armando el medio; el flag de solo-cache no inventa lo que no está.
• Olvidar la imagen del nodo EKS: Spinifex bloquea la creación del cluster si la imagen taggeada como spinifex:managed-by=eks no está registrada. Corregí importándola con spx admin images import antes de crear el cluster.
• Usar el modo de auth viejo: pasar por alto authenticationMode=API falla, porque Spinifex usa access-entry y no el ConfigMap aws-auth. Corregí incluyendo el flag en el create-cluster.

Qué significa para equipos en Latinoamérica

Para organismos públicos, bancos e industria de la región con requisitos de soberanía de datos o aislamiento de red, este enfoque baja una barrera concreta. Si tu equipo ya sabe operar EKS, no necesita aprender un stack nuevo para correrlo en infraestructura propia y desconectada. El conocimiento se transfiere tal cual.

Y para proyectos que no exigen air-gap total pero sí infraestructura local confiable, tener servidores, cloud o VPS en un proveedor regional como donweb.com es una base sólida para montar entornos de contenedores sin depender de latencias intercontinentales. El air-gap es un extremo del espectro; la mayoría de los proyectos vive más acá.

Preguntas Frecuentes

¿Qué significa air-gapped en Kubernetes?

Air-gapped significa que el hardware no tiene ninguna ruta hacia internet, ni durante la instalación ni durante la operación. En Kubernetes esto es difícil porque los pods tiran imágenes de registros externos y los componentes hacen llamadas al arrancar. Un entorno air-gapped resuelve las imágenes con un registro local y transfiere las dependencias por medios físicos como USB.

¿Qué es Spinifex?

Spinifex es una plataforma cloud AWS-compatible open source, escrita en Go y licenciada bajo AGPL-3.0, desarrollada por Mulgadc. Provee gateway AWS, compute, storage, networking e IAM, más una implementación compatible con EKS, todo capaz de instalarse y correr sin conexión a internet. El código está en GitHub bajo el repositorio mulgadc/spinifex.

¿Cuánto cuesta Spinifex?

Spinifex es open source con licencia AGPL-3.0, así que el software no tiene costo de licencia. El costo real está en el hardware propio que ejecuta la plataforma y en la operación, que es justamente el requisito de seguridad que buscan los entornos de defensa e industriales: infraestructura que poseés y controlás.

¿Kubernetes air-gapped necesita internet en algún momento?

Con Spinifex, la plataforma base no necesita internet en ningún momento. La única excepción documentada es el bootstrap del plano de control de EKS, que requiere egress temporal durante el arranque del cluster. Una vez que el cluster está activo, opera sin conectividad externa mientras las imágenes estén disponibles en un registro local.

¿Cómo se gestionan las imágenes de contenedores sin internet?

Se gestionan con un registro ECR-compatible local que Spinifex incluye. Pusheás las imágenes a esa instancia en la misma red del cluster y configurás los pod specs para que tiren de ahí. Todo el ciclo, desde el push hasta el deployment, queda dentro de la LAN, sin depender de Docker Hub ni GitHub Container Registry.

Conclusión

Lo que cambia con Spinifex es que dejás de elegir entre “Kubernetes real” y “Kubernetes que puedo aislar”. La plataforma corre offline de punta a punta (con la salvedad del bootstrap de EKS) y mantiene una compatibilidad total con AWS: mismos comandos, mismo Terraform, mismo IAM. Para defensa, industria crítica y finanzas, eso significa una plataforma productiva sin armar un stack paralelo ni resignar features.

Si te toca este tipo de entorno, el paso concreto es probar la instalación air-gapped en un servidor aislado siguiendo las dos fases, prestando atención a stagear la lista completa de paquetes APT y la imagen del nodo EKS. Ahí es donde la mayoría se traba. Tomá los benchmarks operativos con pinzas hasta correrlo vos mismo: el proyecto es reciente y la restricción del bootstrap indica que todavía hay aristas por pulir.

Fuentes

• Spinifex en GitHub (mulgadc/spinifex) – repositorio oficial, código Go y licencia AGPL-3.0
• Guía oficial de instalación air-gapped – documentación de Mulgadc
• Running Kubernetes in an Air-Gapped Environment With Spinifex – nota técnica (27/08/2026)