Controlador Ingress en Rust/Go: 11% más rápido que Nginx
Un desarrollador conocido como SysAlchemist publicó el 17 de mayo de 2026 el relato técnico de cómo construyó Silex, un controlador Ingress Kubernetes personalizado que combina Go para la orquestación y Rust para el plano de datos, logrando un rendimiento 11% superior a Nginx en pruebas bare-metal. La imagen resultante pesa menos de 280 MB y arranca en segundos donde el stack tradicional tardaba más de 4,5 minutos.
En 30 segundos
- Silex es un controlador Ingress Kubernetes personalizado con arquitectura de dos capas: Go para la gestión de configuración y Rust para el data plane de alta performance.
- Los controladores tradicionales como Nginx superan los 280 MB de imagen y generan cold starts de más de 4,5 minutos en entornos bare-metal, según las pruebas documentadas.
- La separación estricta de responsabilidades elimina el overhead de recargas de configuración multi-proceso que caracteriza a Nginx en entornos dinámicos.
- Los webhooks de validación de los controladores legacy contaminan el scope global del cluster y pueden dejar estados huérfanos al borrar namespaces.
- El resultado: 11% más de rendimiento sobre Nginx en benchmarks propios, con menor consumo de recursos para las aplicaciones backend.
El Problema: Por Qué los Ingress Controllers Tradicionales No Escalan
Silex es un controlador Ingress Kubernetes personalizado diseñado desde cero para entornos cloud-native, construido con Go en el plano de control y Rust en el plano de datos, como alternativa a los controladores basados en Nginx y arquitecturas heredadas.
Ponele que estás armando un cluster bare-metal para una aplicación que escala rápido. Desplegás el Nginx Ingress Controller de siempre, esperás que levante, y en entornos de prueba documentados por SysAlchemist, eso puede demorar más de 4,5 minutos en el cold start. Si tu entorno hace auto-scaling agresivo, esa latencia inicial es un problema real, no teórico.
El tamaño de imagen supera los 280 MB. En una infraestructura donde cada nodo tiene que bajar esa imagen antes de arrancar el proxy, estás pagando ese costo en tiempo y en ancho de banda cada vez que el cluster escala horizontalmente.
Eso sí: la imagen grande es molesta, pero no es el peor problema.
Cuando desplegás un controlador legacy, termina instalando validating webhook configurations que operan a nivel del cluster global. Si en algún momento borrás un namespace a la fuerza (algo que pasa más seguido de lo que cualquiera quisiera admitir), esos webhooks quedan en un estado huérfano. Y ese estado huérfano bloquea la creación de futuros recursos de red en el cluster. No es un bug exótico: es el comportamiento documentado de esta arquitectura.
Nginx en Kubernetes: Diseño Heredado para Problemas Modernos
Nginx es un servidor web brillante para lo que fue diseñado. El problema es que Kubernetes no existía cuando se tomaron las decisiones arquitecturales centrales de Nginx. Complementá la lectura sobre cómo integrar el ingress con tu pipeline CI/CD.
El modelo de Nginx es multi-proceso con recargas de configuración. En un entorno estático, eso está bien. Pero en Kubernetes, donde los servicios aparecen y desaparecen constantemente, cada cambio en las reglas de ruteo dispara una recarga. Esa recarga consume CPU, tiene una ventana de tiempo donde las conexiones pueden verse afectadas, y agrega complejidad operacional que no aportaría nada si el proxy estuviera diseñado para ser dinámico desde el principio.
¿El resultado? CPU y memoria que deberían estar disponibles para las aplicaciones backend se van en sostener la infraestructura de proxy. En nodos con recursos limitados, ese overhead es dinero.
Silex: Reimaginando el Ingress Controller desde Cero
SysAlchemist diseñó Silex con una premisa concreta: separación estricta de responsabilidades. No es una reconfiguración de Nginx, no es un wrapper sobre otro proxy existente. Es un controlador construido desde cero para Kubernetes.
La arquitectura tiene dos capas bien definidas. Una se ocupa de la “inteligencia” (leer el estado del cluster, procesar los objetos Ingress, generar la configuración correcta). La otra se ocupa de mover paquetes con la menor latencia posible. Cada capa tiene su lenguaje, sus herramientas, y su rol. Sin mezclar.
Comparado con alternativas existentes como Traefik o Envoy, la diferencia está en el scope: Silex no busca ser un proxy de propósito general. Busca ser el controlador Ingress Kubernetes más eficiente posible para el caso de uso específico de ruteo en el edge del cluster.
Arquitectura de Separación: El Cerebro (Go) y los Músculos (Rust)
La elección de lenguajes no es arbitraria.
Go para el plano de control tiene sentido por varias razones: el ecosistema de Kubernetes está construido en Go, las librerías para interactuar con la API del cluster están maduras y bien mantenidas, y el garbage collector de Go es suficientemente predecible para tareas de orquestación donde la latencia de control no es crítica al microsegundo. Compilás a un binario nativo, sin dependencia de runtime externo, lo que ya reduce la imagen considerablemente. Lo explicamos a fondo en optimizar el routing de tráfico multiregión.
Rust para el data plane es donde la apuesta se pone interesante. Rust compila a código nativo sin runtime, sin garbage collector, con abstracciones de costo cero. En un proxy de red donde cada paquete cuenta, esa predictibilidad es valiosa. Además, la ausencia de GC elimina los pauses que en Go pueden aparecer en momentos de alta carga y que en el contexto de forwarding de red se sienten.
Esta separación también reduce la superficie de ataque: el componente de data plane en Rust tiene acceso limitado, no tiene que entender la API de Kubernetes, y puede ejecutarse con privilegios mínimos. Si algo falla en la orquestación, el plano de datos sigue funcionando con la configuración anterior.
Subís la configuración, la probás en staging, funciona impecable, la mandás a producción y el componente de data plane la aplica sin reiniciar el proceso completo, sin recarga, sin ventana de corte de conexiones en vuelo.
Resultados Concretos: 11% Mejor Rendimiento Que Nginx
Según el artículo técnico de SysAlchemist, Silex logra un 11% de mejora de rendimiento sobre Nginx en pruebas realizadas en entornos bare-metal. Los cold start que con Nginx superaban los 4,5 minutos se reducen drásticamente.
Un punto que hay que marcar: estos benchmarks son del propio autor. No hay validación independiente publicada todavía. Tomalo con ese contexto. Un 11% de mejora en throughput de proxy es plausible dado el modelo arquitectural, pero hasta que alguien más lo reproduzca en condiciones controladas, el número es orientativo.
¿Alguien lo verificó de forma independiente? Todavía no, que yo sepa.
| Característica | Nginx Ingress Controller | Silex (Go + Rust) |
|---|---|---|
| Tamaño de imagen | >280 MB | Reducido (no especificado) |
| Cold start bare-metal | >4,5 minutos | Segundos |
| Arquitectura | Multi-proceso con recargas | Separación plano control/datos |
| Webhooks de validación | Scope global del cluster | Sin webhooks de scope global |
| Rendimiento vs Nginx | Baseline | +11% (benchmark propio) |
| Lenguaje data plane | C (Nginx core) | Rust |
| Lenguaje control plane | Lua / config templates | Go |
Reducción Radical: Menos Bloat, Menos Complejidad, Menos Problemas
El beneficio más inmediato para equipos que operan clusters bare-metal o edge es el startup. En auto-scaling agresivo, la diferencia entre 4,5 minutos y 15 segundos puede ser la diferencia entre absorber un pico de tráfico y caerse.
La eliminación de los validating webhooks de scope global es otro punto que subestima quien no lo vivió: administrar el ciclo de vida de esos webhooks cuando el cluster tiene alta rotación de namespaces agrega carga operacional real. Con Silex, ese problema no existe porque el diseño lo evita desde el inicio. Esto se conecta con lo que analizamos en ejecutar componentes críticos sin dependencias externas.
Para equipos en Latinoamérica que corren infraestructura en donweb.com u otros proveedores con nodos de recursos ajustados, la reducción del overhead del proxy libera CPU y memoria que van directo a las aplicaciones. En pricing por hora, eso se traduce en costos menores o en más capacidad sin agregar nodos.
Cuándo Migrar a un Ingress Personalizado y Cómo Comenzar
No todo el mundo necesita esto. Seamos honestos.
Si tenés un cluster manejado en un cloud provider donde los nodos son potentes, el cold start de 4,5 minutos es un problema que no se nota, y los webhooks se administran solos, Nginx Ingress (o Traefik, o el controlador de tu cloud) está bien.
Los casos donde un controlador Ingress Kubernetes personalizado como Silex tiene sentido real:
- Bare-metal con auto-scaling real: donde cada segundo de cold start tiene costo directo en disponibilidad.
- Edge computing: nodos con recursos muy limitados donde el overhead del proxy compite con las aplicaciones.
- Clusters con alta rotación de namespaces: donde el problema de los webhooks huérfanos se vuelve operacionalmente costoso.
- Aplicaciones latency-critical: donde el modelo de recarga de Nginx introduce jitter inaceptable.
Para empezar, el repositorio de Silex es el punto de entrada. La arquitectura está documentada en el artículo original. El nivel de entrada técnico es moderado-alto: necesitás entender cómo funciona el controller pattern en Kubernetes, tener algo de Go, y no le tengas miedo a Rust aunque sea para leer el código.
Errores Comunes
Benchmarkear en el entorno equivocado
Un 11% de mejora en bare-metal puede ser 2% o cero en un cluster cloud con nodos potentes y almacenamiento rápido. Los benchmarks de Silex son en bare-metal, que es donde sus ventajas son más pronunciadas. Si vas a evaluar la migración, medí en tu propio entorno, no extrapoles los números del autor.
Ignorar el costo de mantenimiento de un controlador propio
Cualquiera que haya mantenido un fork de software de infraestructura sabe que el costo inicial es bajo y el costo acumulado es alto. Con Silex o cualquier controlador personalizado, vos absorbés el mantenimiento de seguridad, las actualizaciones compatibles con versiones nuevas de Kubernetes, y el debugging de problemas que con un proyecto maduro ya tienen issue abierto y solución documentada. No es un argumento para no usarlo, pero sí para no subestimarlo.
Migrar sin entender el controller pattern de Kubernetes
El controller pattern (reconciliation loop, watch sobre recursos, manejo de eventos) es el corazón de cómo funcionan estos sistemas. Intentar operar o modificar un controlador personalizado sin esa base garantiza problemas difíciles de diagnosticar. Antes de meterte, asegurate de que el equipo entiende cómo un controlador observa el estado deseado vs el estado actual y cómo converge. Tema relacionado: garantizar seguridad en tu infraestructura de ingress.
Preguntas Frecuentes
¿Cómo crear un controlador Ingress personalizado para Kubernetes?
Un controlador Ingress personalizado implementa el controller pattern de Kubernetes: observa los objetos Ingress del cluster usando la API de Kubernetes, traduce esas reglas a configuración del proxy, y mantiene el plano de datos sincronizado. La arquitectura de Silex separa esto en dos binarios: Go para la orquestación (habla con la API de Kubernetes) y Rust para el forwarding real de tráfico. El punto de partida es entender el reconciliation loop y el client-go o controller-runtime en Go.
¿Qué limitaciones tiene Nginx como Ingress en Kubernetes moderno?
Nginx usa un modelo multi-proceso con recargas de configuración que no está optimizado para entornos donde los servicios cambian constantemente. Esto genera overhead de CPU en cada cambio de reglas y una ventana de potencial interrupción de conexiones. Además, instala validating webhooks a nivel de cluster global que pueden dejar estados huérfanos si se borran namespaces de forma abrupta, bloqueando la creación de nuevos recursos de red.
¿Por qué usar Rust para un Ingress Controller?
Rust compila a código nativo sin runtime ni garbage collector, lo que significa cero pauses por GC en el data plane. Para un proxy de red donde cada paquete pasa por ese código, la predictibilidad de latencia de Rust es una ventaja real. Además, las abstracciones de costo cero de Rust permiten escribir código de alto nivel sin pagar overhead en tiempo de ejecución. Combinado con una superficie de ataque reducida (sin memoria dinámica no controlada), es una elección que tiene fundamento técnico más allá de la moda.
¿Cuántos recursos consume un Ingress Controller tradicional?
Según las pruebas documentadas en el caso de Silex, los controladores estándar como Nginx superan los 280 MB de imagen de contenedor. En entornos bare-metal eso se traduce en más de 4,5 minutos de cold start en el primer pull. A nivel de CPU y memoria en ejecución, el modelo multi-proceso de Nginx consume recursos que compiten directamente con las aplicaciones backend en nodos con recursos limitados.
¿Es posible mejorar el rendimiento del routing en Kubernetes con un controlador propio?
Sí, y el caso de Silex lo demuestra: según su autor, logró un 11% de mejora sobre Nginx en bare-metal con una arquitectura Go+Rust. El tradeoff es el costo de mantenimiento: un controlador propio requiere que el equipo absorba actualizaciones de seguridad, compatibilidad con nuevas versiones de Kubernetes, y el debugging de problemas que con proyectos maduros ya tienen solución documentada.
Conclusión
Silex demuestra que los controladores Ingress Kubernetes que vienen por defecto no son la única opción, y que para entornos bare-metal o edge hay espacio real para mejorar. La arquitectura Go+Rust tiene fundamento técnico sólido: el modelo multi-proceso de Nginx con recargas de configuración no está diseñado para la dinámica de Kubernetes, y el overhead acumulado se siente cuando los recursos son limitados.
El 11% de mejora de rendimiento hay que tomarlo con la cautela de que es un benchmark del propio autor en un entorno específico. Lo que sí es verificable desde ya: la reducción de imagen, la eliminación de los webhooks huérfanos y el modelo de data plane sin recargas son ventajas arquitecturales concretas, no promesas.
Si operás clusters bare-metal o edge con auto-scaling agresivo, vale la pena mirar el repositorio y evaluar si el costo de migración se justifica con tu caso de uso específico. Para el resto, el cambio probablemente no mueva la aguja.
