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 la manière de facto dont les applications modernes gèrent l'infrastructure cloud, y compris les ressources de calcul, de stockage, de 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. Contrairement aux VM, Kubernetes abstrait et quantifie les ressources d'infrastructure d'une manière conviviale et intuitive, conçue pour les personnes qui déploient des applications cloud-natives. Il considère l'infrastructure d'un point de vue pratique centré sur les composants de l'application. En faisant abstraction de l'infrastructure de cette manière, Kubernetes permet la portabilité des applications dans de multiples 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 plateforme fournis par les nuages respectifs).
À mesure que la popularité de Kubernetes grandit, un écosystème déjà considérable d'outils opérationnels se développe rapidement. Comme Kubernetes, ces outils sont "cloud-native" et peuvent être adaptés à n'importe quel environnement, dans n'importe quel "cloud", privé ou public, en tirant parti de la même abstraction d'infrastructure. L'observabilité, le déploiement et le débogage dans plusieurs nuages s'effectuent 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 natifs du nuage sont courants pour la gestion et la surveillance des réseaux dans le nuage, on ne peut pas en dire autant des réseaux physiques hors du nuage public. Le réseau physique dans les environnements privés reste dans l'ère pré-cloud. Nous nous appuyons toujours sur des outils sur mesure spécifiques aux fournisseurs qui servent principalement les intérêts des fournisseurs, mais pas ceux des praticiens. Les outils de gestion deviennent rapidement un jeu de plateforme pour les principaux fournisseurs d'infrastructure de réseau. Ils utilisent ces outils, souvent proposés dans le nuage, en tant que service, comme moyen de fidéliser les clients à leur offre plus large. L'une des principales sources d'inspiration de ce modèle est la plateforme Meraki de Cisco, qui a connu un grand succès. Meraki a consumérisé le réseau des entreprises/campus autour de sa plateforme de gestion hébergée dans le nuage, simplifiant ainsi grandement les opérations du réseau. Mais au prix d'une réduction du choix des systèmes matériels et des fournisseurs pris en charge par la plateforme. Une transition similaire des lignes de produits est en cours pour 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 d'un appareil matériel a tout défini : il s'agit simplement d'une "boîte". La façon dont nous gérons les réseaux est exactement la même - un ensemble de boîtes - une boîte à la fois. La mise en réseau a été l'application distribuée originale. L'émergence des fonctions de réseau logicielles rend la nature d'application distribuée de la mise en réseau encore plus pressante. Les nouvelles applications ou les nouveaux services de mise en réseau peuvent s'exécuter n'importe où - sur des commutateurs, des smartNIC, des serveurs ordinaires ou des nœuds de service spéciaux (enfin, 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 y a une meilleure façon de procéder. Sur le plan opérationnel, nous devons rapprocher la mise en réseau des plates-formes informatiques et applicatives. Nous devons offrir la même expérience que celle dont jouissent aujourd'hui tant de personnes dans le nuage, où NetOps fait simplement partie du processus DevOps normal. Alors que de nombreux jeunes spécialistes de l'infrastructure grandissent dans le nuage, nous devons faire en sorte que les réseaux physiques soient perçus, agissent et fonctionnent de la manière que ces nouveaux spécialistes de l'infrastructure trouvent familière.
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'image 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 d'une manière spécialisée et sur mesure qui est 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 un excellent moyen de gérer les applications distribuées modernes - exactement ce dont la mise en réseau a 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, la mise en réseau physique devient juste 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 des CRD, des contrôleurs et des opérateurs), ce qui en fait une base idéale pour les contrôleurs d'infrastructure. Transformer un réseau de commutateurs, de smartNIC et de nœuds de service en 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 dont nous avons besoin maintenant, c'est d'un meilleur logiciel : commercial, open-source ou 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 de réseau aux personnes qui ont grandi dans le nuage. Tous ceux qui s'occupent de réseaux en nuage sont intimement familiers avec le concept de VPC. Le VPC est une unité de base de consommation et d'isolation du réseau dans AWS. Il vous permet d'avoir votre propre "tranche" du réseau en nuage, où vous pouvez exécuter vos applications. Le concept est très abstrait et ne dévoile pas la mise en œuvre sous-jacente du réseau. Pour l'utilisateur, la manière dont le réseau est implémenté sous le capot n'a pas d'importance. L'utilisateur n'a aucun contrôle direct sur les concepts et protocoles sous-jacents du réseau. 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 la rendant plus " cloud " et mettons enfin le réseau physique hors d'état de nuire. Nous y travaillons d'arrache-pied, allez-vous rejoindre notre révolution ?
