Le traducteur de jargon des conteneurs pour le NetOps

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Il y a des jours où le jargon issu de l’univers des conteneurs donne le tournis. Chaque nouvelle fonctionnalité ou capacité proposée par les solutions connexes — maillage de services, orchestrateurs, registres — semble imposer un nouveau terme ou une nouvelle expression. Cette expression est souvent claire pour les équipes DevOps, mais laisse les équipes NetOps perplexes et dubitatives.

Un peu comme celle que vous faites quand je vous demande où se trouve le « bubbler » le plus proche. Vous appelez ça une fontaine à eau. Dans le Wisconsin, on appelle ça un « bubbler ». Même chose, terme différent.

Il s’avère qu’un grand nombre des « nouvelles » capacités et fonctionnalités liées à la mise à l’échelle des conteneurs en interne et dans des scénarios multicloud ne sont en réalité que des fontaines à eau que les équipes DevOps appellent des « bubblers ». Ce choc de régionalismes peut créer des frictions avec les équipes NetOps, alors que les conteneurs poursuivent inexorablement leur démocratisation. Même si, en production, les clusters de conteneurs restent isolés et fonctionnent comme des mini-clouds, ils conservent des points de contact avec le réseau d’entreprise, sur lequel les équipes NetOps continuent de régner. Et, inévitablement, les équipes NetOps et DevOps devront collaborer pour mettre ces clusters à l’échelle de manière sécurisée dans un environnement multicloud.

Contrôleur d’entrée

• Comme indiqué précédemment, le terme « contrôleur d’entrée » a donné un nouveau visage à l’équilibrage de charge de couche 7 (commutation de contenu, routage de contenu, etc.). Un contrôleur d’entrée est un proxy prenant en charge la couche 7 (HTTP), qui achemine les requêtes vers la ressource appropriée au sein d’un cluster de conteneurs. La principale différence entre les proxys HTTP utilisés par les équipes NetOps sur le réseau et ceux qui servent de points d’entrée aux clusters de conteneurs réside dans le fait qu’un contrôleur d’entrée doit tenir compte des conteneurs. Par « tenir compte des conteneurs », j’entends qu’il est configuré et géré automatiquement en fonction des changements qui interviennent dans l’environnement de conteneurs, en particulier dans le fichier de ressources qui décrit la manière dont le contrôleur d’entrée doit acheminer les requêtes entrantes.

Équilibrage de charge tenant compte de la latence

• Ça paraît sympa et novateur, non ? Mais lorsqu’on regarde sous le capot, les équipes NetOps constateront avec un hochement de tête appuyé qu’il ne s’agit en réalité de rien d’autre que d’exploiter un algorithme d’équilibrage de charge basé sur le « temps de réponse le plus rapide ». L’objectif est d’améliorer les performances de l’application en « détournant le trafic des instances lentes ». Si ce point est mis en avant, c’est parce que, de manière générale, les algorithmes natifs d’équilibrage de charge utilisés par les orchestrateurs de conteneurs ne tiennent pas compte des performances. Le Round Robin est pratiquement la norme, alors que nous savons qu’il s’agit de l’un des derniers algorithmes à choisir lorsqu’on cherche à optimiser les performances. Pouvoir acheminer les requêtes en fonction des meilleures performances est particulièrement important, car chaque appel entre microservices nécessaire au traitement d’une seule requête client ajoute sa propre latence.

Entrée multicluster

• Je vais commencer par dire que cette expression est bien plus accrocheuse que celle utilisée par le secteur depuis près de vingt ans. Il s’agit essentiellement du GSLB (Global Server Load Balancing). Oui, je sais, vous êtes déçus, mais en coulisses, c’est bien ce que fait le multi-cluster ingress : vous prenez un contrôleur d’ingress, vous y ajoutez une bonne dose de gestion globale du trafic, et voilà ! Vous obtenez du GSLB pour des clusters de conteneurs dans une configuration multicloud. Côté NetOps, je vote pour remplacer GSLB par cette expression, car elle est tout simplement plus impressionnante.

Ce ne sont pas les seuls termes à avoir fait leur apparition, et ce ne seront pas les derniers. Ce sont les plus pertinents en matière de fonctionnalités et de capacités « au sein du réseau » désormais prises en charge par le DevOps. Certains nécessiteront l’attention du NetOps lors de leur passage en production (comme le Multi-Cluster Ingress), tandis que d’autres non : l’équilibrage de charge tenant compte de la latence au sein des environnements de conteneurs restera probablement du ressort du DevOps, même s’il est utile d’en comprendre le fonctionnement lors des discussions visant à améliorer les performances ou la disponibilité.

DevOps comporte une dimension culturelle qui est souvent négligée, voire totalement ignorée. À mesure que ce mouvement gagne du terrain dans le domaine du NetOps et que les opérations réseau traditionnelles adoptent progressivement mais sûrement ses principes afin de rendre le réseau plus agile, la communication devient essentielle. Il faut donc trouver un terrain d’entente. Comprendre le jargon de chacun peut constituer un bon premier pas vers l’instauration d’une culture plus collaborative, indispensable pour garantir que les déploiements d’applications soient aussi rapides, sécurisés et fiables que leur mise à disposition.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie