Ici, sur le blog de la Linux Foundation, nous partageons le contenu de nos projets, comme cet article de Joel Hans du Blog de la Fondation Cloud Native Computing.

L’industrie des télécommunications est l’épine dorsale des économies de plus en plus numériques d’aujourd’hui, mais elle est confrontée à un nouveau défi difficile en évoluant pour répondre aux pratiques d’infrastructure modernes. Comment les télécommunications se sont-elles retrouvées dans cette situation ? Parce que le les risques d’incidents ou d’indisponibilité sont si importants, l’industrie s’est concentrée presque exclusivement sur des conceptions de systèmes qui minimisent les risques et maximisent la fiabilité. C’est fantastique pour les services critiques, qu’il s’agisse du contrôle public du trafic aérien ou des services bancaires privés à grande vitesse, mais cela met l’accent sur la stabilité plutôt que sur la productivité et l’adoption de nouvelles technologies qui pourraient rendre leurs opérations plus résilientes et plus performantes.

Les télécommunications rattrapent la technologie cloud native, et les effets en aval commencent à se faire sentir. Ces organisations sont désormais en retard sur les choix de facto pour l’entreprise et l’informatique, ce qui signifie qu’elles sont moins susceptibles de recruter les talents d’ingénierie de haut niveau dont elles ont besoin. Dans des environnements de plus en plus concurrentiels, ils doivent accroître leur productivité et déployer plus rapidement de nouvelles plates-formes de téléphonie sur le marché, sans s’enliser dans d’anciennes solutions personnalisées conçues en interne.

Pour passer d’un outil de confiance interne à un outil de confiance de l’industrie, les entreprises de télécommunications doivent avoir la certitude qu’elles sont sur la bonne voie pour faire évoluer correctement leur infrastructure de fonction de réseau virtuel (VNF) afin d’activer les fonctions cloud natives à l’aide de Kubernetes. C’est là que la CNCF a pour objectif d’aider.

Entrez dans la suite de tests CNF pour les télécommunications

Une fonction réseau cloud native (CNF) est une application qui implémente ou facilite la fonctionnalité réseau de manière cloud native, développée à l’aide de principes standardisés et composée d’au moins un microservice.

Et la suite de tests CNF (cncf/cnf-testsuite) est une suite de tests open source permettant aux opérateurs de télécommunications de savoir exactement dans quelle mesure leurs CNF sont natifs du cloud. Il est conçu pour les développeurs de télécommunications et les opérateurs de réseau, construits avec Kubernetes et d’autres technologies natives du cloud, pour valider dans quelle mesure ils suivent les principes et les meilleures pratiques natives du cloud, comme l’infrastructure immuable, les API déclaratives et un « processus de déploiement reproductible ».

La CNCF regroupe les Groupe d’utilisateurs de télécommunications (TUG) et le Groupe de travail sur la fonction de réseau cloud natif (CNF WG) pour mettre en œuvre la suite de tests CNF, qui aide les développeurs de télécommunications et les équipes opérationnelles à créer des boucles de rétroaction plus rapides grâce aux tests flexibles de la suite et au temps d’exécution optimisé. Parce qu’il peut être intégré dans n’importe quel pipeline CI/CD, que ce soit dans le cadre de vérifications de développement ou de pré-production, ou exécuté en tant que test autonome pour un seul CNF, les équipes de développement des télécommunications obtiennent d’un coup d’œil une compréhension de la façon dont leurs nouveaux déploiements s’alignent sur le écosystème cloud natif, y compris les projets, technologies et concepts hébergés par la CNCF.

C’est une réponse puissante à une question difficile : À quel point sommes-nous natifs du cloud ?

La suite de tests CNF exploite 10 projets hébergés par la CNCF et plusieurs outils open source. Une version modifiée de CoreDNS est utilisé comme exemple CNF pour que les utilisateurs finaux se familiarisent avec la suite de tests dans cinq étapeset Prométhée est utilisé dans un test d’observabilité pour vérifier la meilleure pratique des CNF pour exposer activement les métriques. Et il regroupe d’autres outils en amont, comme Gardien de l’OPA, Linter de barreet Outil promotionnel pour rendre l’installation, la configuration et la gestion des versions reproductibles. L’équipe CNF Test Suite est également reconnaissante des contributions de Kyverno sur les tests de sécurité, LitmusChaos pour les tests de résilience, et Kubescope pour les politiques de sécurité.

