Kubernetes et conteneurs : fonctionnement, seuil de pertinence et coût réel

Kubernetes est un orchestrateur de conteneurs : il décide où exécuter chaque charge sur un ensemble de machines, la redémarre en cas de défaillance, ajuste le nombre d’instances selon la demande et déploie les nouvelles versions sans interruption. C’est aujourd’hui la réponse la plus solide au problème de portabilité entre fournisseurs. C’est aussi une plateforme dont le coût d’exploitation dépasse fréquemment le bénéfice quand elle est adoptée trop tôt. Cette page pose le fonctionnement, le seuil à partir duquel l’orchestration se justifie et les postes de coût réels, dans le prolongement de notre couverture cloud et infrastructure.

Conteneur et orchestration : deux choses distinctes

Définition. Un conteneur emballe une application et l’ensemble de ses dépendances dans une unité exécutable isolée, qui s’exécute de manière identique sur un poste de développement, en préproduction et en production. Kubernetes est l’orchestrateur qui gère le cycle de vie de ces conteneurs à l’échelle d’un parc de machines.

La confusion entre les deux conduit à des décisions coûteuses. Conteneuriser une application apporte déjà l’essentiel du bénéfice de portabilité et de reproductibilité. L’orchestration ne devient nécessaire que lorsque le nombre d’instances à piloter dépasse ce qu’une équipe peut gérer manuellement.

Une organisation qui exécute une douzaine de conteneurs sur deux serveurs n’a pas besoin de Kubernetes. Elle a besoin de conteneurs.

Ce que Kubernetes fait réellement

• Placement. L’orchestrateur choisit sur quelle machine exécuter chaque conteneur en fonction des ressources disponibles et des contraintes déclarées.
• Réconciliation. Vous déclarez un état souhaité, la plateforme s’emploie en permanence à l’atteindre. Un conteneur qui s’arrête est relancé sans intervention.
• Mise à l’échelle. Le nombre d’instances s’ajuste à la charge, selon des règles définies.
• Déploiement progressif. Les nouvelles versions remplacent les anciennes par vagues, avec retour arrière possible.
• Exposition réseau et découverte de services. Les conteneurs se trouvent entre eux sans configuration statique.

Le modèle déclaratif est ce qui fait la valeur de la plateforme. L’infrastructure devient un fichier de configuration versionné, auditable et reproductible. C’est aussi ce qui rend la portabilité réelle : une charge correctement décrite se redéploie chez un autre fournisseur avec un effort mesurable, ce qu’aucune machine virtuelle spécifique ne permet. Ce point est déterminant dans l’arbitrage de dépendance traité dans notre section hyperscalers et fournisseurs cloud.

Le coût que les présentations passent sous silence

Kubernetes ne supprime pas la complexité, il la déplace. Quatre postes concentrent l’effort réel.

Le réseau. Communication entre conteneurs, politiques d’isolation, exposition vers l’extérieur, chiffrement des flux internes. C’est le domaine où les incidents de production sont les plus fréquents et les plus difficiles à diagnostiquer.

Le stockage persistant. Les conteneurs sont conçus pour être éphémères. Y raccorder des données durables demande une conception explicite, et c’est là que les migrations de bases de données échouent.

L’observabilité. Sans journalisation centralisée, métriques et traces distribuées, un incident sur une architecture de plusieurs dizaines de services devient impossible à qualifier. Cet outillage est un prérequis, pas une option ultérieure.

La sécurité de la chaîne d’approvisionnement logicielle. Les images de conteneurs embarquent des dépendances dont personne n’a l’inventaire complet. Scan des images, signature, restriction des registres autorisés, gestion des secrets et des privilèges. Ce chantier relève autant de l’équipe plateforme que de la sécurité du système d’information.

Le seuil de pertinence

La règle tient en une phrase : l’orchestration se justifie quand le nombre de services et la fréquence de déploiement dépassent ce qu’une équipe pilote à la main, pas parce que la technologie est disponible.

Trois indicateurs concrets pour trancher :

Le corollaire : un cluster mal exploité coûte plus cher qu’un parc de machines virtuelles bien tenu. Les organisations qui adoptent l’orchestration sans équipe capable de la maintenir se retrouvent avec une plateforme qu’elles n’osent plus mettre à jour, ce qui produit une dette technique plus lourde que celle qu’elles fuyaient. Le sujet croise directement les arbitrages de refonte du parc de virtualisation.

Managé ou auto-hébergé

Les trois grands fournisseurs et les acteurs européens proposent des offres managées qui prennent en charge le plan de contrôle : mises à jour, disponibilité, correctifs de sécurité. C’est le point d’entrée raisonnable dans la quasi-totalité des cas.

L’auto-hébergement se justifie sur trois situations : une contrainte de localisation ou de souveraineté que l’offre managée ne satisfait pas, un besoin de configuration que le service managé n’expose pas, ou un volume suffisant pour que l’économie de licence dépasse le coût humain. En dehors de ces cas, il transfère vers l’équipe interne un travail de maintenance sans contrepartie.

Explorer le cluster

Cette page fait partie de notre couverture des architectures cloud et infrastructures d’entreprise : hyperscalers, souveraineté, coûts, migration et datacenters.

iTPro+ : recevez chaque semaine les analyses d’architecture qui concernent les équipes plateforme et les directions informatiques.