Pourquoi Kubernetes ?

Avant de comprendre pourquoi Kubernetes est devenu un outil essentiel dans le monde de la gestion des applications, revenons brièvement sur l'évolution des infrastructures informatiques.

Le bare metal : une époque sans isolation

À l’origine, les applications tournaient directement sur des serveurs physiques. Cela signifiait que toutes les applications partageaient les mêmes ressources matérielles, telles que le CPU et la mémoire, et étaient exécutées sans aucune séparation entre elles. Cette configuration posait de nombreux problèmes :

• Absence d'isolation : Toutes les applications fonctionnaient sur la même machine, ce qui pouvait créer des conflits. Une application utilisant trop de ressources pouvait impacter les autres, et il n'y avait aucune garantie que chaque application fonctionnerait correctement sans interférer avec les autres.
• Complexité de gestion : Avec plusieurs applications sur le même serveur, la gestion des dépendances (bibliothèques, versions) devenait complexe, augmentant le risque d'incompatibilités.
• Utilisation inefficace des ressources : Les ressources matérielles étaient souvent sous-exploitées ou mal réparties entre les applications.
• Temps d'installation : Le déploiement de nouvelles applications prenait du temps, car chaque serveur nécessitait une configuration et un provisionnement manuel.

Voici un schéma qui représente cette architecture :

INFO

• Serveur bare metal : serveur physique sans aucune couche de virtualisation
• Système d'exploitation : Un seul système d'exploitation est installé directement sur le matériel (bare metal).
• Applications 1, 2 : Les applications sont exécutées directement sur le système d'exploitation du serveur physique et partagent le CPU, la RAM ainsi que l'espace disque.

Ce modèle a servi de base pendant longtemps avant que la virtualisation, puis les conteneurs, n’apportent des solutions plus souples et efficaces pour gérer des applications à grande échelle.

L'ère des machines virtuelles

Pour mieux utiliser les ressources physiques, la virtualisation a été introduite.

• La virtualisation permettait de créer plusieurs VMs sur un seul serveur physique, chacune avec son propre système d'exploitation et un ensemble d'applications. Cela a permis de mieux exploiter les ressources disponibles.
• Chaque VM était isolée des autres, ce qui apportait une certaine sécurité et flexibilité.

Cette approche générait un certain nombre de problèmes :

• Lourdeur : Chaque VM inclut un système d’exploitation complet, ce qui consomme beaucoup de ressources (mémoire, CPU, espace disque).
• Temps de démarrage : Le démarrage d’une VM est relativement lent, car tout un système d’exploitation doit être initialisé.
• Maintenance : La maintenance des VMs implique la gestion des systèmes d'exploitation et des mises à jour individuelles pour chaque VM.

Ces inconvénients ont conduit au développement de nouvelles approches plus légères et plus agiles, telles que les containers.

Voici un schéma représentant cette architecture sous l'ère des machines virtuelles :

INFO

• Bare metal : Le matériel sous-jacent (CPU, RAM, disque, etc.).
• Hyperviseur : Le logiciel de virtualisation qui permet de créer et de gérer plusieurs machines virtuelles.
• Machine virtuelle 1,2 : Chaque VM fonctionne comme une machine indépendante, avec son propre système d'exploitation et ses applications.
• Système d'exploitation : Chaque VM a son propre système d'exploitation, ce qui engendre une consommation de ressources importante (overhead lié à la virtualisation).

Ce modèle a permis une meilleure utilisation des ressources physiques qu'avec des serveurs dédiés, mais il restait encore une forte demande d'optimisation.

L’apparition des containers

Le 18 juillet 2013 marque une étape majeure avec l’introduction de Docker 0.5, apportant les premiers containers. Mais qu’est-ce qu’un container exactement ?

Un container est un outil conçu pour automatiser le déploiement d'applications dans des environnements isolés et légers. Il permet à une application de fonctionner efficacement dans des environnements variés tout en étant isolée des autres applications.

La magie derrière les containers repose sur deux concepts essentiels :

• cgroups : Ils permettent de limiter, isoler et allouer des ressources (comme le CPU, la mémoire) pour chaque application containerisée.
• namespaces : Ils créent un environnement isolé pour chaque container, garantissant que les processus d'un container ne peuvent pas interagir directement avec ceux des autres.

Les containers permettent ainsi :

• Une meilleure isolation des applications.
• Une gestion des ressources plus fine et optimisée.
• Une portabilité accrue entre différents environnements (développement, tests, production).

INFO

• Serveur : Machine physique ou virtuelle.
• Noyau du système d'exploitation : Le système d’exploitation hôte (par exemple, Linux) qui est partagé par tous les containers.
• Docker/Runtime Container : Le moteur de containerisation (comme Docker, containerd ou CRI-O) qui gère les containers et assure leur isolation et leur gestion.
• Container 1, 2 : Chaque container contient une application ainsi que ses dépendances (bibliothèques, configurations), mais partage le noyau de l'OS avec les autres containers.
• Ressources : CPU, Ram, Stockage à disposition sur le serveur.

