Kubernetes mange le réseau

par | Déc 5, 2022 | Blog

Kubernetes mange l'infrastructure

Kubernetes est l'une des transitions de plateforme les plus critiques de l'histoire de l'informatique. Kubernetes est la façon dont nous déployons, planifions et exploitons les applications distribuées natives du cloud. La plateforme devient rapidement le moyen de facto par lequel les applications modernes traitent l'infrastructure du cloud, notamment les ressources de calcul, de stockage, de mise en réseau, de GPU et de DPU. Dans le cloud public, à la périphérie ou dans des environnements privés (centres de données privés ou centres de colocation), Kubernetes est partout. À la différence des VM, Kubernetes abstrait et quantifie les ressources d'infrastructure d'une manière conviviale et intuitive, conçue pour les personnes déployant des applications "cloud-natives". Il considère l'infrastructure d'un point de vue pratique centré sur les composants de l'application. En abstrayant l'infrastructure de cette manière, Kubernetes permet la portabilité des applications sur plusieurs nuages et environnements, privés ou publics. (Bien sûr, tant qu'il n'y a pas de dépendances directes "dures" sur les services de plate-forme fournis par les nuages respectifs).

Le paysage du Cloud Native

À mesure que la popularité de Kubernetes s'accroît, un écosystème déjà considérable d'outils opérationnels se développe rapidement. Comme Kubernetes, ces outils sont natifs du nuage et peuvent être adaptés à n'importe quel environnement, dans n'importe quel nuage, privé ou public, en exploitant la même abstraction d'infrastructure. L'observabilité, le déploiement et le débogage sur plusieurs nuages sont effectués de manière standard et non personnalisée à l'aide de chaînes d'outils ouvertes de facto. Des centaines de milliers de développeurs, de SRE et d'équipes DevOps adoptent ces outils pour un usage quotidien sans craindre d'être enfermés dans une impasse propriétaire. Ces outils sont partagés entre les organisations, les entreprises et les nuages, ce qui fait de la connaissance de ces outils un ensemble de compétences portables applicables partout. 

La mise en réseau doit devenir plus dématérialisée

Presque partout - rien de tout cela ne s'applique aux réseaux modernes. Même si les outils d'exploitation standard natifs du cloud sont courants pour gérer et surveiller les réseaux dans le cloud, on ne peut pas en dire autant des réseaux physiques hors cloud public. Les réseaux physiques dans les environnements privés en sont encore à l'ère pré-cloud. Nous nous appuyons toujours sur des outils spécifiques aux fournisseurs qui servent principalement les intérêts de ces derniers, mais pas ceux du praticien. Les outils de gestion se transforment rapidement en un jeu de plateforme pour les principaux fournisseurs d'infrastructure réseau. Ils utilisent ces outils, souvent hébergés dans le nuage, en tant que service, comme moyen de fidéliser les clients à leur offre plus large. L'une des principales inspirations de ce modèle est la plateforme Meraki de Cisco, qui a connu un grand succès. Meraki a consumérisé les réseaux d'entreprise/de campus autour de sa plate-forme de gestion hébergée dans le nuage, simplifiant ainsi considérablement les opérations réseau. Mais au prix d'une réduction du choix de systèmes matériels et de fournisseurs que la plate-forme prend en charge. Une transition similaire de la gamme de produits se produit avec les plateformes de centres de données - NEXUS Cloud de Cisco, Cloud Vision d'Arista et, dans une moindre mesure, Apstra de Juniper. Les outils de gestion de réseau sont désormais un mécanisme de verrouillage opérationnel de la concurrence. 

Historiquement, le facteur de forme de la livraison d'un appareil matériel définissait tout - c'est juste une "boîte". La façon dont nous gérons les réseaux est exactement la même - comme un tas de boîtes - une boîte à la fois. La mise en réseau est l'application distribuée originale. L'émergence des fonctions de réseau logiciel rend la nature d'application distribuée de la mise en réseau encore plus pressante. Les nouveaux services ou applications de mise en réseau peuvent être exécutés n'importe où - sur des commutateurs, des smartNIC, des serveurs ordinaires ou des nœuds de service spéciaux (des serveurs ordinaires, mais dédiés à la mise en réseau). 

La mise en réseau se transforme en nuage.

Cette "approche en boîte" ne fonctionne pas pour les logiciels - il existe une meilleure méthode. Sur le plan opérationnel, nous devons rapprocher les réseaux des plates-formes de calcul et d'applications. Nous devons offrir la même expérience que celle dont bénéficient aujourd'hui de nombreuses personnes dans le cloud, où NetOps fait simplement partie du processus DevOps normal. Comme de nombreux jeunes spécialistes de l'infrastructure grandissent dans le nuage, nous devons faire en sorte que les réseaux physiques se sentent, agissent et fonctionnent de la même manière que ces nouveaux spécialistes de l'infrastructure. 

La mise en réseau doit devenir plus Kubernetes

