Améliorez l’architecture réseau 5G des opérateurs télécoms grâce à Service Proxy for Kubernetes

Phil Klatte

Début 2018, je me retrouvais régulièrement à avoir des conversations similaires avec mes amis et collègues spécialistes des réseaux et des nouvelles normes 5G : nous éprouvions tous un vague malaise à l’idée de nous précipiter vers une transition comportant BEAUCOUP d’inconnues. Nous savions tous que la 5G allait accélérer la transition vers les conteneurs et une architecture cloud native, mais aussi que Kubernetes et les autres outils cloud native avaient été conçus à l’origine pour des cas d’usage totalement différents. Nous constations tous — comme probablement beaucoup de lecteurs de cet article — que notre secteur fonçait droit vers de sérieux problèmes.

Depuis cette période d’incertitude, les fournisseurs de services de communication (CSP) ont entamé le véritable travail de migration vers une infrastructure cloud native. Les pionniers de ces déploiements découvrent en effet des obstacles inattendus : certains aspects essentiels de la mise en réseau de Kubernetes, telle qu’elle a été conçue à l’origine, ne permettent pas de répondre aux exigences des cas d’usage des fournisseurs de services. Que l’objectif de l’opérateur télécom soit de s’orienter vers le déploiement d’un cœur de réseau 5G autonome (SA) ou qu’il s’inscrive dans une initiative de modernisation reposant sur une architecture cloud distribuée, il est indispensable d’adapter Kubernetes afin de prendre en charge l’interopérabilité des réseaux, le passage à l’échelle de niveau opérateur et les politiques de sécurité propres aux opérateurs dans l’ensemble de l’infrastructure cloud native.

Kubernetes ayant depuis évolué principalement pour répondre aux cas d’usage web et informatiques exécutés dans le cloud public ou dans des environnements d’entreprise, il est compréhensible que l’ensemble spécifique d’exigences et de protocoles nécessaires au déploiement des cas d’usage des fournisseurs de services n’ait jamais été prévu. Heureusement, les architectes de Kubernetes ont mis en place un solide ensemble de modèles de conception qui rendent Kubernetes extensible, ouvrant ainsi la voie aux cas d’usage fondamentaux des opérateurs télécoms : gestion, visibilité et contrôle du trafic réseau, ainsi que prise en charge étendue de protocoles tels que HTTP/2, GTP, SIP et Diameter.

Avant de décrire les améliorations nécessaires pour adapter Kubernetes aux cas d’usage actuels des fournisseurs de services, commençons par identifier les exigences propres à un réseau de fournisseur de services.

Kubernetes doit s’intégrer dans un écosystème plus vaste

Tout d’abord, un cluster Kubernetes doit s’intégrer au réseau et aux opérations plus larges du fournisseur de services. Les décisions architecturales peuvent avoir des répercussions à long terme, notamment en matière d’augmentation des coûts et de la complexité opérationnels. Les architectes réseau doivent prendre en compte les multiples cas d’usage des opérateurs télécoms, la prise en charge des protocoles existants et la manière dont les changements dynamiques au sein de Kubernetes peuvent affecter la topologie réseau existante, avec le risque d’en accroître la complexité.

Deuxièmement, les charges de travail des opérateurs télécoms (fonctions réseau) diffèrent des charges de travail informatiques. Les réseaux des fournisseurs de services et leurs fonctions réseau ne se limitent pas aux protocoles standard HTTP/HTTPS ou TCP. Il sera essentiel pour les opérateurs mobiles de disposer d’une prise en charge réseau à la fois des anciens protocoles 3G/4G, tels que SIP, GTP, SCTP, etc., et du protocole HTTP/2 de la 5G. Par rapport aux charges de travail informatiques, les charges de travail des opérateurs télécoms sont également soumises à une couche supplémentaire de normes qui vient s’ajouter aux couches réseau traditionnelles.

Enfin, et ce point est loin d’être le moins important, la sécurité est primordiale pour tous les nouveaux points d’exposition, qui nécessitent de nouvelles fonctions d’automatisation, de visibilité et de gestion. La sécurité doit être déployée à tous les niveaux et fonctionner de concert avec les nouveaux clusters lors de l’introduction d’une nouvelle technologie. Les équipes SecOps des fournisseurs de services cherchent constamment à réduire la surface d’attaque et à assurer un contrôle cohérent de la sécurité. En outre, les politiques de sécurité globales du réseau doivent être mises à jour et pouvoir évoluer au fil du temps.

Deux approches actuelles pour combler ces lacunes fonctionnelles

Contourner les modèles Kubernetes

Le contournement des modèles cloud natifs indique que les architectes sont contraints de recourir à des solutions de fortune, car Kubernetes ne dispose pas nativement des outils nécessaires pour gérer les charges de travail des opérateurs télécoms. Nous avons observé plusieurs pratiques préoccupantes par lesquelles ces opérateurs s’affranchissent de ces modèles :

