A medida que las empresas de telecomunicaciones líderes en la actualidad construyen sus redes centrales para respaldar servicios móviles 5G de alto valor, las decisiones clave que toman desde el principio con respecto a sus arquitecturas de malla de servicios pueden afectar en gran medida el nivel de funcionalidad, flexibilidad, monitoreo y seguridad de la red 5G de sus datos los centros pueden esperar.
La malla de servicios es una tecnología nativa de la nube que proporciona administración de tráfico, seguridad, conocimientos de comportamiento y control operativo sobre la red de microservicios que se ejecutan dentro de un clúster de Kubernetes. El plano de control de la malla de servicios es el medio por el cual los centros de datos administran uno o más proveedores y sus respectivas funciones de red 5G nativas de la nube en la plataforma Kubernetes.
En este artículo, consideraremos los pros y los contras de aprovechar cuatro patrones de malla de servicios diferentes utilizados para implementar microservicios nativos de la nube en las plataformas de nube de Kubernetes, lo que finalmente impulsa las redes centrales 5G en los centros de datos de telecomunicaciones. Estos cuatro casos de uso incluyen el alojamiento de todas las funciones de red nativas de la nube (CNF) de:
- Un solo proveedor que usa una sola malla de servicios en un solo clúster de Kubernetes
- Diferentes proveedores que utilizan una sola malla de servicios en un solo clúster de Kubernetes
- Diferentes proveedores que utilizan múltiples mallas de servicio en un solo clúster de Kubernetes
- Diferentes proveedores que utilizan múltiples mallas de servicio en múltiples clústeres de Kubernete
Proveedor único / Malla única / Clúster único
El cambio de las funciones de red física (PNF) a las funciones de red virtual (VNF) y ahora al entorno de contenedores como servicio (CaaS) nativo de la nube ha dado lugar a enormes desafíos tecnológicos para la industria de las telecomunicaciones. En la actualidad, las implementaciones de malla de servicios, como Istio, Linkerd, Consul y Kuma, proporcionan un marco que brinda a los centros de datos control, incluida la seguridad, la observabilidad y la gestión del tráfico, sobre los microservicios en las CNF (Funciones de red nativas de la nube) que comprenden sus Red central 5G.
Cuando todos los CNF son proporcionados por un solo proveedor de 5G, los centros de datos normalmente podrían usar un solo patrón de malla para orquestar sus funciones en un solo clúster de Kubernetes. El tráfico de la carga de trabajo se puede organizar en espacios de nombres separados (aislamiento de Kubernetes), con una única puerta de enlace de entrada / salida.
El inconveniente es que el centro de datos está bloqueado por un proveedor en particular y no puede contratar servicios con otro que podría ofrecer mejores precios o características. Sin embargo, una ventaja es que el uso de un solo clúster de Kubernetes da como resultado una huella de uso de recursos informáticos ligera.
Diferentes proveedores / Malla única / Clúster único
Cuando la arquitectura admite diferentes proveedores a la vez, el cliente tiene la flexibilidad de adquirir servicios CNF de múltiples proveedores. Con un solo plano de control de malla, se pueden monitorear múltiples funciones de red en un solo tablero. Dado que los proveedores comparten el acceso al mismo clúster de Kubernetes, esta configuración también tiene una huella de utilización de recursos relativamente ligera.
Sin embargo, siempre que los proveedores comparten el mismo clúster de Kubernetes, esencialmente compiten por los recursos de red, como CPU, RAM y capacidad de disco. Sus aplicaciones solo están separadas o limitadas a espacios de nombres, y deben admitir cualquier software de malla de servicios y la versión que esté ejecutando la plataforma Kubernetes. En general, tener que compartir una sola malla y un clúster de Kubernetes genera preocupaciones en los proveedores sobre la seguridad organizacional de su software y cómo se implementará y utilizará.
Si surge un problema técnico pero no está claro qué aplicación del proveedor es responsable, esto podría resultar en acusaciones que hagan que el equipo del centro de datos tome la iniciativa en la resolución de problemas necesaria para restaurar el servicio.
Diferentes proveedores / Malla múltiple / Clúster único
Con varias mallas de servicios dedicadas a diferentes proveedores en el mismo clúster de Kubernetes, los planos de control de la malla de servicios independientes crean un aislamiento de tenencia múltiple. Este aislamiento da como resultado un mayor grado de seguridad. Cada proveedor tiene su propio espacio de nombres dedicado y, con puertas de enlace de entrada / salida independientes, el tráfico de red hacia y desde las funciones (microservicios) viaja a lo largo de rutas independientes.
Si bien este patrón de malla de servicios implica una implementación más compleja, el centro de datos gana al no estar limitado al precio, las características o los servicios ofrecidos por ningún proveedor en particular. En términos de inconvenientes, las mallas de servicios múltiples están restringidas a ver su propio plano de datos específico del proveedor respectivo utilizando sus propias interfaces gráficas de usuario (GUI) y, como resultado, este patrón de malla de servicios carece de un solo punto de monitoreo y control.
Para el monitoreo de las operaciones de red, los centros de datos pueden usar paneles, como Kiali, Prometheus, Jaeger y Grafana. Este caso de uso de malla de servicios en particular promueve una huella de recursos relativamente ligera, pero la plataforma consume recursos adicionales necesarios para admitir múltiples mallas de servicios.
Diferentes proveedores / Malla múltiple / Clústeres múltiples
El beneficio de aprovechar múltiples clústeres de Kubernetes para múltiples proveedores es que cada proveedor puede obtener un mayor grado de aislamiento y flexibilidad. Los proveedores se benefician al obtener el aislamiento de seguridad de sus cargas de trabajo debido a los clústeres de Kubernetes aislados que se ejecutan en máquinas físicas o virtuales separadas. Esta configuración también es beneficiosa porque involucra plataformas de malla de servicios completamente independientes. Este aislamiento de múltiples inquilinos brinda a los proveedores una mayor sensación de seguridad y no tienen que competir entre sí por los recursos del centro de datos.
En comparación con los tres casos de uso de malla de servicios anteriores, el uso de varios clústeres de Kubernetes da como resultado el mayor consumo de recursos. Al igual que en el tercer caso de uso, las mallas de servicios múltiples están restringidas a ver su propio plano de datos específico del proveedor respectivo, por lo que carecen de un solo punto de control.
De estos cuatro casos de uso destacados, el patrón de proveedor único / malla única / clúster único es el más simple de estructurar e implementar, implica menos complejidad operativa, consume la menor cantidad de recursos y permite una supervisión y un control más centralizados.
Sin embargo, si el equipo del centro de datos desea flexibilidad de múltiples proveedores, pueden colocar diferentes proveedores en clústeres de Kubernetes únicos o múltiples, administrados por una o más instancias de la malla de servicios. La complejidad aumenta a medida que los proveedores, los clústeres de Kubernetes y los planos de control de la malla de servicios deciden implementar dentro de su red central 5G. La utilización de recursos también aumenta en relación con el número de proveedores y grupos involucrados.
Independientemente de cuál de estos cuatro patrones de malla de servicios se adopte, la estrategia que emplean los centros de datos para estructurar su arquitectura de red central y para implementar la malla de servicios tiene un gran impacto en los beneficios, las eficiencias, los desafíos y las limitaciones que finalmente experimentan.