Por qué la mayoría de las empresas aún no han alcanzado la madurez en Kubernetes

Buu LamDirector de Evangelización Comunitaria

Hace más de 10 años, cuando trabajaba como ingeniero de soluciones, vi cómo las organizaciones empezaban a desplegar Kubernetes como un proyecto secundario. Era una iniciativa experimental, que a menudo se llevaba a cabo en paralelo a las pruebas de otros orquestadores de contenedores. Las cargas de trabajo reales seguían ejecutándose en máquinas virtuales en vSphere, un entorno diseñado en torno a objetivos de nivel de servicio y de tiempo de recuperación. Todo el mundo participaba, no solo los administradores de servidores. Eso era, por así decirlo, un entorno de categoría empresarial.

Entonces las cosas cambiaron. La nube pública despegó, las aplicaciones se modernizaron y Kubernetes se convirtió en la opción por defecto de las empresas para ejecutar aplicaciones en contenedores. El motor del cambio era el de siempre: la actividad comercial, que necesitaba escalar con rapidez. Las empresas querían avanzar más deprisa, y acompañé a muchos de los primeros clientes en su intento de convertir Kubernetes en una plataforma empresarial.

Para esos clientes, las expectativas del negocio marcaban el destino. En un proyecto experimental se hace lo que se puede, y a veces ni eso. Una plataforma empresarial tiene que evolucionar al ritmo del negocio e, idealmente, convertirse en un elemento clave de su competitividad. Kubernetes ya ha alcanzado ese nivel de exigencia, pero por sí solo no es una plataforma completa como lo es vSphere. Su base de código abierto es magnífica, pero es solo el principio.

Un nuevo estudio encargado por F5 a SlashData revela la magnitud de la brecha para alcanzar el nivel empresarial. De las empresas que utilizan Kubernetes en producción, el 61 % le exige un nivel igual o superior al del resto de su infraestructura de TI, pero solo el 38 % alcanza un grado de madurez de nivel empresarial.

Solo el 38 % de las empresas que utilizan Kubernetes en producción alcanzan un nivel de madurez de categoría empresarial.

En el informe, el nivel empresarial implica más que una puntuación alta. Exige un control de admisión automatizado, un aislamiento obligatorio entre inquilinos, observabilidad centralizada, objetivos de recuperación documentados y pruebas de conmutación por error realizadas en los últimos 12 meses. La encuesta evaluó lo que los equipos hacen realmente, no el grado de madurez que creen tener, a partir de 445 respuestas de profesionales con experiencia práctica en organizaciones de más de 500 empleados, recopiladas en agosto de 2026.

La mayoría de los entornos están consolidados, pero no son maduros

Veo las definiciones del informe como hitos en un camino que todos estamos recorriendo. Dudo que ninguna organización llegue nunca a completar ese camino, y siempre hay que hacer concesiones al fijar prioridades. El informe nos ofrece una instantánea de la situación actual de las empresas. La mitad (51 %) se sitúa en el nivel consolidado, en el que los estándares están definidos y se aplican en gran medida, aunque con carencias evidentes. Otro 11 % aún está en proceso de estandarización. Casi nueve de cada diez (88 %) alcanzan el nivel más alto en al menos un ámbito, pero solo el 22 % lo consigue en los cuatro. Incluso entre el 51 % de las empresas que obtienen una puntuación global de 80 o más, una de cada cuatro (24 %) incumple un único requisito previo, lo que les impide acceder al nivel más alto.

La observabilidad es la pieza que falta con más frecuencia. Entre las empresas que se quedan a las puertas del nivel más alto, el 36 % carece de observabilidad centralizada y el 31 % de control de admisión automatizado. Ambas carencias coinciden con lo que he visto sobre el terreno. En la mayoría de los casos, lo que les faltaba a mis clientes era observabilidad, utilizaran Kubernetes o no. Resolver los problemas era complicado, implicaba a muchas más personas de las necesarias y, con demasiada frecuencia, acababa en un cruce de acusaciones.

El control de admisión es importante por una cuestión de escala. Un cliente dependía en gran medida de él para gestionar vSphere debido al tamaño de su entorno. Los entornos de Kubernetes crecen rápidamente, y el reto más citado en el informe es la complejidad de gestionar clústeres y entornos (39 %). Los controles que resultan importantes a gran escala empiezan a serlo antes de lo que la mayoría de los equipos espera. Sin embargo, solo el 28 % tiene previsto invertir en observabilidad en los próximos 12 meses, frente al 42 % que prevé invertir en seguridad y aplicación de políticas.

La madurez es un deporte de equipo

Con los años, los roles cobraron más importancia de la que esperaba. Conocí a los equipos de plataformas y DevOps porque conocían NGINX, confiaban en él y querían utilizarlo. También conocí a los equipos de redes y seguridad, que querían asegurarse de que Kubernetes pudiera integrarse en sus prácticas empresariales de NetOps y SecOps, en lugar de crear flujos de trabajo completamente independientes.

Un cliente hizo algo poco habitual en aquel momento: le dio a su ingeniero de DevOps su propio F5 BIG-IP. Aprendió todos sus entresijos y consiguió que hiciera cosas que rara vez había visto hacer a los administradores tradicionales de BIG-IP (¡un saludo a Steven!). Eso era confianza puesta en práctica. El éxito siempre surgía de la colaboración y la confianza, porque los resultados de nivel empresarial dependen de que los equipos se apoyen unos en otros, no de que trabajen al margen de los demás.

La investigación apunta en la misma dirección. En las empresas donde un equipo especializado de ingeniería de plataformas gestiona Kubernetes y un equipo central de seguridad independiente establece las políticas, el 66 % alcanza un nivel de madurez de categoría empresarial, aproximadamente el doble que con otros modelos organizativos. Solo el 19 % trabaja así. El alcance también importa: el 53 % de las empresas que utilizan Kubernetes como plataforma estándar en toda la organización alcanza el nivel más alto, frente al 25 % de aquellas en las que su uso se limita a un único equipo.

