Mejore la arquitectura de la red 5G de telecomunicaciones con Service Proxy para Kubernetes
A principios de 2018, seguía teniendo conversaciones similares con mis amigos y colegas que eran expertos en redes y estándares 5G emergentes. Todos teníamos una vaga incomodidad de que nos apresurábamos hacia una transición con MUCHAS incógnitas. Todos comprendíamos que 5G iba a impulsar una transición hacia contenedores y una arquitectura nativa de la nube, pero también sabíamos que Kubernetes y otras herramientas nativas de la nube se crearon originalmente con un conjunto totalmente diferente de casos de uso en mente. Lo que todos vimos (y probablemente muchos de los que leen esta publicación también observaron) fue que nuestra industria estaba camino de colisionar con la acidez estomacal.
Desde aquellos días preocupantes, los proveedores de servicios de comunicación (CSP) han comenzado el verdadero trabajo de migrar a una infraestructura nativa de la nube. Los pioneros de estas implementaciones de hecho están descubriendo barreras inesperadas donde las áreas críticas en la red Kubernetes tal como fue diseñada originalmente no pueden satisfacer las demandas de los casos de uso de los proveedores de servicios. Ya sea que el objetivo de la empresa de telecomunicaciones sea avanzar hacia una implementación de núcleo autónomo (SA) 5G o ser parte de una iniciativa de modernización con una arquitectura de nube distribuida, la adaptación de Kubernetes para soportar la interoperabilidad de la red, la escala de nivel de operador y las políticas de seguridad del operador son capacidades críticas necesarias en toda la infraestructura nativa de la nube.
Dado que Kubernetes ha evolucionado desde entonces principalmente para centrarse en casos de uso de TI y web que se ejecutan en la nube pública o en entornos empresariales, es comprensible que nunca se haya planificado el conjunto único de requisitos y protocolos para implementar casos de uso de proveedores de servicios. Afortunadamente, sin embargo, los arquitectos de Kubernetes implementaron un conjunto sólido de patrones de diseño que hacen que Kubernetes sea extensible, creando un camino para casos de uso fundamentales de telecomunicaciones: para la gestión del tráfico de red, la visibilidad y el control, y soporte extendido de protocolos como HTTP/2, GTP, SIP y Diameter.
Antes de describir qué mejoras son necesarias para que Kubernetes se adapte a los casos de uso de los proveedores de servicios actuales, identifiquemos primero los requisitos únicos que conlleva una red de proveedores de servicios.
Kubernetes debe encajar en un ecosistema más grande
En primer lugar, un clúster de Kubernetes debe integrarse con la red y las operaciones del proveedor de servicios más amplias. Las decisiones arquitectónicas pueden tener ramificaciones a largo plazo, en términos de mayor complejidad y costos operativos. Los arquitectos de redes deben tener en cuenta múltiples casos de uso de telecomunicaciones, soporte para protocolos heredados y cómo los cambios dinámicos dentro de Kubernetes pueden afectar la topología de la red existente, lo que potencialmente conduce a una mayor complejidad.
En segundo lugar, las cargas de trabajo de telecomunicaciones (funciones de red) son diferentes a las cargas de trabajo de TI. Las redes de proveedores de servicios y sus funciones de red utilizan más que solo el estándar HTTP/HTTPS o TCP. Será fundamental que los proveedores de telefonía móvil cuenten con soporte de red tanto para los protocolos 3G/4G tradicionales, como SIP, GTP, SCTP, etc., como para el 5G HTTP2. Las cargas de trabajo de telecomunicaciones también tienen una capa adicional de estándares que se ubican sobre las capas de red tradicionales en comparación con las cargas de trabajo de TI.
Por último, pero no menos importante, la seguridad es primordial para 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 trabajar en conjunto con los nuevos clústeres cuando se introducen nuevas tecnologías. Los equipos de SecOps de los proveedores de servicios siempre buscan formas de reducir la superficie de ataque y tener un control de seguridad constante. Además, es necesario actualizar y adaptar políticas de seguridad más amplias de la red a lo largo del tiempo.
Dos enfoques actuales para abordar estas brechas funcionales
Evitar los patrones de Kubernetes
Eludir los patrones nativos de la nube es un indicador de que los arquitectos se ven obligados por necesidad a crear hacks, porque Kubernetes no viene de forma nativa con las herramientas para gestionar las cargas de trabajo de las empresas de telecomunicaciones. Hemos observado varias formas preocupantes en las que las empresas de telecomunicaciones están rompiendo los patrones:
- Cómo eludir las redes de Kubernetes: la gran mayoría de las CNF colocan una o más interfaces fuera del control de Kubernetes. Estas CNF requieren acceso directo a la red (que a menudo se presenta como una solicitud de “multus” para permitir una interfaz adicional directa al exterior). Sin un punto central de control de red, esto expone la complejidad interna de Kubernetes a la red del proveedor de servicios externo, lo que generará una mayor complejidad y costos operativos, así como una mayor superficie de ataque a la seguridad. Esto también supone una mayor exigencia para cualquier desarrollador de aplicaciones o funciones de red y para cualquier operador de red en lo que respecta a la gestión de direcciones IP, así como al manejo de la naturaleza dinámica de los contenedores en Kubernetes, que ahora están expuestos al mundo exterior.
- Clústeres separados para cada función de red: la red Kubernetes no proporciona de forma nativa un punto central para el ingreso y egreso del tráfico de red. Kubernetes proporciona cierto control de ingreso, pero ignora casi por completo el tráfico de egreso, y no hay una forma integrada de vincular las redes de ingreso y egreso. Hemos visto múltiples implementaciones donde cada función de red se ejecuta en su propio clúster, para permitir la correlación entre las direcciones IP de los servidores y las direcciones IP de las funciones de red. Esto genera una sobrecarga de recursos adicional y un mayor gasto de CapEx, al tiempo que agrega complejidad operativa, lo que resulta en un mayor gasto de OpEx.
Alinearse con los patrones de Kubernetes
Un enfoque alternativo es alinearse con los patrones de diseño de Kubernetes e introducir un proxy de servicio que proporcionará un “panel único” para la red de entrada/egreso y la seguridad del clúster de Kubernetes hacia el mundo exterior. El objetivo de un proxy de servicio es llenar los vacíos funcionales que presenta Kubernetes cuando se utiliza en un entorno de proveedor de servicios. Un proxy de servicio debe:
- Utilice patrones nativos de Kubernetes para ampliar la red de Kubernetes (definiciones de recursos personalizados, bucle de control de K8s)
- Interfaz con una red más amplia (enrutamiento BGP, asignaciones de IP SNAT de salida, traducción IPv4/v6)
- Vincular la entrada y la salida individualmente para cada CNF
- Proporcionar amplio soporte L4/L7 (tcp, udp, sctp, NGAP, HTTP/2, Diameter, GTP, SIP)
- Proporcionar una capa de seguridad (terminación TLS, firewall, DDoS, firewall de aplicação web)
- Presentar CNF consistente , ocultando eventos de Kubernetes altamente dinámicos
El enfoque de F5: Introducción al proxy de servicio
F5 ha elegido el segundo escenario descrito anteriormente para ampliar Kubernetes y crear este proxy de servicio para proporcionar esta funcionalidad faltante. Basándonos en nuestras décadas de experiencia en gestión de tráfico y seguridad, creemos que es una función fundamental necesaria para respaldar la migración nativa de la nube a gran escala. Listo para producción y disponible ahora, hemos desarrollado el producto de infraestructura nativa de la nube BIG-IP Next Service Proxy para Kubernetes (SPK), para abordar directamente las deficiencias de Kubernetes y permitir que los proveedores de servicios creen recursos de los que carece el Kubernetes “básico”. SPK simplifica y protege la arquitectura, con un marco que automatiza y se integra sin problemas con políticas de seguridad y red más amplias. Este enfoque de Kubernetes para las empresas de telecomunicaciones seguirá generando una menor complejidad y menores costos operativos, además de una infraestructura más resistente y segura. Como hoy estamos presenciando una desaceleración en la transición a 5G SA ( los operadores de telecomunicaciones están fallando en 5G SA, según GlobalData ), es seguro asumir que la transición flaqueará aún más sin la introducción de un proxy de servicio adecuado. Los clientes de telecomunicaciones en producción en medio de una modernización digital a gran escala están descubriendo que SPK está demostrando ser la solución de Kubernetes al problema de arquitectura de red 5G que ni siquiera sabían que tenían.
El SPK de F5 ya está disponible en formato GA y se encuentra actualmente en producción con grandes empresas de telecomunicaciones. Busque los próximos eventos en los que demostraremos las capacidades de SPK en comparación con otros enfoques y cómo certificar 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, contáctenos .