Le installation minimale pour la suite de tests CNF ne nécessite qu’un cluster Kubernetes en cours d’exécution, kubectl, curl et helm, et prend même en charge l’exécution de tests CNF sur des machines isolées ou celles qui pourraient avoir besoin d’auto-héberger les référentiels d’images. Une fois installé, vous pouvez utiliser un exemple de CNF ou apporter le vôtre. Il vous suffit de fournir le fichier .yml et d’exécuter `cnf-testsuite all` pour exécuter tous les tests disponibles. Il y a même un rapide processus en cinq étapes pour déployer la suite et obtenir des recommandations en moins de 15 minutes.

Ce que couvre la suite de tests CNF et pourquoi

Début 2022, la suite de tests CNF peut exécuter environ 60 tests de charge de travail, qui sont segmentés en 7 catégories différentes.

Compatibilité, installabilité et évolutivité: Les CNF doivent fonctionner avec tout produit Kubernetes certifié et tout réseau compatible CNI qui répondent à leurs exigences de fonctionnalité tout en utilisant des outils de déploiement intrabande standard tels que les cartes Helm (version 3). La suite de tests CNF vérifie si le CNF peut être mis à l’échelle horizontalement et verticalement à l’aide de `kubectl` pour s’assurer qu’il peut tirer parti de la fonctionnalité intégrée de Kubernetes.

Microservice: Le CNF doit être développé et livré en tant que microservice pour améliorer l’agilité ou le temps de développement requis entre les déploiements. Les organisations agiles peuvent déployer de nouvelles fonctionnalités plus fréquemment ou permettre à plusieurs équipes de déployer en toute sécurité des correctifs en fonction de leur domaine fonctionnel, comme la correction des vulnérabilités de sécurité, sans avoir à se synchroniser avec d’autres équipes au préalable.

État: Une infrastructure cloud native doit être immuable, indépendante de l’environnement et résistante aux défaillances de nœuds, ce qui signifie gérer correctement la configuration, les données persistantes et l’état. La configuration d’un CNF doit être sans état, stockée dans une définition de ressource personnalisée ou dans une base de données distincte sur le stockage local, avec toutes les données persistantes gérées par StatefulSets. Les informations séparées avec état et sans état créent une infrastructure facilement reproductible, cohérente, jetable et toujours déployée de manière reproductible.

Fiabilité, résilience et disponibilité: La fiabilité de l’infrastructure de télécommunications est la même que celle de l’informatique standard – elle doit être hautement sécurisée et fiable et prennent en charge des latences ultra-faibles. Les meilleures pratiques cloud natives tentent de réduire le temps moyen entre les pannes (MTBF) en s’appuyant sur des sous-composants redondants avec une facilité de maintenance plus élevée (temps moyen de récupération (MTTR)), puis en testant ces hypothèses via l’ingénierie du chaos et des configurations d’auto-réparation. La suite de tests utilise un type de test de chaos pour s’assurer que les CNF résistent aux défaillances inévitables des environnements de cloud public ou aux problèmes au niveau de l’orchestrateur, tels que ce qui se produit lorsque des pods sont supprimés de manière inattendue ou à court de ressources informatiques. Ces tests garantissent que les CNF répondent aux normes de fiabilité de l’industrie des télécommunications sur les plates-formes matérielles/logicielles cloud partagées non de niveau opérateur.

Observabilité & Diagnostics: Chaque élément de l’infrastructure native du cloud de production doit rendre ses états internes observables via des métriques, un traçage et une journalisation. La suite de tests CNF recherche la compatibilité avec Courant, Jaeger, Outil promotionnel, Prométhéeet OpenMetricsqui aident les équipes DevOps ou SRE à maintenir, déboguer et recueillir des informations sur la santé de leurs environnements de production, qui doivent être versionnés, maintenus dans le contrôle des sources et modifiés uniquement via des pipelines de déploiement.

Sécurité: La sécurité native du cloud nécessite l’attention d’experts au niveau du système d’exploitation, de l’exécution du conteneur, de l’orchestration, de l’application et de la plate-forme cloud. Bien que bon nombre d’entre eux ne relèvent pas du champ d’application de la suite de tests CNF, elle valide toujours si les conteneurs sont isolés les uns des autres et de l’hôte, n’autorisent pas l’escalade des privilèges, ont des limites de ressources définies et sont vérifiés par rapport aux CVE courants.

