La nouvelle pile réseau OSI : conteneurs et demi-couches

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

En 1983, alors que j’apprenais encore à manipuler directement le matériel de mon Apple ][e à coups de PEEK et de POKE, un groupe de personnes partageant les mêmes idées dans les secteurs de l’informatique et des télécommunications s’est réuni pour élaborer une spécification détaillée baptisée Open Systems Interconnection (OSI). Ce qui avait commencé comme une tentative de définir précisément de véritables interfaces a fini par évoluer vers un modèle de référence commun, que d’autres organismes — comme l’IETF — pouvaient à leur tour utiliser pour développer des interfaces. Ces interfaces pouvaient alors devenir — et sont effectivement devenues — des normes : IP, TCP, HTTP, etc.

Ce modèle de référence a été enseigné à la plupart d’entre nous qui avons laborieusement suivi des cours d’informatique à l’université. Nous avons étudié les « sept couches du modèle OSI », avant de découvrir, dans la pratique, que les implémentations réelles correspondent rarement de manière exacte au modèle de réseau OSI.

Malgré tout, les correspondances sont suffisamment bonnes pour que nous continuions à l’utiliser comme le modèle de référence qu’il était censé être. La plupart d’entre nous comprennent que la couche 4 désigne TCP, la couche 7 HTTP, et les couches 2 et 3 Ethernet et IP. Ces termes sont presque interchangeables.

Il y a quelques années, nous avons même débattu de la couche à laquelle appartenaient précisément les protocoles de superposition associés au SDN et aux réseaux virtuels. Ils ne relevaient pas vraiment de la couche 2, mais pas tout à fait non plus de la couche 3. Ils se situaient en quelque sorte entre les deux.

Nous avons pu, pour l’essentiel, faire abstraction de cette question, désigner vaguement les deux couches et parler simplement de « réseau superposé ». Tout le monde comprenait ce que nous voulions dire, et nous avions d’autres sujets de débat, comme la définition du cloud et la question de savoir si le DevOps était adapté ou non à l’entreprise.

C’est là qu’entrent en scène les conteneurs – ou, plus précisément, la mise en réseau des conteneurs. L’univers hautement dynamique et automatisé des environnements d’orchestration de conteneurs (COE) a rendu nécessaires de nouvelles couches dans la pile réseau.

Comme pour les réseaux superposés, nous sommes peu enclins à créer de nouvelles couches dans le modèle OSI car, après tout, il constitue désormais une référence standard, et modifier des normes peut prendre beaucoup de temps. Beaucoup. Vraiment. Beaucoup. De temps. Mais, comme pour les réseaux superposés, ces couches existent bel et bien en tant qu’interfaces à part entière dans la pile réseau. Et, comme pour les réseaux superposés, je suis enclin à leur attribuer des « demi-couches », tant elles sont importantes pour l’avenir des réseaux dans les environnements d’orchestration de conteneurs (COE).

COUCHE 4.5 : MAILLAGE DE SERVICES

Le premier « demi-niveau » se situe entre les couches 4 et 5. C’est là qu’interviennent l’exécution et l’automatisation du maillage de services. En résumé, un maillage de services repose sur des proxys déployés en tant que conteneurs side-car, qui interceptent chaque requête. Ils peuvent ainsi appliquer aux services un routage propre au domaine dans l’ensemble de l’environnement de conteneurs. Ce système suppose l’existence de protocoles de niveau inférieur, dont il étend concrètement les fonctionnalités. Cela est nécessaire, car toutes les couches réseau sous-jacentes partent du principe que la connectivité et le routage reposent uniquement sur l’adresse IP. Et même si c’est en définitive ainsi que les paquets circulent dans un environnement de conteneurs, le choix de l’adresse IP et du port auxquels envoyer une requête donnée ne repose pas sur ces informations. Il dépend de diverses variables liées à l’état et à l’emplacement du service et de l’application. En substance, il s’agit d’examiner les métadonnées d’une requête et de les utiliser pour déterminer son routage. Ces métadonnées sont essentielles à la création du « maillage », qui garantit à son tour la disponibilité et la capacité de mise à l’échelle de chaque service.

COUCHE 7.5 : ÉTIQUETTES DE SERVICE

Le second « demi-niveau » se situe vers le haut, au-dessus de la couche 7. Blague sur la « couche humaine (couche 8) » mise à part, le COE ajoute effectivement au-dessus de l’application une couche de métadonnées qui sert de « liant » et permet la mise à l’échelle dans les environnements conteneurisés. Il s’agit des « balises » d’application ou de service utilisées pour identifier les différents services dont le COE automatise la mise à l’échelle. Sans ces balises, il est presque impossible de distinguer une application d’une autre. En effet, toutes les couches du modèle OSI sont identifiables grâce à des éléments précis, tels que l’adresse IP et le port. Si nous connaissons depuis longtemps les architectures qui reposent sur le partage de ces éléments à l’extérieur de l’environnement (serveurs virtuels et mise en réseau basée sur l’hôte), les conteneurs ont créé les mêmes problèmes à l’intérieur de l’environnement. Le partage des ports et des adresses IP complique la différenciation des services à la vitesse requise.

L’ajout de « tags » au niveau de la couche 7.5 dans les environnements conteneurisés permet aux services réseau (tels que l’équilibrage de charge et le routage) d’identifier les ressources de manière unique, tout en garantissant leur évolutivité et leur disponibilité.

Les nouvelles « couches de conteneurs » permettent à l’environnement de s’affranchir des constructions réseau et, ce faisant, garantissent une portabilité supérieure à celle des technologies précédentes, qui restaient étroitement liées aux autres couches de la pile réseau. En opérant au niveau de « demi-couches » et en partant du principe que les couches traditionnelles existent, les environnements conteneurisés deviennent indépendants de tout schéma ou de toute architecture réseau spécifique et peuvent passer avec la même facilité du développement aux tests, des tests à la production, ou encore d’une infrastructure sur site au cloud.

À 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