La réussite en 5G commence par une infrastructure cloud native
La 5G transforme le paysage numérique pour les fournisseurs de services, en apportant avec elle de nouveaux cas d’utilisation et de nouvelles possibilités de revenus. Les fournisseurs de services capables de réussir la transition vers la 5G peuvent bénéficier de nouvelles applications d’entreprise, de l’automatisation industrielle, de l’IdO, ainsi que de services grand public comme les jeux et l’AR/VR. Ces nouveaux cas d’utilisation sont rendus possibles grâce à un nouveau noyau autonome 5G (SA) construit sur une architecture basée sur les services (SBA) native cloud. Afin de tirer le meilleur parti de ces nouvelles possibilités, les fournisseurs de services doivent définir et déployer une infrastructure native cloud cohérente du cœur à la périphérie, capable de prendre en charge les fonctions de réseau (NF) du 5G Core, du vRAN et du N6-LAN, ainsi que les applications et services d’entreprise et grand public. L’infrastructure native cloud est la fondation de la réussite d’un fournisseur de services avec la 5G.
L’infrastructure étant un élément essentiel des déploiements 5G, qui détermine la capacité d’un fournisseur de services à réaliser pleinement les nouveaux cas d’utilisation 5G, il est impératif que les fournisseurs de services définissent, gèrent et contrôlent leur propre infrastructure 5G native cloud. Il existe de nombreux précédents de concentration des investissements sur l’infrastructure. On peut citer les hyperscalers Google, AWS, Azure et même Apple ; toutes ces entreprises ont investi massivement dans la construction d’une infrastructure capable de fournir de manière fiable et sûre des services et des applications clients qui génèrent des revenus.
Tirant parti des technologies qui alimentent les applications web modernes d’aujourd’hui, l’infrastructure 5G est construite sur une architecture conteneurisée native cloud qui permet de nouveaux niveaux d’automatisation opérationnelle, de flexibilité et d’adaptabilité pour le fournisseur de services. Kubernetes est devenu la référence du secteur en matière de gestion et d’orchestration des conteneurs, et pratiquement tous les fournisseurs de services l’utilisent pour leur infrastructure native cloud. Cependant, les réseaux de fournisseurs de services imposent des exigences nouvelles et uniques en matière de flux de données vers et au sein du cluster Kubernetes. Kubernetes n’est pas équipé en natif pour répondre à ces demandes. Dans les sections suivantes, nous examinerons les exigences uniques qu’une infrastructure native cloud doit satisfaire pour prendre en charge les vRAN, les NF du 5G Core et les applications d’entreprise et grand public, puis nous verrons comment F5 répond à ces exigences.
Pour que les fournisseurs de services puissent fournir des services fiables, sûrs et évolutifs, ils doivent tenir compte de trois principaux types d’exigences :
- Contrôle : les fournisseurs de services doivent être en mesure d’appliquer un contrôle des politiques sur plusieurs types de trafic qui sont propres à un réseau de fournisseurs de services. Pouvoir appliquer une gestion intelligente du trafic permettra aux fournisseurs de prendre en charge de nouveaux services comme le découpage du réseau, de soutenir la transition des protocoles 4G vers les protocoles 5G, et de fournir les bases nécessaires aux nouveaux cas d’utilisation de la 5G.
- Sécurité : afin de maintenir un niveau élevé de confiance et de fidélisation des clients, les contrôles de sécurité doivent être appliqués en plusieurs points et sur plusieurs couches du réseau.
- Visibilité : la visibilité du flux de trafic vers et dans l’infrastructure améliorera l’efficacité opérationnelle, augmentera l’efficacité du dépannage, et rendra le contrôle du revenu plus flexible.
Tout d’abord, nous examinerons les exigences et les solutions pour la mise en réseau des entrées/sorties du cluster Kubernetes, également appelé « trafic nord-sud » La mise en réseau standard de Kubernetes est suffisante pour la plupart des applications web fonctionnant dans un environnement cloud où HTTP/HTTPS est le principal protocole de communication vers et au sein du cluster Kubernetes. Un environnement de fournisseur de services présente des défis uniques pour la mise en réseau de Kubernetes en raison de la nécessité de prendre en charge un ensemble de protocoles. Le passage à la 5G ne sera pas un changement radical ; la plupart des fournisseurs de services devront faire fonctionner la 4G et la 5G simultanément, et ils ont besoin d’une solution de migration qui les aidera à le faire. Par exemple, au fur et à mesure du déploiement du noyau 5G SA, de nombreux fournisseurs de services exploiteront leurs systèmes de facturation et d’imputation existants de la 4G pour accélérer la fourniture de la 5G, ce qui leur permettra d’obtenir plus rapidement un retour sur leur investissement dans la 5G. Cela signifie que leurs clusters Kubernetes doivent prendre en charge à la fois les protocoles 4G et 5G. Un proxy de service pour le contrôle des entrées et des sorties est nécessaire pour améliorer la fonctionnalité existante de Kubernetes.
Figure 1 : Le proxy de service F5® BIG-IP® pour Kubernetes facilite la prise en charge de plusieurs protocoles.
Un proxy de service fournissant un contrôle des entrées et sorties sera en mesure de répondre aux exigences strictes d’un réseau de fournisseurs de services en fournissant des services de mise en réseau améliorés pour Kubernetes :
- Prise en charge de plusieurs protocoles, y compris la signalisation 4G et 5G
- Routage
- Équilibrage de charge
Au point d’entrée du cluster Kubernetes, les fournisseurs de services doivent également protéger le cluster contre les attaques et fournir une visibilité par abonné. La première ligne de défense consiste à appliquer un ensemble de services de sécurité robustes au point d’entrée dans la grappe. Les services de sécurité tels que la protection DDoS, le pare-feu et le WAF peuvent être appliqués à l’entrée pour empêcher le trafic malveillant d’entrer dans le cluster et d’avoir un impact sur les fonctions réseau du 5G Core et les applications des clients. En plus de la sécurité d’entrée, les fournisseurs de services ont besoin de visibilité sur le trafic par abonné. Ces données précieuses aident à résoudre les problèmes de réseau et peuvent également être utilisées pour garantir les revenus. Les fournisseurs de services dépensent énormément d’argent pour s’assurer que les événements peuvent être suivis à des fins de conformité et de facturation. Ces données peuvent être recueillies au point d’entrée du cluster Kubernetes et ensuite comparées aux rapports de l’ensemble dynamique de conteneurs.
Figure 2 : Un proxy de service peut contribuer à améliorer la sécurité et la visibilité en suivant les données à l’entrée.
En résumé, un proxy de service assurant le contrôle d’entrée/sortie, la sécurité et la visibilité fournit la fonctionnalité critique dont Kubernetes a besoin pour répondre aux exigences d’une infrastructure 5G native du cloud.
Maintenant que nous avons abordé les exigences du trafic nord-sud dans une infrastructure basée sur Kubernetes, nous pouvons examiner les exigences et les défis du trafic au sein du cluster. Comme pour l’entrée et la sortie, la communication est-ouest entre les services fonctionnant au sein du cluster doit répondre à des normes d’observabilité et de sécurité plus élevées afin d’être compatible avec l’infrastructure 5G native cloud. Les fournisseurs de services doivent être en mesure d’appliquer des politiques de sécurité qui contrôlent la communication entre les services au sein du cluster. La désagrégation du 5G Core crée une exigence d’observabilité accrue au sein du cluster, pour permettre aux fournisseurs de services d’évaluer la santé de leurs services et d’identifier la cause profonde des défaillances éventuelles. Les fournisseurs de services doivent également s’assurer que leur infrastructure a la capacité de répondre aux exigences gouvernementales, telles que l’interception légale. Ces exigences présentent des défis pour la mise en réseau et les contrôles de Kubernetes. Une méthode pour relever ces défis consiste à mettre en œuvre un maillage de services tel qu’Istio, qui ajoute les capacités suivantes :
- Fiabilité : tentatives répétées, délais de connexion, atténuation des défaillances en cascade
- Observabilité et débogage : surveillance, traçage, métriques
- Sécurité : authN/authZ, gestion des secrets, garantie du cryptage
- Gestion du trafic : découverte de services, routage personnalisé, déploiement de canaris
Figure 3 : F5® Aspen Mesh™ améliore la visibilité et la sécurité de la communication est-ouest au sein d’un cluster Kubernetes.
F5 est un leader des services d’application, de réseau et de sécurité, et fournit toute une gamme de solutions pour les infrastructures de noyau 5G et 5G natives cloud. F5 propose deux produits principaux qui répondent aux défis auxquels les fournisseurs de services sont confrontés lors de la mise en place d’une infrastructure native du cloud pour répondre aux exigences de réseau et de sécurité pour le vRAN, le 5G Core et les applications d’entreprise.
- F5 BIG-IP Service Proxy pour Kubernetes (BIG-IP SPK)
- Carrier-Grade Aspen Mesh
BIG-IP SPK est unique dans l’industrie, offrant un contrôle des entrées et sorties avec la prise en charge de la signalisation multiprotocole et une sécurité spécialement conçue pour les fournisseurs de services déployant une infrastructure native cloud sur l’ensemble de leur territoire. BIG-IP SPK s’aligne également sur les modèles de conception de Kubernetes pour la configuration et l’orchestration. Cette solution permet d’appliquer des fonctions de réseau et de sécurité de pointe à une infrastructure basée sur Kubernetes.1
Contrôle des entrées et sorties
- Équilibrage de charge L4 : TCP, UDP et SCTP
- Équilibrage de charge L7 : Diameter, SIP, HTTP/2
- Équilibrage de charge GTPcV2
- Routage
- Limitation des débits
Sécurité
- Pare-feu de signalisation, DDoS, WAF
- Cryptage/décryptage
- Masquage de la topologie
Visibilité
- Assurance des recettes
- Statistiques et analyses
De plus, BIG-IP SPK peut tirer parti des capacités améliorées du SmartNIC d’Intel pour des performances et une évolutivité accrues.
Figure 4 : BIG-IP Service Proxy pour Kubernetes peut s’intégrer à SmartNIC pour une performance accrue.
Carrier-Grade Aspen Mesh est un maillage de service conçu spécialement pour les infrastructures natives cloud des fournisseurs de services. Le maillage de services Aspen Mesh est basé sur le logiciel libre Istio et ajoute des fonctionnalités essentielles pour un réseau de fournisseurs de services.
- Une visibilité du trafic inégalée au sein de chaque cluster Kubernetes du 5G Core, afin de garantir les revenus et de permettre aux fournisseurs de services de monétiser la 5G en utilisant les systèmes de facturation existants.
- Une sécurité renforcée avec une approche cohérente pour le cryptage et l’authentification de tout le trafic entre les fonctions de réseaux multifournisseurs et multisites, fondée sur les techniques mTLS les plus robustes et adossé à une autorité de certification de classe opérateur et compatible avec 3GPP.
- Le contrôle du trafic et la gestion des politiques qui permettent aux fournisseurs de services d’acheminer efficacement les communications de service et d’appliquer des politiques commerciales et de conformité pour le maillage des services et le trafic du réseau.
Aspen Mesh fournit également des capacités de capture de paquets, que les Kubernetes standard ne fournissent pas. La capture de paquets facilite le dépannage des problèmes de communication entre les CNF au sein du cluster et donne aux fournisseurs de services l’infrastructure nécessaire pour se conformer aux exigences gouvernementales comme l’interception légale.
BIG-IP SPK et Carrier-Grade Aspen Mesh travaillent en équipe pour résoudre les différents défis liés à l’utilisation de Kubernetes dans une infrastructure 5G native du cloud. BIG-IP SPK répond aux besoins de support de signalisation multiprotocoles, de sécurité et de visibilité du trafic dans le cluster Kubernetes, tandis que le Carrier-Grade Aspen Mesh s’occupe de la communication entre les CNF. Les deux sont essentiels au déploiement d’une infrastructure 5G native cloud. La figure ci-dessous représente une infrastructure 5G utilisant BIG-IP SPK et Aspen Mesh.
Figure 5 : Architecture réseau native cloud
Les fournisseurs de services comprennent le rôle central que jouera une infrastructure native cloud dans le succès de leur déploiement 5G, et dans leur capacité à prendre en charge les applications et les services rendus possibles par un nouveau réseau 5G. Les fournisseurs de services recherchent des solutions qui leur apporteront le contrôle, la sécurité et la visibilité nécessaires à l’infrastructure native du cloud 5G. F5 comprend les exigences d’un réseau de fournisseurs de services et fournit des solutions qui permettent aux fournisseurs de services d’utiliser Kubernetes pour construire et déployer avec succès leur infrastructure 5G native cloud.
1 Contactez F5 pour connaître la disponibilité des fonctionnalités.
Connect with F5