Configuration: Les équipes doivent gérer la configuration d’un CNF dans un déclaratif manière, à l’aide de ConfigMaps, d’opérateurs ou d’autres interfaces déclaratives, pour concevoir le résultat souhaité, et non comment obtenir ledit résultat. La configuration déclarative n’a pas besoin d’être exécutée pour être comprise, ce qui la rend beaucoup moins sujette aux erreurs que la configuration impérative ou même les séquences de commandes `kubectl` les mieux entretenues.

Après avoir déployé de nombreux tests dans chaque catégorie, la suite de tests CNF génère une notation flexible et des suggestions de correction pour chaque catégorie (ou une catégorie si vous l’avez choisie dans la CLI), vous donnant les prochaines étapes pratiques pour améliorer votre CNF afin de mieux suivre le cloud natif. les pratiques. Il s’agit d’une solution puissante et toujours en croissance pour l’industrie des télécommunications pour adopter le cloud natif d’une manière contrôlable, observable et validée par toute l’expertise sous l’égide de la CNCF.

Quelle est la prochaine étape pour la suite de tests CNF ?

L’initiative Test Suite continuera de travailler en étroite collaboration avec le Groupe d’utilisateurs de télécommunications (TUG) et le Groupe de travail sur la fonction de réseau cloud natif (CNF WG), recueillant des retours basés sur des cas d’utilisation réels et faisant évoluer le projet. Alors que le groupe de travail CNF publie davantage de pratiques recommandées pour les opérateurs de télécommunications natifs du cloud, l’équipe de la suite de tests CNF ajoutera d’autres tests pour valider chacun.

En réalité, v0.26.0, publié le 25 février 2022, comprend six nouveaux tests de charge de travail, des corrections de bogues et une documentation améliorée autour des tests de plate-forme. Si vous souhaitez vous impliquer et façonner l’avenir de la suite de tests CNF, il existe déjà plusieurs façons de fournir des commentaires ou de contribuer au code, à la documentation ou à des exemples de CNF :

Visitez la suite de tests CNF sur GitHub
Continuer la conversation sur Mou (#cnf-testsuite-dev)
Assister Contributeur de la suite de tests CNF appelle le jeudi à 15:15 UTC
Rejoins Groupe de travail CNF réunions le lundi à 16:00 UTC

Regard vers l’avenir : le programme de certification CNF

La suite de tests CNF n’est que la première étape passionnante de la prochaine Programme de certification Cloud Native Network Function (CNF). Nous sommes impatients de faire de CNF Test Suite l’outil de facto des fournisseurs d’équipements réseau et des équipes de développement CNF pour prouver, puis certifier, qu’ils adoptent les meilleures pratiques natives du cloud dans les nouveaux produits et services.

Les avantages pour l’industrie des télécommunications sont clairs :

Les fournisseurs obtiennent une vérification que leurs applications et architectures cloud natives adhèrent aux meilleures pratiques cloud natives.
Leur les clients obtiennent une vérification que les services ou réseaux cloud natifs qu’ils achètent sont réellement cloud natif.

Et ils bénéficient tous les deux d’une fiabilité encore meilleure, d’un risque réduit et de coûts d’investissement/d’exploitation réduits.

Nous prévoyons de prendre en charge tout produit qui s’exécute dans un environnement Kubernetes certifié pour nous assurer que les organisations créent des CNF compatibles avec tous les principaux fournisseurs de cloud public ou environnements sur site. Nous n’avons pas encore publié les exigences de certification, mais elles seront similaires aux Conformité k8s processus, où vous pouvez soumettre des résultats via une demande d’extraction et recevoir des mises à jour sur votre processus de certification par e-mail.

Au fur et à mesure du développement du programme de certification CNF, le TUG et le CNF-WG s’engageront auprès des organisations qui utilisent fortement la suite de tests pour apporter des améliorations et se tenir au courant des dernières meilleures pratiques natives du cloud. Nous sommes ravis de voir comment l’industrie des télécommunications évolue en adoptant davantage de principes natifs du cloud, tels que les systèmes à couplage lâche et l’immuabilité, et en recueillant des preuves de leur travail acharné via la suite de tests CNF. C’est ainsi que nous veillons à ce qu’une industrie complexe et essentielle franchisse les prochaines étapes vers la meilleure infrastructure technologique à offrir, sans sacrifier un centimètre sur la fiabilité.

Pour franchir les prochaines étapes avec la suite de tests CNF et préparer votre organisation au prochain programme de certification CNF, programme une démo personnalisée de CNF Test Suite ou assister à la Journée Cloud Native Telcoun événement co-localisé à KubeCon + CloudNativeCon Europe 2022 le 16 mai 2022.