Plateformes d'exécution : hyperviseur, runtime, orchestrateur, serverless

45 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 9 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Une plateforme d'exécution n'est pas un service que l'application appelle : c'est ce sur quoi elle tourne, qui la lance, la surveille et la relance. Elle s'empile en couches : un hyperviseur découpe une machine en machines virtuelles, un runtime lance des conteneurs, un orchestrateur décide où les placer, et le serverless cache le tout derrière une fonction appelée à la demande. Cette leçon apprend à situer ces couches, à séparer leur plan de contrôle de leur plan de données, et à prédire ce que devient la boutique quand l'un ou l'autre tombe.

Ce que vous allez apprendre

Distinguer une plateforme d'exécution d'un service consommé
Situer hyperviseur, runtime, orchestrateur et serverless les uns par rapport aux autres
Prédire l'effet de la panne du plan de contrôle et celle d'un nœud
Dire comment le modèle d'exécution déplace les responsabilités

Pourquoi une plateforme n'est-elle pas un service comme les autres ?

La boutique appelle PostgreSQL ; elle n'appelle pas Kubernetes, elle vit dedans : la base est un service consommé, l'orchestrateur est une plateforme d'exécution. La différence change la lecture des pannes. La panne d'un service consommé se voit dans les erreurs de l'application, qui ne trouve plus sa base. La panne d'une plateforme ne se voit pas forcément dans l'application : elle continue de tourner, mais plus personne ne peut la déployer, la déplacer ni la relancer.

C'est pourquoi la V4 du fil rouge dessine l'application à l'intérieur de la plateforme, et non à côté d'elle. Le premier module a donné le vocabulaire : le plan de données sert le trafic, le plan de contrôle décide et modifie. Une plateforme d'exécution est l'endroit où les deux se séparent le plus nettement.

Hyperviseur, runtime, orchestrateur, serverless : quelle couche fait quoi ?

Chaque couche exécute la suivante : l'hyperviseur exécute des machines virtuelles, le runtime des conteneurs, l'orchestrateur décide sur quelle machine lancer chaque conteneur, et le serverless lance une fonction à chaque appel. Les couches se cumulent souvent : un cluster Kubernetes tourne sur des machines virtuelles, elles-mêmes sur un hyperviseur. Le tableau les distingue par ce qu'elles exécutent et par ce qu'elles isolent.

Couche	Ce qu'elle exécute	Isolation	Exemples
hyperviseur	des machines virtuelles complètes	un noyau par VM	KVM, Proxmox, VMware
runtime de conteneurs	des conteneurs sur une machine	noyau partagé	containerd, CRI-O, Podman
orchestrateur	des conteneurs sur un parc de machines	celle du runtime	Kubernetes, Nomad
serverless (FaaS)	une fonction, à chaque appel	gérée par le fournisseur	AWS Lambda, Knative

La ligne d'isolation compte pour la confiance. Deux conteneurs d'une même machine partagent son noyau : une faille du noyau les expose l'un à l'autre. Deux machines virtuelles ont chacune le leur. C'est pourquoi des clients qui ne se font pas confiance sont séparés par des machines virtuelles, et non seulement par des conteneurs.

Plan de contrôle et plan de données d'un orchestrateur

Dans un orchestrateur, le plan de contrôle garde l'état voulu du cluster et décide où placer chaque copie ; le plan de données est fait des nœuds qui exécutent réellement les copies et servent le trafic. Sur chaque nœud, un agent reçoit les consignes et demande au runtime de lancer les conteneurs. Le schéma montre les deux plans de la boutique.

Les deux plans d'un orchestrateur : le trafic ne traverse jamais le plan de contrôle. Source · SVG

Le trait rouge ne passe jamais par le plan de contrôle : les requêtes des clients vont directement aux copies. C'est le fait le plus utile du schéma, parce qu'il dit que les deux plans peuvent tomber séparément, avec des conséquences opposées. L'état du cluster, ici en cylindre, est le magasin etcd de la leçon DNS, temps et découverte, avec son quorum.

Que se passe-t-il quand l'un des deux plans tombe ?

Plan de contrôle en panne : la boutique continue de servir, mais rien ne peut plus changer ni se réparer ; nœud en panne : ses copies disparaissent, et le plan de contrôle les relance ailleurs s'il fonctionne. Le premier cas est trompeur, parce que tout semble aller bien. Un déploiement est refusé, une copie qui plante n'est pas relancée, la montée en charge automatique ne réagit plus. La plateforme est figée dans son dernier état.

Le second cas est celui pour lequel l'orchestrateur existe : il constate que les copies du nœud perdu manquent, et en lance de nouvelles sur les nœuds restants. Encore faut-il que ces nœuds aient la capacité de les accueillir, que le registre fournisse l'image, et que les copies soient réparties sur plusieurs nœuds dès le départ. Deux copies sur le même nœud, ou deux nœuds sur le même hyperviseur, partagent le même domaine de panne.