Se trata de una correlación, no de una prueba de causalidad. Puede que las organizaciones más grandes y comprometidas simplemente sean más propensas a repartir el trabajo de esta manera. Aun así, coincide con mi experiencia: los equipos que comparten la carga de trabajo y confían en que los demás cumplan con su parte son los que alcanzan un nivel de madurez empresarial.

La IA avanza más rápido que la gobernanza

También fui testigo de los primeros indicios de esta situación. Una empresa estaba desplegando rápidamente cargas de trabajo de aprendizaje automático que se estaban volviendo esenciales para el negocio, y esa área era el motor de la innovación en una empresa que, por lo demás, era de corte tradicional. A ese ritmo, la gobernanza puede quedarse atrás.

Entre las empresas que utilizan Kubernetes en producción, el 45 % despliega modelos o los pone a disposición para su uso, y el 86 % de ellas ha ampliado la protección de su cortafuegos de aplicaciones web (WAF) o de sus API a ese tráfico. Los controles específicos para la IA van a la zaga. Solo el 43 % inspecciona las herramientas de los agentes y el tráfico del protocolo de contexto de modelos (MCP), aunque el 49 % prevé hacerlo en los próximos 12 meses. Los entornos maduros llevan la delantera en la limitación de la tasa de solicitudes y las cuotas de tokens (80 % frente al 50 %), pero esa ventaja desaparece en la inspección de prompts y del tráfico MCP. Las prácticas de gobernanza desarrolladas para las cargas de trabajo tradicionales ayudan, pero aún no lo cubren todo.

Qué implica el estudio para tu infraestructura tecnológica

El estudio no apunta a un único producto. Señala carencias, y esas carencias se corresponden con distintos roles. La observabilidad comienza con la telemetría en el edge, que compete a los equipos de plataforma y redes. Web application and API protection (WAAP) presenta una de las mayores brechas tecnológicas entre niveles: lo utiliza el 69 % de los entornos de categoría empresarial, frente al 50 % del resto. Se trata de una política cuya responsabilidad recae en los equipos de seguridad y que todos los clústeres deben heredar. La conmutación por error debe probarse entre clústeres, lo que requiere la colaboración de los equipos de redes y plataforma.

El enfoque de F5 se adapta a la forma en que estos equipos trabajan en la práctica. Los equipos de Kubernetes parten del código abierto, ya que una pila de software como Kubernetes lo convierte en la opción predeterminada. Pueden empezar con proyectos como NGINX Ingress Controller, una solución de Ingress con soporte a largo plazo pese a la retirada del proyecto comunitario ingress-nginx, o NGINX Gateway Fabric, que cumple plenamente con la especificación Gateway API.

Con el tiempo, buscan las garantías que ofrece una solución comercial, y es entonces cuando dan el salto a F5 NGINX Enterprise para disponer de imágenes reforzadas, identidad en el perímetro, políticas de seguridad por aplicación, acuerdos de nivel de servicio de soporte o capacidad de escalado para toda la flota.

Los equipos de redes y seguridad quieren que Kubernetes se adapte a sus prácticas actuales, por lo que F5 BIG-IP con Container Ingress Services (CIS) les permite aplicar políticas centralizadas de tráfico y seguridad y gestionar la conmutación por error entre clústeres desde BIG-IP, mientras los equipos de plataforma siguen trabajando en Kubernetes.

Para las cargas de trabajo de IA que se ejecutan a la escala de una neocloud o una fábrica de IA, F5 BIG-IP Next for Kubernetes amplía este enfoque con una gestión del tráfico y una seguridad diseñadas para la IA en Kubernetes. Cada equipo conserva las herramientas que le resultan familiares, y el punto de control compartido mantiene a todos coordinados.

Nuestro documento técnico complementario estructura este proceso en cuatro fases, cada una con sus propios criterios de finalización. El calendario es orientativo, así que empiece por la fase que corresponda a su nivel de madurez actual y adapte los plazos a sus circunstancias.

1. Estandarizar (meses 0–3): un único patrón de ingress compatible en cada clúster, telemetría en el perímetro y funciones de plataforma y seguridad definidas.
2. Establecer (meses 3–9): un estándar de Gateway API, un WAF para la seguridad heredada y telemetría centralizada.
3. Nivel empresarial (meses 9–18): control de admisión automatizado, un único punto de control para el tráfico y las políticas, y conmutación por error probada.
4. Optimizar (a partir del mes 18): salvaguardas de IA, políticas como código y reevaluación trimestral del nivel de madurez.

En la fase 4, la IA vuelve a entrar en escena, como en las cargas de trabajo de aprendizaje automático que mencioné antes. Los equipos llegan a este punto sobre la base que ya han construido con F5 NGINX Enterprise y BIG-IP con CIS. Para operar a la escala de las neoclouds y las fábricas de IA, esa base puede ampliarse con BIG-IP Next for Kubernetes. Sea cual sea la escala, la tecnología solo funciona tan bien como las alianzas que la sustentan.

Encuentre su punto de partida. Descargue una hoja de ruta para alcanzar un nivel de madurez de Kubernetes de categoría empresarial, con una autoevaluación y un plan paso a paso. A continuación, lea El estado de la estrategia de Kubernetes empresarial en 2026 para consultar el estudio completo.

Además, no te pierdas nuestro artículo del blog, «Control del tráfico y seguridad nativos de la nube para Kubernetes: diseñados para todos los equipos».

Sobre el autor

Buu LamDirector de Evangelización Comunitaria

Más artículos de Buu Lam