A principios de 2018, me encontraba una y otra vez manteniendo conversaciones similares con amigos y compañeros expertos en redes y en los nuevos estándares 5G: todos sentíamos cierta inquietud ante la rapidez con la que avanzábamos hacia una transición plagada de incógnitas. Todos entendíamos que el 5G iba a impulsar la transición hacia los contenedores y la arquitectura nativa de la nube, pero también sabíamos que Kubernetes y otras herramientas nativas de la nube se habían creado originalmente pensando en casos de uso totalmente distintos. Lo que todos veíamos (y probablemente también muchos de quienes leen esta publicación) era que nuestro sector se encaminaba de lleno hacia serios quebraderos de cabeza.
Desde aquellos días de incertidumbre, los proveedores de servicios de comunicaciones (CSP) han comenzado el verdadero trabajo de migración a una infraestructura nativa de la nube. Los pioneros en estas implementaciones están descubriendo obstáculos inesperados en áreas críticas de las redes de Kubernetes, cuyo diseño original no permite satisfacer las exigencias de los casos de uso de los proveedores de servicios. Tanto si el objetivo del operador de telecomunicaciones es avanzar hacia la implementación de un núcleo 5G independiente (SA) como si forma parte de una iniciativa de modernización con una arquitectura de nube distribuida, adaptar Kubernetes para que admita la interoperabilidad de redes, la escalabilidad de nivel operador y las políticas de seguridad de los operadores es fundamental en toda la infraestructura nativa de la nube.
Dado que Kubernetes ha evolucionado desde entonces centrándose principalmente en casos de uso web y de TI ejecutados en la nube pública o en entornos empresariales, es comprensible que nunca se contemplara el conjunto específico de requisitos y protocolos necesarios para implementar los casos de uso de los proveedores de servicios. Afortunadamente, los arquitectos de Kubernetes establecieron un sólido conjunto de patrones de diseño que permiten ampliar Kubernetes, abriendo así el camino a casos de uso fundamentales para las empresas de telecomunicaciones, como la gestión, la visibilidad y el control del tráfico de red, así como la compatibilidad con protocolos adicionales como HTTP/2, GTP, SIP y Diameter.
Antes de describir qué mejoras son necesarias para adaptar Kubernetes a los casos de uso actuales de los proveedores de servicios, identifiquemos primero los requisitos específicos de una red de proveedor de servicios.
Kubernetes debe integrarse en un ecosistema más amplio
En primer lugar, un clúster de Kubernetes debe integrarse con la red y las operaciones generales del proveedor de servicios. Las decisiones arquitectónicas pueden tener repercusiones a largo plazo, como un aumento de los costes operativos y de la complejidad. Los arquitectos de redes deben tener en cuenta los múltiples casos de uso de las empresas de telecomunicaciones, la compatibilidad con protocolos heredados y cómo los cambios dinámicos dentro de Kubernetes pueden afectar a la topología de red existente, lo que podría aumentar la complejidad.
En segundo lugar, las cargas de trabajo de telecomunicaciones (funciones de red) son diferentes de las cargas de trabajo de TI. Las redes de los proveedores de servicios y sus funciones de red utilizan más que los protocolos estándar HTTP/HTTPS o TCP. Será fundamental que los operadores móviles cuenten con compatibilidad de red tanto para protocolos 3G/4G heredados, como SIP, GTP, SCTP, etc., como para HTTP/2 en 5G. En comparación con las cargas de trabajo de TI, las cargas de trabajo de telecomunicaciones también incorporan una capa adicional de estándares sobre las capas de red tradicionales.
Por último, aunque no por ello menos importante, la seguridad es primordial en todos los nuevos puntos de exposición, que requieren nuevas funciones de automatización, visibilidad y gestión. La seguridad debe implementarse en todas las capas y funcionar de forma conjunta con los nuevos clústeres al introducir nuevas tecnologías. Los equipos de SecOps de los proveedores de servicios buscan constantemente formas de reducir la superficie de ataque y mantener un control de seguridad coherente. Además, las políticas de seguridad generales de la red deben actualizarse y poder adaptarse con el tiempo.
Dos enfoques actuales para abordar estas carencias funcionales
Eludir los patrones de Kubernetes
Eludir los patrones nativos de la nube indica que los arquitectos se ven obligados a crear soluciones improvisadas, ya que Kubernetes no incluye de forma nativa las herramientas necesarias para gestionar las cargas de trabajo de las empresas de telecomunicaciones. Hemos observado varias formas preocupantes en las que estas empresas están rompiendo dichos patrones:
- Elusión de las redes de Kubernetes – La gran mayoría de las CNF sitúan una o varias interfaces fuera del control de Kubernetes. Estas CNF requieren acceso directo a la red (a menudo planteado como una solicitud de «Multus» para permitir una interfaz adicional con conexión directa al exterior). Al no existir un punto central de control de la red, la complejidad interna de Kubernetes queda expuesta a la red externa del proveedor de servicios, lo que aumentará la complejidad y los costes operativos, así como la superficie expuesta a ataques de seguridad. También exige un mayor esfuerzo a los desarrolladores de aplicaciones o funciones de red y a los operadores de red para gestionar las direcciones IP y lidiar con la naturaleza dinámica de los contenedores en Kubernetes, que ahora queda expuesta al mundo exterior.
- Clústeres independientes para cada función de red – Las redes de Kubernetes no proporcionan de forma nativa un punto central para el tráfico de red entrante y saliente. Kubernetes ofrece cierto control del tráfico entrante, pero ignora casi por completo el tráfico saliente, y no existe ninguna forma integrada de vincular las redes de entrada y salida. Hemos visto varias implementaciones en las que cada función de red se ejecuta en su propio clúster para poder correlacionar las direcciones IP de los servidores con las de las funciones de red. Esto genera una sobrecarga adicional de recursos y un mayor gasto de capital (CapEx), además de añadir complejidad operativa, lo que se traduce en un mayor gasto operativo (OpEx).
Alinearse con los patrones de Kubernetes
Un enfoque alternativo consiste en adoptar los patrones de diseño de Kubernetes e introducir un proxy de servicios que proporcione una «vista unificada» de las redes de entrada y salida y de la seguridad entre el clúster de Kubernetes y el mundo exterior. El objetivo de un proxy de servicios es suplir las carencias funcionales que presenta Kubernetes cuando se utiliza en el entorno de un proveedor de servicios. Un proxy de servicios debe:
- Usar patrones nativos de Kubernetes para ampliar las capacidades de red de Kubernetes (definiciones de recursos personalizados, bucle de control de K8s)
- Interactuar con una red más amplia (enrutamiento BGP, asignaciones de direcciones IP SNAT de salida, traducción IPv4/IPv6)
- Vincular el tráfico de entrada y salida de forma individual para cada CNF
- Ofrecer una amplia compatibilidad con L4/L7 (TCP, UDP, SCTP, NGAP, HTTP/2, Diameter, GTP, SIP)
- Proporcionar una capa de seguridad (terminación TLS, cortafuegos, protección contra DDoS, cortafuegos de aplicaciones web)
- Presentar una CNF coherente, ocultando los eventos altamente dinámicos de Kubernetes
El enfoque de F5: presentación del proxy de servicio
F5 ha optado por el segundo escenario descrito anteriormente para ampliar Kubernetes y crear este proxy de servicios que proporcione la funcionalidad que falta. Basándonos en nuestras décadas de experiencia en gestión y seguridad del tráfico, creemos que se trata de una función esencial para respaldar la migración a gran escala a entornos nativos de la nube. Ya disponible y listo para entornos de producción, hemos desarrollado BIG-IP Next Service Proxy for Kubernetes (SPK), un producto de infraestructura nativo de la nube que aborda directamente las carencias de Kubernetes y permite a los proveedores de servicios crear recursos de los que carece Kubernetes «estándar». SPK simplifica y protege la arquitectura mediante un marco que automatiza los procesos y se integra perfectamente con políticas más amplias de red y seguridad. Este enfoque de Kubernetes para las empresas de telecomunicaciones seguirá reduciendo la complejidad y los costes operativos, además de proporcionar una infraestructura más resiliente y segura. Dado que actualmente estamos asistiendo a una ralentización de la transición a 5G SA (Los operadores de telecomunicaciones no logran implantar 5G SA, según GlobalData), cabe suponer que la transición se estancará aún más si no se introduce un proxy de servicios adecuado. Los clientes del sector de las telecomunicaciones que ya lo utilizan en producción y se encuentran inmersos en una modernización digital a gran escala están comprobando que SPK está demostrando ser la solución de Kubernetes al problema de la arquitectura de red 5G que ni siquiera sabían que tenían.
SPK de F5 ya está disponible de forma general (GA) y actualmente se utiliza en entornos de producción de operadores de telecomunicaciones a gran escala. No se pierda los próximos eventos, en los que mostraremos las capacidades de SPK frente a otros enfoques y explicaremos cómo certificar las CNF en nuestra plataforma. Para obtener más información, visite esta página, y si desea hablar directamente con un miembro del equipo de F5, póngase en contacto con nosotros.
Sobre el autor
Artículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.