• Contournement de la mise en réseau de Kubernetes – La grande majorité des CNF placent une ou plusieurs interfaces hors du contrôle de Kubernetes. Ces CNF nécessitent un accès direct au réseau (souvent formulé sous la forme d’une demande de « multus », afin de permettre l’ajout d’une interface supplémentaire directement connectée à l’extérieur). En l’absence d’un point central de contrôle du réseau, la complexité interne de Kubernetes se trouve exposée au réseau externe du fournisseur de services, ce qui entraînera une augmentation de la complexité et des coûts d’exploitation, ainsi qu’un élargissement de la surface d’attaque. Cela impose également aux développeurs d’applications ou de fonctions réseau et aux opérateurs réseau des contraintes accrues en matière de gestion des adresses IP et de prise en charge de la nature dynamique des conteneurs dans Kubernetes, désormais exposée au monde extérieur.
• Des clusters distincts pour chaque fonction réseau – La mise en réseau de Kubernetes ne fournit pas nativement de point central pour le trafic réseau entrant et sortant. Kubernetes permet un certain contrôle du trafic entrant, mais ignore presque totalement le trafic sortant, et il n’existe aucun moyen intégré d’associer les réseaux d’entrée et de sortie. Nous avons observé plusieurs déploiements dans lesquels chaque fonction réseau s’exécute dans son propre cluster, afin de permettre la mise en correspondance des adresses IP des serveurs avec celles des fonctions réseau. Cela entraîne une consommation supplémentaire de ressources et une hausse des dépenses d’investissement (CapEx), tout en ajoutant une complexité opérationnelle qui se traduit par une augmentation des dépenses d’exploitation (OpEx).

S’aligner sur les modèles Kubernetes

Une autre approche consiste à s’aligner sur les modèles de conception de Kubernetes et à introduire un proxy de services offrant une « vue unifiée » sur la mise en réseau des flux entrants et sortants ainsi que sur la sécurité entre le cluster Kubernetes et le monde extérieur. L’objectif d’un proxy de services est de combler les lacunes fonctionnelles de Kubernetes lorsqu’il est utilisé dans l’environnement d’un fournisseur de services. Un proxy de services doit :

• Utiliser des modèles natifs de Kubernetes pour étendre la mise en réseau de Kubernetes (définitions de ressources personnalisées, boucle de contrôle K8s)
• Interagir avec le réseau étendu (routage BGP, attribution d’adresses IP SNAT en sortie, traduction IPv4/IPv6)
• Relier les flux entrants et sortants individuellement pour chaque CNF
• Fournir une prise en charge étendue des couches L4/L7 (TCP, UDP, SCTP, NGAP, HTTP/2, Diameter, GTP, SIP)
• Fournir une couche de sécurité (terminaison TLS, pare-feu, protection contre les attaques DDoS, pare-feu applicatif web)
• Présenter des CNF cohérentes, tout en masquant les événements Kubernetes très dynamiques

L’approche de F5 — Présentation du proxy de service

F5 a choisi le deuxième scénario décrit ci-dessus pour étendre Kubernetes et créer ce proxy de services afin de fournir la fonctionnalité manquante. Forts de plusieurs décennies d’expertise dans la gestion du trafic et la sécurité, nous estimons qu’il s’agit d’une fonction essentielle pour accompagner la migration à grande échelle vers des environnements cloud natifs. Prêt pour la production et disponible dès maintenant, notre produit d’infrastructure cloud native BIG-IP Next Service Proxy for Kubernetes (SPK) répond directement aux lacunes de Kubernetes et permet aux fournisseurs de services de créer des ressources qui font défaut à Kubernetes dans sa version standard. SPK simplifie et sécurise l’architecture grâce à un framework qui automatise les opérations et s’intègre parfaitement aux politiques globales de réseau et de sécurité. Cette approche de Kubernetes destinée aux opérateurs télécoms continuera de réduire la complexité et les coûts d’exploitation, tout en renforçant la résilience et la sécurité de l’infrastructure. Alors que nous assistons aujourd’hui à un ralentissement de la transition vers la 5G SA (Les opérateurs télécoms échouent dans le déploiement de la 5G SA, selon GlobalData), il est raisonnable de penser que cette transition s’essoufflera davantage encore sans l’introduction d’un proxy de services adapté. Les opérateurs télécoms qui utilisent déjà cette solution en production dans le cadre d’une modernisation numérique à grande échelle constatent que SPK s’impose comme la solution Kubernetes au problème d’architecture des réseaux 5G dont ils ignoraient même l’existence.

Schéma de l’entrée Kubernetes pour les protocoles de télécommunications avec F5 BIG-IP Next Service Proxy for Kubernetes (SPK)

Le SPK de F5 est désormais disponible pour tous et actuellement utilisé en production par des opérateurs télécoms de grande envergure. Consultez les événements à venir au cours desquels nous présenterons les capacités de SPK par rapport à d’autres approches, ainsi que la procédure de certification des CNF sur notre plateforme. Pour plus d’informations, consultez cette page, et si vous souhaitez vous entretenir directement avec un membre de l’équipe F5, contactez-nous.

À propos de l’auteur

Phil Klatte

Autres articles de Phil Klatte