Virtualisation et conteneurs pour l'automatisation réseau

Définition

La virtualisation découple le logiciel du matériel : un hyperviseur fait tourner plusieurs machines virtuelles (VM) indépendantes, chacune avec son OS invité complet, sur un seul serveur physique. La conteneurisation va plus loin dans la légèreté : un conteneur isole des processus sur le noyau du système hôte, grâce aux namespaces (vue isolée sur le réseau, les PID, le système de fichiers) et aux cgroups (plafonds de CPU et mémoire), sans OS invité. C'est pourquoi une image conteneur se compte en dizaines de mégaoctets alors qu'une image VM se compte en gigaoctets.

Contexte

Le blueprint 200-301, thème 6, demande de décrire les caractéristiques des technologies de virtualisation et de conteneurisation. À l'examen : distinguer hyperviseur de type 1 et de type 2, opposer VM et conteneur (noyau partagé, démarrage, empreinte), et connaître le vocabulaire Docker (image, conteneur, registry). Kubernetes n'est attendu qu'au niveau du rôle : un ordonnanceur de conteneurs.

Les deux familles d'hyperviseurs

	Type 1 (bare-metal)	Type 2 (hosted)
Position	Installé directement sur le matériel	Application tournant dans un OS existant
Exemples	VMware ESXi, Microsoft Hyper-V, KVM	VirtualBox, VMware Workstation, UTM
Usage type	Datacenter, serveurs de labo	Poste de travail, démos, études
Performance	Overhead minimal	Overhead de l'OS hôte

VM ou conteneur

Une VM émule du matériel : chaque OS invité charge son propre noyau, s'isole totalement des voisines et démarre en dizaines de secondes. Un conteneur ne boote aucun noyau : il démarre un processus confiné en une à deux secondes, et tous les conteneurs d'un même hôte partagent son noyau Linux. Le prix de cette légèreté est une isolation plus faible : un conteneur n'est pas une VM, et un hôte compromis l'est entièrement.

Critère	Machine virtuelle	Conteneur
Noyau	Noyau invité dédié	Noyau de l'hôte partagé
Image	Gigaoctets (OS complet)	Mégaoctets (application + libs)
Démarrage	Secondes à dizaines de secondes	Inférieur à la seconde
Densité sur 32 Go de RAM	Quelques VM	Des dizaines de conteneurs
Isolation	Matérielle/hyperviseur, forte	Processus confié, plus faible

Docker en pratique

Trois mots suffisent pour l'examen. Une image est un modèle de fichier en couches, construit depuis un Dockerfile, immuable. Un conteneur est une instance exécutable de cette image, avec son propre espace réseau. Un registry (Docker Hub, ghcr.io, ou un registry privé dans l'entreprise) stocke et distribue les images, d'où docker pull avant docker run. Une application se décrit alors en YAML :

services:
  netops-api:
    image: python:3.12-slim
    working_dir: /app
    command: python -m http.server 8000
    ports:
      - "8000:8000"
    volumes:
      - ./data:/app/data
    environment:
      - LOG_LEVEL=info

Kubernetes entre en jeu quand il faut déployer ces conteneurs sur plusieurs nœuds : il regroupe les conteneurs en pods, les réplique, les redémarre s'ils meurent et les expose derrière des services. Pour le CCNA, retenir le mot « orchestration » suffit.

Usage dans le monde réseau

Les labos réseau modernes tournent sur de la virtualisation : CML (Cisco Modeling Labs) lance des routeurs virtuels (IOSv, CSR 1000v, Cat8000V) sur un hyperviseur de type 1, et les versions récentes d'IOS XE s'exécutent justement dans des conteneurs Linux internes, ce qui explique la commande runner et les apps Docker embarquées sur les Catalyst. Packet Tracer, lui, simule le comportement des équipements sans exécuter de système réel. Côté outils, un serveur de supervision, NetBox ou un petit scraper Python se déploient aujourd'hui en conteneurs plutôt qu'en VM dédiées : même fonction, dix fois moins de RAM et une mise à jour en un docker pull.

Exemple concret

Un labo de préparation CCNA doit faire tourner 6 routeurs et 3 switchs. En VM (CML) : 9 systèmes à environ 2 Go chacun, soit 18 Go de RAM et un poste à 32 Go obligatoire. En conteneurs légers pour les mêmes outils d'automatisation (influxdb, grafana, un collector syslog) : 3 images totalisant 450 Mo au lieu de 6 Go pour trois VM, démarrage en 2 secondes par service au lieu de 40. À l'inverse, les images IOS ne se remplacent pas par des conteneurs ordinaires : elles ont besoin de leur propre noyau, donc d'une VM.

Pièges fréquents

1. Confondre hyperviseur et conteneur : ESXi ne « tourne pas dans » un OS, c'est un OS.
2. Croire qu'un conteneur possède son noyau : il partage celui de l'hôte.
3. Penser qu'une image se modifie : on modifie le conteneur, puis on fige une nouvelle image.
4. Opposer les deux technologies : en production réseau elles cohabitent (IOS XE, CML, conteneurs sur switch).