Améliorez l'architecture du réseau Telco 5G avec le proxy de service pour Kubernetes

Début 2018, je me suis retrouvé à avoir des conversations similaires avec mes amis et collègues qui étaient des experts en réseau et en normes 5G émergentes. Nous ressentions tous un vague malaise à l’idée que nous nous précipitions vers une transition comportant BEAUCOUP d’inconnues. Nous comprenions tous que la 5G allait accélérer la transition vers les conteneurs et l’architecture cloud native, mais nous savions également que Kubernetes et d’autres outils cloud natifs avaient été créés à l’origine avec un ensemble de cas d’utilisation totalement différent à l’esprit. Ce que nous avons tous vu (et probablement que beaucoup de lecteurs de cet article ont également observé), c’est que notre industrie se dirigeait vers une trajectoire de crise d’estomac.

Depuis ces jours d’appréhension, les fournisseurs de services de communication (CSP) ont commencé le véritable travail de migration vers une infrastructure cloud native. Les premiers pionniers de ces déploiements découvrent en effet des obstacles inattendus où les zones critiques du réseau Kubernetes telles que conçues à l’origine ne peuvent pas répondre aux exigences des cas d’utilisation des fournisseurs de services. Que l’objectif de l’opérateur télécoms soit de se diriger vers un déploiement 5G Stand Alone (SA) Core ou de faire partie d’une initiative de modernisation avec une architecture cloud distribuée, l’adaptation de Kubernetes pour prendre en charge l’interopérabilité du réseau, l’évolutivité de niveau opérateur et les politiques de sécurité des opérateurs sont des capacités essentielles nécessaires dans toute l’infrastructure cloud native.

Étant donné que Kubernetes a depuis évolué principalement pour se concentrer sur les cas d’utilisation Web et informatiques exécutés dans le cloud public ou dans des environnements d’entreprise, il est compréhensible que l’ensemble unique d’exigences et de protocoles pour déployer des cas d’utilisation de fournisseurs de services n’ait jamais été prévu. Heureusement, les architectes de Kubernetes ont mis en place un ensemble solide de modèles de conception qui rendent Kubernetes extensible, créant ainsi une voie pour les cas d'utilisation fondamentaux des télécommunications : pour la gestion du trafic réseau, la visibilité et le contrôle, et la prise en charge étendue des protocoles tels que les protocoles HTTP/2, GTP, SIP et Diameter.

Avant de décrire les améliorations nécessaires pour adapter Kubernetes aux cas d’utilisation actuels des fournisseurs de services, identifions d’abord les exigences uniques qu’apporte un réseau de fournisseurs 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, en termes d’augmentation des coûts opérationnels et de complexité. Les architectes réseau doivent prendre en compte plusieurs cas d'utilisation des télécommunications, la prise en charge des protocoles hérités et la manière dont les changements dynamiques au sein de Kubernetes peuvent avoir un impact sur la topologie du réseau existant, ce qui peut entraîner une complexité accrue.

Deuxièmement, les charges de travail des télécommunications (fonctions réseau) sont différentes des charges de travail informatiques. Les réseaux des fournisseurs de services et leurs fonctions réseau utilisent bien plus que les standards HTTP/HTTPS ou TCP. Il sera essentiel pour les fournisseurs de téléphonie mobile de prendre en charge les réseaux à la fois pour les protocoles 3G/4G existants tels que SIP, GTP, SCTP, etc. et 5G HTTP2. Les charges de travail des télécommunications disposent également d’une couche supplémentaire de normes qui se trouvent au-dessus des couches réseau traditionnelles par rapport aux charges de travail informatiques.

Enfin, et certainement pas des moindres, 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 de nouvelles technologies. Les équipes SecOps des fournisseurs de services recherchent toujours des moyens de réduire la surface d’attaque et d’assurer un contrôle de sécurité cohérent. De plus, les politiques de sécurité plus larges du réseau doivent être mises à jour et adaptables au fil du temps.

Deux approches actuelles pour combler ces lacunes fonctionnelles

Contourner les modèles Kubernetes

Le contournement des modèles natifs du cloud est un indicateur que les architectes sont nécessairement amenés à créer des hacks, car Kubernetes n’est pas fourni nativement avec les outils permettant de gérer les charges de travail des opérateurs de télécommunications. Nous avons observé plusieurs façons troublantes dont les opérateurs de télécommunications brisent les modèles :