Contrairement à ce que pensent les grands fournisseurs de matériel de réseau, les outils de gestion de réseau ne sont pas la plate-forme. Le réseau physique n'est qu'une petite partie, mais essentielle, de l'infrastructure. Il est responsable de la connexion des applications entre elles, à l'Internet et à d'autres nuages et environnements. Dans tout environnement, le réseau physique fait partie intégrante de l'application. Mais c'est la seule partie gérée de manière spécialisée et sur mesure, souvent incompatible avec les opérations du reste de l'infrastructure et de la pile d'applications. Et cette partie de la pile sera entièrement dominée par Kubernetes, tout comme dans le cloud public. Kubernetes est une plateforme de consommation d'infrastructure de facto qui émerge rapidement et constitue un excellent moyen de gérer les applications distribuées modernes - exactement ce dont les réseaux ont besoin. Il s'intègre bien dans un large éventail d'outils opérationnels de facto et fonctionne bien avec les approches opérationnelles modernes telles que GitOps, l'infrastructure en tant que code/données, le déploiement continu, etc. En utilisant Kubernetes, le réseau physique devient simplement un autre composant de la pile d'infrastructure ouverte standard.

Comment y arriver ?

Un système d'exploitation en réseau

Tout d'abord, nous avons besoin d'un système d'exploitation réseau ouvert (NOS) pour fournir un réseau sous la forme d'une application distribuée moderne. Le NOS devrait être modularisé et conteneurisé. Nous devrions être en mesure de traiter chacun de ses composants ou services comme de simples applications. Avec un peu (enfin, peut-être beaucoup) de nettoyage, SONiC peut offrir ces propriétés. SONiC a déjà une grande communauté d'adeptes et bénéficie du soutien de la plupart des vendeurs de boîtes blanches et de systèmes de marque. Il y a cependant un peu de travail à faire. Un grand nombre de scripts d'initialisation et d'entretien doivent être découplés, démêlés et modularisés. L'objectif est de faire en sorte que chaque service soit géré indépendamment et puisse être mis à jour sans nécessiter de redémarrage général affectant les autres services. Il peut être nécessaire de faire migrer un runtime de conteneur de Docker à containerd pour assurer une interopérabilité plus fluide avec Kubernetes et d'autres outils modernes de cloud-native. 

Plan de contrôle Kubernetes

Kubernetes est un excellent outil pour déployer des logiciels et distribuer des configurations. Il est très modulaire et extensible (via les CRD, les contrôleurs et les opérateurs), ce qui en fait une base idéale pour les contrôleurs d'infrastructure. Transformer un réseau de commutateurs, de smartNICs et de nœuds de service en un cluster Kubernetes nous permet de traiter le réseau comme un ensemble d'applications distribuées. Il peut s'agir de protocoles de routage, de fonctions utilitaires, de sondes d'observabilité, de proxies, de passerelles API, d'applicateurs de politiques, d'agents de collecte de journaux ou de robots de débogage. Le matériel d'aujourd'hui est incroyable ; ce qu'il nous faut maintenant, c'est un meilleur logiciel : commercial, open-source, ou des expériences développées sur mesure.

Ops et Observabilité Cloud-Native

Sur le plan opérationnel, Kubernetes simplifiera l'intégration avec les outils natifs du nuage couramment utilisés. Cela permettra l'utilisation native d'outils d'observabilité/télémétrie comme ELK-stack, Prometheus, Jaeger et Grafana. Les outils d'automatisation tels que Terraform et ArgoCD permettront de mettre en œuvre les pratiques DevOps standard telles que GitOps et Infrastructure As Code. L'intégration à ces outils apportera les mêmes approches opérationnelles dont bénéficient les équipes DevOps et SRE dans le cloud public.

Abstraction des tissus

Nous devons ouvrir l'infrastructure réseau aux personnes qui ont grandi dans le nuage. Tous ceux qui s'occupent de réseaux en nuage connaissent intimement le concept de VPC. Le VPC est une unité de base de consommation et d'isolation du réseau dans AWS. Il vous permet de disposer de votre propre "tranche" du réseau du cloud, où vous pouvez exécuter vos applications. Le concept est très abstrait et ne divulgue pas l'implémentation sous-jacente du réseau. Pour l'utilisateur, la façon dont le réseau est mis en œuvre sous le capot n'a pas d'importance. L'utilisateur n'a aucun contrôle direct sur les concepts et protocoles de mise en réseau sous-jacents. La seule façon dont l'utilisateur peut interagir avec le réseau est l'abstraction.

Une méthode similaire doit être employée pour le réseau physique hors-cloud. L'abstraction ne doit laisser filtrer aucun détail d'instrumentation ou de protocole pour l'utilisateur et doit pouvoir s'adapter à plusieurs technologies de réseau via des politiques d'instrumentation correspondantes. Par exemple, en fonction de l'org, de l'utilisateur ou des propriétés de l'objet VPC, l'isolation peut être mise en œuvre sous la forme de VLAN ou de BGP eVPNs. Les politiques d'instrumentation sont détenues et contrôlées par l'équipe d'architecture réseau et ne sont pas modifiables par l'utilisateur qui alloue un VPC.

L'avenir sera beaucoup plus futuriste que prévu.

Mettons le nouveau réseau physique ouvert à la portée du plus grand nombre, simplifions l'infrastructure physique en l'orientant vers les nuages et éliminons enfin le réseau physique. Nous travaillons dur pour cela, allez-vous rejoindre notre révolution ?