Pourquoi orchestrer ?

Quand vous commencez à gérer plusieurs containers (parfois des centaines ou des milliers), le besoin d'une orchestration devient indispensable. Pour bien comprendre l’orchestration, commençons par la notion de cluster.

Un cluster est un ensemble de machines (physiques ou virtuelles) qui fonctionnent ensemble pour héberger des containers. Mais gérer manuellement l'état de chaque container dans un cluster est impossible à grande échelle.

Comparons trois types d’architectures pour mieux comprendre ce que l’orchestration apporte :

Architecture	Description	Avantages (Pros)	Inconvénients (Cons)
Application Monolithique	Une architecture où toute l'application est développée et déployée en un seul bloc. Tous les composants sont fortement liés, et l'ensemble est géré dans un seul processus.	- Simplicité de développement et de déploiement initial. - Performances optimales pour des petites applications. - Facile à tester et à déboguer.	- Scalabilité limitée (difficile de faire évoluer une partie sans tout redéployer). - Couplage fort entre les composants. - Maintenance complexe.
Monolithe Distribué	Variante de l'architecture monolithique, où certains composants du monolithe sont distribués entre différents environnements, tout en restant liés dans un ensemble cohérent.	- Partage de certaines ressources à travers plusieurs environnements. - Scalabilité améliorée par rapport au monolithe classique.	- Complexité accrue par la gestion de la distribution. - Possibilité de goulots d'étranglement si certaines parties ne sont pas bien séparées.
Microservices	Une architecture où l'application est composée de services indépendants, chaque service représentant une partie fonctionnelle distincte. Chaque service peut être déployé séparément.	- Très grande scalabilité (chaque service peut évoluer indépendamment). - Résilience améliorée. - Flexibilité dans le choix des technologies.	- Complexité accrue (orchestration, surveillance, communication entre services). - Difficulté dans la gestion des transactions distribuées.

• L’orchestration vise à automatiser la gestion des containers, ce qui inclut :
  • Le déploiement automatique de containers.
  • La gestion des défaillances (redémarrage d’un container planté).
  • La mise à l’échelle automatique en fonction de la charge.
  • La répartition de la charge réseau entre les containers.

L’orchestration est cruciale pour évoluer vers des architectures complexes comme les microservices, où chaque service (authentification, facturation, etc.) fonctionne dans son propre container et doit interagir avec d'autres services dans le cluster.

Les alternatives à Kubernetes

Kubernetes n'est pas le seul orchestrateur de containers. Voici les principales alternatives :

Orchestrateur	Description	Cas d'usage
Docker Swarm	Orchestrateur natif de Docker, simple à configurer et intégré à l'écosystème Docker.	Petits clusters, équipes déjà sur Docker, besoin de simplicité.
HashiCorp Nomad	Orchestrateur léger et flexible, capable de gérer containers, VMs et applications standalone.	Environnements hétérogènes, intégration avec l'écosystème HashiCorp (Vault, Consul).
Apache Mesos	Plateforme de gestion de ressources distribuées, souvent couplée à Marathon pour l'orchestration.	Très grands clusters, workloads mixtes (Big Data, containers).

Malgré ces alternatives, Kubernetes domine largement le marché grâce à son écosystème riche, sa communauté active et son adoption massive par les cloud providers (GKE, EKS, AKS).

Kubernetes : la réponse aux besoins d'orchestration

En 2015, Google a ouvert une grande partie de son infrastructure de gestion interne des containers avec la création de Kubernetes, basé sur un projet interne appelé Borg. Borg était utilisé en interne par Google pour orchestrer des millions de containers, et Kubernetes en est une version modernisée et open source. L'idée derrière Kubernetes était de permettre aux entreprises d'orchestrer leurs containers à grande échelle, de la même manière que Google gérait ses propres services.

Il permet, par exemple, de :

• Automatiser le déploiement des containers.
• Assurer que les containers défaillants soient redémarrés automatiquement.
• Gérer la répartition des charges entre les containers.
• Faciliter la mise à l’échelle des services en fonction de la demande.

NOTE

Le nom Kubernetes vient du grec « κυβερνήτης » (kubernêtês), qui signifie « timonier » ou « pilote », une métaphore reflétant son rôle dans la direction des containers à travers différents environnements.

C'est également un clin d'œil à l’univers de Star Trek, où l’idée de « diriger » des vaisseaux à travers l’espace rejoint l’idée de diriger des containers à travers les ressources informatiques. En outre, le logo de k8s est une hélice à 7 branches (contre 6 traditionnellement sur un gouvernail), rendant ainsi hommage au "Seven of Nine", un personnage de la série.

En résumé, Kubernetes est devenu un outil indispensable dans l’écosystème DevOps moderne, permettant de simplifier la gestion des applications, tout en garantissant une efficacité et une fiabilité accrues.