• Contournement du réseau 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 présenté sous la forme d'une demande de « multus », pour permettre une interface supplémentaire, directe vers l'extérieur). Sans un point central de contrôle du réseau, cela expose la complexité interne de Kubernetes au réseau du fournisseur de services externe, ce qui entraînera une complexité et des coûts opérationnels accrus, ainsi qu'une surface d'attaque de sécurité accrue. Cela impose également une demande accrue à tout développeur d'application/fonction réseau et à tout opérateur réseau pour gérer les adresses IP, ainsi que pour gérer la nature dynamique des conteneurs dans Kubernetes, qui est désormais exposée au monde extérieur.
• Clusters distincts pour chaque fonction réseau – La mise en réseau Kubernetes ne fournit pas nativement de point central pour l’entrée/sortie du trafic réseau. Kubernetes fournit un certain contrôle d'entrée, mais ignore presque totalement le trafic de sortie, et il n'existe aucun moyen intégré de lier les réseaux d'entrée et de sortie. Nous avons vu plusieurs déploiements où chaque fonction réseau s’exécute dans son propre cluster, pour permettre la corrélation entre les adresses IP des serveurs et les adresses IP des fonctions réseau. Cela entraîne des frais généraux de ressources supplémentaires et une augmentation des dépenses d'investissement, tandis que cela ajoute également une complexité opérationnelle, ce qui se traduit par une augmentation des dépenses d'exploitation.

Alignement avec les modèles Kubernetes

Une approche alternative consiste à s’aligner sur les modèles de conception de Kubernetes et à introduire un proxy de service qui fournira un « panneau de verre unique » pour la mise en réseau et la sécurité d’entrée/sortie du cluster Kubernetes vers le monde extérieur. L'objectif d'un proxy de service est de combler les lacunes fonctionnelles que Kubernetes présente lorsqu'il est utilisé dans un environnement de fournisseur de services. Un proxy de service doit :

• Utiliser les modèles natifs de Kubernetes pour étendre la mise en réseau Kubernetes (définitions de ressources personnalisées, boucle de contrôle K8s)
• Interface avec un réseau plus large (routage BGP, attributions d'IP SNAT de sortie, traduction IPv4/v6)
• Lier l'entrée et la sortie individuellement pour chaque CNF
• Fournit un support L4/L7 étendu (tcp, udp, sctp, NGAP, HTTP/2, Diameter, GTP, SIP)
• Fournir une couche de sécurité (terminaison TLS, pare-feu, DDoS, pare-feu application Web)
• Présentez un CNF cohérent , masquant les événements Kubernetes hautement 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 service pour fournir cette fonctionnalité manquante. Forts de nos décennies d'expertise en matière de gestion du trafic et de sécurité, nous pensons qu'il s'agit d'une fonction essentielle nécessaire pour prendre en charge la migration cloud native à grande échelle. Prêt pour la production et disponible dès maintenant, nous avons développé le produit d'infrastructure cloud natif BIG-IP Next Service Proxy for Kubernetes (SPK), pour remédier directement aux lacunes de Kubernetes et permettre aux fournisseurs de services de créer des ressources qui manquent à Kubernetes « vanilla ». SPK simplifie et sécurise l'architecture, avec un cadre qui automatise et s'intègre parfaitement aux politiques de réseau et de sécurité plus larges. Cette approche de Kubernetes pour les opérateurs de télécommunications continuera à conduire à une réduction de la complexité et des coûts opérationnels, ainsi qu’à une infrastructure plus résiliente et plus sécurisée. Alors que nous assistons aujourd'hui à un ralentissement de la transition vers la 5G SA ( Telecom Operators Failing 5G SA, GlobalData Finds ), il est prudent de supposer que la transition va encore faiblir sans l'introduction d'un proxy de service approprié. Les clients des opérateurs de télécommunications en production, au milieu d'une modernisation numérique à grande échelle, constatent que SPK s'avère être la solution Kubernetes au problème d'architecture du réseau 5G dont ils ne savaient même pas qu'ils l'avaient.

Le SPK de F5 est désormais GA et est actuellement en production auprès d'opérateurs de télécommunications à grande échelle. Recherchez les événements à venir où nous démontrerons les capacités de SPK par rapport à d’autres approches et comment certifier les CNF sur notre plateforme. Pour plus d'informations, visitez cette page , et si vous souhaitez parler directement à un membre de l'équipe F5, contactez-nous .