L’infrastructure Kubernetes n’était que la partie la plus élémentaire des plans de Deutsche Telekom pour un nouveau service de base 5G natif du cloud ; alors que les télécommunications se préparent pour le lancement, ses équipes informatiques estiment que GitOps est tout aussi important.
GitOps fait référence à un ensemble de pratiques organisationnelles et d’outils techniques qui stockent à la fois le code de l’application et l’infrastructure sous forme de fichiers de code dans le même Dépôts de contrôle de version Git. Dans cette approche de l’automatisation de l’infrastructure informatique, l’état des ressources de production est en constante synchronisation avec un état souhaité exprimé dans le code. GitOps a atteint l’usage courant des entreprises grâce à l’omniprésence des conteneurs et de Kubernetes, qui se prêtent naturellement à la gestion des applications et de l’infrastructure via du code, mais les deux ne sont pas identiques.
La technologie de réseau mobile 5G, qui offre des performances élevées et une faible latence, devrait faciliter une augmentation majeure de la quantité de données que les réseaux sans fil peuvent transmettre. Cela permettra de nouveaux types de Applications commerciales, en particulier dans des domaines tels que internet des objets et l’informatique de pointe.
« Exécuter une application basée sur Kubernetes ne signifie pas qu’elle est native du cloud », a déclaré Michal Sewera, chef d’équipe du projet de base 5G natif du cloud de Deutsche Telekom (DT), appelé 5G Standalone (SA). « Cloud-native, pour moi, signifie que vous êtes capable de survivre aux mises à jour continues [and] mises à niveau du système sans impact sur les clients, [and] être capable de détacher complètement votre état d’esprit du matériel sous-jacent. »
GitOps alimente la vitesse du réseau 5G
DT a commencé à planifier des services de télécommunications de base qui fonctionneraient sur sa plate-forme Kubernetes, qu’il appelle « Das Schiff » ou « The Ship », en 2019. Cela est dû en partie au fait que les fournisseurs de virtualisation de serveurs et la communauté open source Kubernetes avaient prise en charge améliorée de la virtualisation des fonctions réseau (NFV), un ensemble d’infrastructures logicielles qui permettent aux machines virtuelles de prendre en charge des périphériques réseau hautes performances, tels que des routeurs et des équilibreurs de charge, qui nécessitaient auparavant du matériel spécialisé. DT a également dû attendre que les fournisseurs de logiciels de télécommunications mettent à jour leurs applications pour prendre en charge les machines virtuelles et les conteneurs.
Fin 2019, DT avait déplacé les applications informatiques classiques sur Das Schiff, mais l’hébergement 5G SA il présentait un défi unique au-delà de la capacité de NFV à émuler les performances matérielles. Les applications logicielles de l’entreprise et les mises à jour de l’infrastructure définie par logiciel devaient également évoluer plus rapidement.
« Une seconde en 5G, c’est comme une éternité », a déclaré Sewera. « C’est une énorme différence par rapport à toute autre application informatique, non seulement du point de vue de [sensitivity to] pannes, mais surtout si vous pensez à l’intégration d’exécution où des milliers de nœuds sont connectés et vous devez répondre en quelques millisecondes. »
Lors de la construction de Das Schiff, l’équipe d’infrastructure de DT avait commencé à travailler avec l’open source Flux Outil CD GitOps pour gérer ses clusters Kubernetes, qui se comptent désormais par centaines, en vue d’une éventuelle flotte de milliers.
Lorsque l’équipe de Sewera a commencé à planifier le transfert de la 5G SA à Das Schiff en 2020, elle a trouvé que GitOps était un élément indispensable pour faire ce saut. Alors qu’une intervention manuelle très peu fréquente est requise de la part des équipes DevOps et de l’infrastructure informatique, un workflow GitOps signifie que Das Schiff se met en grande partie à jour tout au long du cycle de vie de chaque application, synchronisant automatiquement les ressources et la configuration de l’environnement de production avec les modifications exprimées dans le code et moins sujettes à les erreurs humaines qui accompagnent les tests et le déploiement manuels.
« Vous faites un très petit incrément de changement sur tout, et il y a un concept que j’appelle des tests d’acceptation non-stop, ce qui signifie qu’il n’y a plus de moment fixe où votre application est gelée [for testing] », a déclaré Sewera. » Il n’y aurait pas de [other] moyen de contrôler la qualité… et de réagir immédiatement à une demande client. »
La route de DT vers le noyau Kubernetes 5G
En 2019, l’équipe d’infrastructure de DT a commencé à envisager diverses plates-formes de gestion commerciales Kubernetes, ainsi qu’un environnement autogéré basé sur l’open source en amont. Après avoir décidé d’opter pour cette dernière option, l’équipe d’infrastructure a également commencé à expérimenter GitOps et a engagé Weaveworks, support commercial de Flux CD, pour obtenir de l’aide et des conseils sur la façon de mettre en œuvre l’outil à grande échelle.
« Ils ont été les premiers à adopter certaines technologies que nous utilisons actuellement, comme l’API de cluster, dans leur propre plate-forme Kubernetes pour les entreprises », a déclaré Vuk Gojnic, chef d’équipe pour le moteur Kubernetes de DT. « Nous avions d’autres candidats pour ce genre de rôle qui étaient très [HashiCorp] Terraformation. Pour notre petite équipe à l’époque, cela ne ressemblait pas à quelque chose d’évolutif. »
À l’aide de Flux, DT gère désormais quelque 200 clusters Kubernetes avec seulement 10 ingénieurs à temps plein et prévoit d’évoluer vers des milliers de clusters sans ajouter plus d’un ou deux membres supplémentaires à l’équipe d’infrastructure.
Le fonds d’investissement de DT, Telekom Investment Pool, a ensuite investi dans Weaveworks, avec d’autres investisseurs, dont Ericsson Ventures et Orange Ventures, dans un tour de table de 36 millions de dollars de série C en 2020.
Le travail de DT avec Weaveworks l’a aidé à surmonter la transition entre la version 1 de Flux et la version 2 de Flux, publiée pour la première fois en 2020, qui a ajouté la prise en charge recherchée de la multi-location, mais a représenté une refactorisation de base pour l’utilitaire.
« Nous avons eu beaucoup d’interactions avec le [Weaveworks] l’équipe d’ingénierie et leur a donné beaucoup de commentaires qui ont été intégrés au produit en amont – un certain nombre de choses qui sont spécifiques à la façon dont [we] gérer les profils de déploiement d’applications », a déclaré Gojnic.
Weaveworks a intégré Flux version 2 dans son produit Weave GitOps Enterprise, lancé en juin et mis à jour dans la version 2021.11 cette semaine, qui a ajouté une interface utilisateur de livraison d’applications, des profils de composants d’infrastructure réutilisables, la prise en charge des plates-formes reproductibles en tant que code et une interface de gestion multi-cluster.
DT a été l’un des premiers utilisateurs de Flux version 2, mais a signé des contrats avec le support technique de Weaveworks pour Flux avant la sortie de Weave GitOps Enterprise, a déclaré Gojnic, et pourrait envisager la plate-forme commerciale à l’avenir.
« Nous utilisons une pile personnalisée pour laquelle nous avons un support », a déclaré Gojnic. « Ce n’est pas un produit standard, mais nous espérons également faire de ce cas d’utilisation [work]. »
Beth Pariseau, rédactrice principale chez TechTarget, est une vétéran primée du journalisme informatique. Elle est joignable au [email protected] ou sur Twitter @PariseauTT.