Ce qui tombe	Le trafic	Les changements	La réparation
plan de contrôle	continue	impossibles	aucune
un nœud	continue sur les autres copies	possibles	automatique, si capacité et image
un hyperviseur	perd toutes ses VM, donc leurs nœuds	possibles	si les nœuds étaient répartis

Que change le serverless ?

Le serverless confie toute la plateforme au fournisseur : l'équipe ne livre qu'une fonction, lancée à chaque appel et facturée à l'usage, et ne voit plus ni machine, ni nœud, ni orchestrateur. La boutique pourrait l'utiliser pour redimensionner les images de ses produits : la fonction ne coûte rien entre deux dépôts, et le fournisseur absorbe un pic de mille images.

Le prix se lit en trois points. Une fonction qui n'a pas servi depuis un moment doit d'abord être chargée : c'est le démarrage à froid, qui ajoute de la latence au premier appel. Les fonctions ont des limites de durée et de mémoire, qui les réservent aux traitements courts. Et la plateforme devient entièrement celle du fournisseur, avec ses API propres : en sortir coûte une réécriture.

Comment lire une plateforme avec la grille ?

Une plateforme d'exécution porte peu de données métier, mais elle porte l'état voulu de tout ce qui tourne, et sa perte oblige à tout redéclarer. Le tableau applique la grille à un orchestrateur. La ligne responsabilité compte autant que les autres : le modèle d'exécution choisi décide de qui répond de chaque couche, du matériel au code.

Question de la grille	Ce qu'il faut regarder
État porté	l'état voulu du cluster (etcd) ; rien de métier sur les nœuds, s'ils sont sans état
À sauvegarder	etcd, et surtout les manifestes en code versionné, d'où tout se redéclare
S'il tombe	plan de contrôle : figé ; nœud : copies relancées ailleurs
Responsabilité	VM : tout au-dessus de l'hyperviseur ; Kubernetes managé : les nœuds et au-dessus ; serverless : le code seul
Signal à surveiller	santé du plan de contrôle, nœuds prêts, copies en attente de placement

Ce que la plateforme change dans la boutique

La boutique tourne en deux copies sur un orchestrateur, réparties sur deux nœuds dans deux zones, et un nœud perdu est remplacé sans intervention. Sur la V4 du fil rouge, la plateforme d'exécution englobe l'application et tire son image du registre. Le tableau pose le compromis.

Ce qu'on gagne	Ce qu'on paie
des copies relancées seules après la perte d'un nœud	un plan de contrôle à rendre disponible, avec son quorum
des déploiements sans interruption	une plateforme complexe, à mettre à jour plusieurs fois par an
une montée en charge automatique	une capacité de réserve sur les nœuds pour accueillir les copies
un même socle pour toutes les applications	un domaine de panne partagé par toutes ces applications

La dernière ligne est le revers de la mutualisation. Une erreur sur la plateforme, une mise à jour ratée, un quorum perdu, touche toutes les applications qu'elle porte en même temps. Le choix d'un orchestrateur managé transfère la disponibilité du plan de contrôle au fournisseur, mais laisse à l'équipe la capacité, la répartition des copies et les mises à jour de ses nœuds.

Qui prend le relais pour installer une plateforme d'exécution ?

Cette leçon décrit le rôle architectural de ces couches ; leur installation et leur exploitation relèvent des formations spécialisées du site. Le guide Control Plane Kubernetes détaille l'API, etcd et l'ordonnanceur ; Découverte de l'orchestration présente les orchestrateurs. Mutualisation et isolation compare machines virtuelles et conteneurs, Serverless explique le démarrage à froid, et Responsabilités partagées répartit les responsabilités couche par couche.

Pièges de lecture courants

Ces erreurs reviennent devant une plateforme d'exécution, et elles viennent presque toutes d'une confusion entre plan de contrôle et plan de données :

Ranger l'orchestrateur avec les services consommés, à côté de la base.
Conclure que tout va bien parce que le trafic passe, alors que le plan de contrôle est tombé.
Placer deux copies sur le même nœud ou deux nœuds sur le même hyperviseur.
Prévoir la relance des copies sans la capacité pour les accueillir.
Séparer des clients qui ne se font pas confiance par de simples conteneurs.

À retenir

Une plateforme exécute l'application ; un service est consommé par elle.
Hyperviseur, runtime, orchestrateur, serverless : chaque couche exécute la suivante.
Le trafic ne traverse jamais le plan de contrôle.
Plan de contrôle en panne : tout tourne, rien ne change ni ne se répare.
Nœud en panne : relance ailleurs, si capacité, image et répartition.
Le modèle d'exécution décide de qui répond de chaque couche.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin