Kubernetes ya no es un entorno de pruebas para los pioneros en su adopción. Es el sistema operativo de las empresas modernas. Cerca de 20 millones de desarrolladores de aplicaciones nativas de la nube lo utilizan para desarrollar en todo el mundo. Se prevé que más del 90 % de las organizaciones de todo el mundo ejecuten aplicaciones en contenedores en producción de aquí a 2027. Además, dos tercios de quienes han adoptado la IA generativa ya ejecutan cargas de trabajo de inferencia en Kubernetes. La orquestación de contenedores ya es, oficialmente, esencial para el negocio.
Pero esta es la incómoda realidad: solo el 38 % de las organizaciones que ejecutan Kubernetes en producción han alcanzado un nivel de madurez empresarial, según El estado de la estrategia empresarial de Kubernetes en 2026, basado en una investigación de SlashData patrocinada por F5. Aproximadamente la mitad —el 51 %— están «consolidadas», pero siguen teniendo carencias críticas en gobernanza, observabilidad, resiliencia o en su cadena de suministro de software. El 11 % restante aún está en proceso de estandarización.
Para ayudar a las empresas a alcanzar el nivel de madurez de Kubernetes de categoría empresarial que necesitan, F5 Application Delivery and Security Platform (ADSP) ofrece una arquitectura unificada que elimina la brecha operativa entre los equilibradores de carga externos y el ingreso dentro del clúster, sustituyendo las frágiles cadenas de herramientas de múltiples proveedores por una arquitectura cohesionada de categoría empresarial.
Una base común que une a los equipos
Kubernetes cumple su función de forma excepcional. Programa las cargas de trabajo, escala los recursos de computación de forma elástica, recupera automáticamente los pods que fallan y abstrae el hardware subyacente en entornos híbridos y multinube. Pero la orquestación de contenedores es solo la mitad de la ecuación. Controlar y proteger el tráfico es la otra mitad.
Kubernetes nunca se diseñó para controlar el comportamiento del tráfico de las aplicaciones y la IA en entornos empresariales distribuidos. No toma decisiones de enrutamiento en tiempo real basadas en las condiciones globales de la red, no aplica políticas de seguridad empresarial de forma coherente en las rutas de entrada y salida ni garantiza un aislamiento estricto del tráfico entre múltiples inquilinos a gran escala.
Y esto es lo que complica aún más el problema: el tráfico y la seguridad de Kubernetes no son responsabilidad de un único perfil profesional. Un ingeniero de plataformas que expone microservicios mediante GitOps, un arquitecto de redes que gestiona el emparejamiento del protocolo de puerta de enlace de frontera (BGP) entre varios clústeres y la descarga de procesamiento en DPU, y un CISO que se defiende frente a ataques que aprovechan vulnerabilidades de día cero mediante IA tienen requisitos operativos fundamentalmente distintos.
Obligar a todas las partes implicadas a utilizar una única herramienta que sirva para todo siempre acaba mal: o resulta demasiado compleja para los desarrolladores o demasiado limitada para los equipos de infraestructura empresarial. F5 ADSP adopta un enfoque diferente y ofrece soluciones nativas de la nube diseñadas específicamente para adaptarse a la forma en que cada perfil controla y protege realmente el tráfico, todo ello sobre una base común que une a los equipos sin obligar a nadie a hacer concesiones.
Equipos diferentes, prioridades distintas en materia de tráfico y seguridad
A medida que Kubernetes crece —especialmente cuando las organizaciones pasan de aplicaciones web sin estado a cargas de trabajo de IA con estado y de alto rendimiento—, surgen cuatro perfiles diferenciados, cada uno con dificultades muy distintas.
- El responsable de plataformas y DevOps prioriza la rapidez, el autoservicio y los flujos de trabajo YAML nativos de Kubernetes. Con demasiada frecuencia, empieza con un controlador comunitario gratuito —como el proyecto comunitario ingress-nginx, retirado recientemente— y acaba teniendo que mantener software sin soporte en decenas de clústeres de producción, dedicando recursos de ingeniería a tareas operativas tediosas.
- El responsable de NetOps e infraestructura exige un enrutamiento eficiente, descarga de TLS de alta capacidad, aislamiento estricto entre inquilinos y visibilidad de extremo a extremo. Cuando el tráfico entra en un clúster, los equipos de red suelen perder la visibilidad de lo que ocurre, lo que da lugar a sesiones de crisis de cuatro horas para intentar determinar si la interrupción se origina en la red o en el pod.
- El responsable de la infraestructura de IA ha invertido millones en clústeres de GPU que a menudo están infrautilizados, no por falta de capacidad de cómputo, sino porque el cuello de botella está en gestionar de forma eficiente la entrada y salida de tokens, enrutar las solicitudes de forma inteligente entre los distintos modelos y aislar el tráfico de GPU de los distintos inquilinos.
- El CISO y el responsable de SecOps se preocupan por la exposición al riesgo imposible de cuantificar en los clústeres efímeros, la falta de coherencia en las políticas de seguridad de las API y del cortafuegos de aplicaciones web (WAF), y la rapidez con la que se explotan las vulnerabilidades actuales.
En lugar de pedir a DevOps que piense como NetOps, o a NetOps que gestione el YAML de las aplicaciones, F5 proporciona a cada equipo el plano de datos y el plano de control nativos de la nube adecuados.
“F5 adopta un enfoque diferente y ofrece soluciones nativas de la nube diseñadas específicamente para adaptarse a la forma en que cada perfil controla y protege el tráfico en la práctica, todo ello respaldado por una base común que une a los equipos sin obligar a nadie a hacer concesiones.”
Para los equipos de DevOps y de plataformas: agilidad ligera y nativa de Kubernetes
Los ingenieros de plataformas y los desarrolladores buscan una solución ligera y ágil que se ejecute de forma nativa en Kubernetes y se integre sin fricciones en los flujos de CI/CD y GitOps. Esa es precisamente la función de F5 Ingress Controller for NGINX y F5 Gateway Fabric for NGINX, ambos parte de F5 ADSP.
Con la confianza de millones de implementaciones nativas de la nube, F5 NGINX es la opción natural para estandarizar la gestión del tráfico de aplicaciones y API dentro del clúster. Tanto si sus equipos utilizan recursos Ingress de Kubernetes como el moderno estándar Gateway API de Kubernetes —incluida la extensión de inferencia de Gateway API para cargas de trabajo de IA—, las soluciones NGINX de F5 ofrecen una implementación ultrarrápida y fácil de usar para los desarrolladores.
En cuanto a la eficiencia de los recursos, el consumo de memoria de los proxies de la competencia se dispara al gestionar prompts de IA de contexto largo o cargas de datos en streaming. F5 Gateway Fabric for NGINX, en cambio, mantiene un consumo de memoria constante y predecible, independientemente del tamaño de la carga de datos.
Para las organizaciones que están migrando desde el proyecto comunitario ingress-nginx, ya retirado, F5 ofrece una alternativa con soporte empresarial y el respaldo de un SLA, además de conversión automatizada de la configuración, para que la migración no tenga por qué ser complicada.
Además, la seguridad no se añade a posteriori. Los equipos pueden integrar productos WAF de F5, seguridad de API, autenticación (OIDC, JWT), limitación de la tasa de solicitudes y mecanismos de protección en tiempo real para las entradas y respuestas de la IA directamente en sus manifiestos de Kubernetes, protegiendo el tráfico de las aplicaciones y los LLM al ritmo del código.
Para arquitectos de infraestructura e IA: aislamiento multiclúster y tráfico de salida
Un proxy ligero dentro del clúster es ideal para los equipos de aplicaciones, pero los entornos empresariales a gran escala, los operadores de telecomunicaciones y las fábricas de IA necesitan una escalabilidad de nivel operador, un aislamiento estricto entre inquilinos y un control bidireccional del tráfico. Ahí es donde entra en juego F5 BIG-IP Next for Kubernetes.
Basado en el micronúcleo de gestión del tráfico (TMM) de F5, nativo de contenedores, y diseñado para ejecutarse en nodos de trabajo estándar o delegar el procesamiento en DPU NVIDIA BlueField-3, BIG-IP Next for Kubernetes lleva el control del tráfico y la seguridad de nivel de infraestructura directamente a Kubernetes.
La mayoría de las herramientas de Kubernetes se centran exclusivamente en el tráfico de entrada. BIG-IP Next for Kubernetes controla y protege tanto el tráfico de entrada como el de salida. A medida que los microservicios y los agentes de IA se conectan a API externas, bases de datos de sistemas de origen, servidores del protocolo de contexto de modelos (MCP) y servicios entre clústeres, el tráfico de salida no gestionado se convierte en un importante punto ciego para la exfiltración de datos. BIG-IP Next for Kubernetes aplica enrutamiento determinista del tráfico de salida, SNAT, reglas de cortafuegos basadas en espacios de nombres y microsegmentación de confianza cero.
En entornos multiclúster y multiinquilino, BIG-IP Next for Kubernetes establece conexiones de peering directamente con las redes troncales mediante BGP y acelera la gestión del tráfico L4–L7, la descarga de operaciones criptográficas mTLS y el enrutamiento de tokens basado en prefijos en las DPU. El resultado: un aislamiento estricto entre inquilinos, la liberación de recursos de CPU de los hosts y el máximo aprovechamiento de las GPU.
Uniendo a los equipos de NetOps y de plataformas
Entonces, ¿qué ocurre cuando NetOps gestiona F5 BIG-IP en el perímetro —encargándose de la mitigación de ataques DDoS a nivel de hardware, la gestión global del tráfico y el cumplimiento normativo— mientras el equipo de plataforma ejecuta F5 Gateway Fabric for NGINX o F5 Ingress Controller for NGINX dentro del clúster?
F5 BIG-IP Container Ingress Services (CIS) conecta sus flujos de trabajo automáticamente.
Como conector automatizado y nativo de Kubernetes, BIG-IP CIS supervisa las API de Kubernetes y OpenShift —incluidos los recursos Ingress, Gateway API, Routes y F5 IngressLink/GatewayLink— y configura dinámicamente los sistemas BIG-IP externos en tiempo real.
Los desarrolladores siguen trabajando en Kubernetes y definen el enrutamiento del tráfico dentro del clúster, TLS y las políticas de L7 en YAML estándar. NetOps mantiene el control del perímetro, mientras CIS detecta automáticamente los cambios en el clúster y actualiza los servidores virtuales, los miembros de los pools y DNS/GTM multiclúster en el BIG-IP externo, sin necesidad de gestionar solicitudes manualmente. Ambos equipos mantienen el control de sus respectivos ámbitos y comparten telemetría de extremo a extremo, desde la VIP del perímetro hasta el pod, con la posibilidad de migrar a BIG-IP Next for Kubernetes a medida que evolucionan las necesidades.
Para SecOps y CISO: versiones reforzadas tanto de código abierto como empresariales
Ofrecer a cada perfil la arquitectura de tráfico adecuada es esencial, pero el software de tu plano de datos también debe resistir un panorama de amenazas acelerado por la IA.
Veamos las cifras. En 2018, los equipos de defensa disponían de una media de 771 días desde la divulgación de una CVE hasta que se desarrollaba un exploit listo para atacar. Hoy, los agentes de IA ofensiva pueden convertir vulnerabilidades en armas en cuestión de minutos, mientras que una empresa media sigue tardando varias semanas en desplegar un parche. En los repositorios públicos de código abierto, cada commit de seguridad es, en esencia, una hoja de ruta para los atacantes; las herramientas de IA pueden comparar los cambios en el código y generar exploits semanas antes de que las distribuciones derivadas recompilen los paquetes.
F5 proporciona versiones reforzadas para que puedas desplegar con confianza, protegiendo tanto a los clientes comerciales como a la comunidad de código abierto. F5 ejecuta continuamente un conjunto interno de pruebas de seguridad basadas en IA en el código de BIG-IP, BIG_IP Next for Kubernetes y NGINX para detectar y corregir vulnerabilidades de forma proactiva.
Las versiones reforzadas confidenciales se distribuyen a los clientes comerciales de NGINX Enterprise, BIG-IP y BIG-IP Next for Kubernetes como actualizaciones específicas centradas exclusivamente en la seguridad, sin cambios en las funcionalidades ni obsolescencia de las API. Después, unas seis semanas más tarde —para dar a las infraestructuras empresariales un margen seguro para aplicar los parches—, F5 publica su aviso de seguridad y, al mismo tiempo, facilita los detalles de las CVE y los parches para NGINX Open Source.
Cómo encaja todo: escalar una plataforma multiinquilino de GPU como servicio
Para ver cómo encajan estas piezas en la práctica, tomemos como ejemplo la reciente implementación de uno de los principales gigantes del comercio electrónico y la logística de Asia-Pacífico.
Tras años ejecutando enormes cargas de trabajo internas de IA, la empresa se propuso lanzar una nube comercial de GPU como servicio (GPUaaS) basada en clústeres de Kubernetes locales a gran escala, con sistemas NVIDIA DGX. La transformación de los clústeres internos en una nube multiinquilino planteó tres retos inmediatos.
En primer lugar, los clientes empresariales externos necesitaban acceder simultáneamente a clústeres compartidos sin que el tráfico de un cliente se filtrase a otro. En segundo lugar, el equipo de la plataforma necesitaba enrutamiento L7 nativo de la nube, terminación TLS y aislamiento de espacios de nombres en más de 100 nodos, sin tener que tramitar manualmente solicitudes de red. Y, en tercer lugar, los controladores de código abierto de la comunidad simplemente carecían de la gestión robusta del tráfico y del soporte ininterrumpido necesarios para respaldar un acuerdo de nivel de servicio (SLA) comercial.
La empresa implementó una arquitectura de tráfico de Kubernetes de dos niveles que combina F5 BIG-IP rSeries LTM, BIG-IP CIS y F5 Ingress Controller for NGINX en 100 nodos de Kubernetes. En el perímetro, los dispositivos BIG-IP rSeries proporcionan equilibrio de carga de capa 4 de alto rendimiento y un aislamiento estricto de los equilibradores de carga virtuales —con vCPU, memoria y particiones de enrutamiento dedicadas—, asignando cada dominio de inquilino a una IP virtual aislada mediante una correspondencia uno a uno.
Mediante F5 IngressLink, BIG-IP CIS supervisa la API de Kubernetes y vincula automáticamente los servidores virtuales BIG-IP externos con los pods de NGINX del clúster, sin necesidad de solicitudes manuales. Dentro del clúster, los pods de NGINX Ingress Controller dedicados a cada inquilino terminan las conexiones TLS, realizan el descifrado y aplican el enrutamiento y la autenticación de capa 7, dirigiendo el tráfico al espacio de nombres aislado y a los recursos de GPU de cada inquilino.
Al proporcionar a NetOps aislamiento por hardware de BIG-IP en el perímetro, ofrecer a sus ingenieros de plataforma la agilidad de NGINX nativa de la nube dentro del clúster y conectar ambos entornos con BIG-IP CIS, la empresa lanzó su plataforma GPUaaS en el plazo previsto, al tiempo que sentaba las bases para adoptar BIG-IP Next for Kubernetes a medida que crezca su fábrica de IA.
Control del tráfico y seguridad adaptados a la forma de trabajar de tus equipos
Según El estado de la estrategia empresarial de Kubernetes en 2026, el 24 % de las empresas no logra alcanzar la madurez en Kubernetes debido a una única carencia, que suele estar relacionada con la observabilidad o el control de admisión. La diferencia entre «consolidado» y «de nivel empresarial» no es un problema de plataforma, sino de control del tráfico, seguridad y coordinación entre equipos.
F5 cierra esa brecha para todos los perfiles. Migre desde el proyecto comunitario ingress-nginx, ya retirado, mediante una vía con soporte empresarial. Conecte automáticamente los flujos de trabajo de NetOps y de los equipos de plataforma con BIG-IP CIS. Controle el tráfico de entrada y salida de los clústeres de IA multitenant con BIG-IP Next for Kubernetes. Y refuerce la seguridad de todo el entorno con versiones exclusivamente de seguridad que se publican semanas antes de la divulgación pública de las CVE. Con una arquitectura unificada que satisface las necesidades de los distintos equipos, F5 ADSP proporciona la madurez operativa de Kubernetes que las empresas necesitan para ejecutar Kubernetes de forma segura y eficiente a gran escala.
¿Quieres profundizar? Visita el stand n.º 100 de F5 en KubeCon, en Salt Lake City, del 9 al 12 de noviembre, y habla directamente con nuestros ingenieros para resolver los cuellos de botella de red de Kubernetes, probar demostraciones interactivas, asistir a sesiones informativas prácticas y resolver los cuellos de botella de Kubernetes.
Lee nuestro blog: «Por qué la mayoría de las empresas aún no han alcanzado un nivel de seguridad empresarial».
Además, no te olvides de inscribirte en nuestro seminario web «Qué distingue una estrategia de Kubernetes de nivel empresarial de las demás».
Sobre los autores
Artículos relacionados del blog
El imperativo empresarial de la IA en un mundo de nube híbrida y multinube
Cómo la IA redefine los patrones de tráfico, el riesgo de las API y el cumplimiento normativo, y por qué el paquete Distributed Cloud Services Enterprise ofrece la profundidad necesaria en entornos híbridos multicloud.
STIG de F5 NGINX: un plan de seguridad para el sector público y los entornos regulados
Descubra cómo las STIG de F5 NGINX proporcionan un modelo de seguridad para el Departamento de Defensa de EE. UU. y los entornos regulados, ayudándole a cumplir la normativa mientras crea una infraestructura sólida de confianza cero con mayor visibilidad y resiliencia.
Cómo el marco AEGIS de Forrester valida un enfoque centrado en la inferencia
El auge de la IA agéntica está transformando el panorama de la seguridad empresarial. Estos agentes de IA autodirigidos funcionan de forma autónoma, toman decisiones en tiempo real y pueden interactuar entre distintos sistemas de maneras para las que las arquitecturas tradicionales de ciberseguridad no fueron diseñadas. Aunque esto abre nuevas posibilidades, también introduce riesgos sistémicos: fallos en cascada, secuestro de objetivos y superficies de ataque hasta ahora invisibles. El reciente […] de Forrester
La nueva superficie de riesgo de la IA: invisible, autónoma y ya está dentro
James White, vicepresidente de Ingeniería de F5 A mediados de 2025, es un buen momento para hacer balance de la adopción de la IA en las empresas y del estado de la seguridad de la IA. El uso de la IA generativa ya es habitual en las empresas En general, las empresas cuentan al menos con unos conocimientos básicos sobre la IA generativa. Entienden qué es y dónde puede […]
Protegiendo el futuro: cómo CalypsoAI se alinea con el Top 10 de OWASP para los LLM
Cuando OWASP publicó su Top 10 de 2025 para grandes modelos de lenguaje (LLM), proporcionó al sector un referente de seguridad muy necesario. Pero los referentes no sirven de nada si no se actúa. CalypsoAI aborda el 80 % del Top 10 de OWASP, dando prioridad a los riesgos reales más urgentes. La plataforma combina protección en tiempo real durante la ejecución y pruebas adversariales exhaustivas, ofreciendo una cobertura inigualable frente a las […]
Implementación de LLM en la empresa: mediante una API local
Por sí solos, sin medidas de protección ni protocolos adicionales de seguridad para la IA, el despliegue de modelos de IA generativa —en particular, modelos de lenguaje de gran tamaño (LLM)— en toda la empresa supone una oportunidad de alto riesgo y grandes beneficios para cualquier organización. Sin embargo, determinar exactamente cómo debe dar su organización este gran paso hacia el ámbito de la IA generativa requiere una planificación minuciosa. Quizá […]