Définition K8S : Kubernetes

Qu’est-ce que Kubernetes ?

C’est un orchestrateur de conteneur (mais potentiellement extensible à d’autres formats). Il s’assure en permanence que soit respecté un état d’exécution attendu pour un ensemble d’asset.

Il surveille différents objets en comparant leur statut à un attendu exprimé dans une base de données. Si des divergences sont constatées, Kubernetes (ou K8S) n’aura de cesse de vouloir faire revenir le système à la conformité demandée.

C’est également un écosystème de développement et de mise en production, fournissant une API et une liste d’objets prévus pour interagir entre eux.

Kubernetes permet à la fois l’exécution d’application et la gestion de leur cycle de vie associé.

Comment fonctionne Kubernetes ?

Organisation logique

Kubernetes travaille avec la notion d’objets logiques.

Chacun est décrit et manipulable via une API dans lequel se retrouvent différentes branches. Ces branches représentent des arborescences dans lesquelles on va retrouver ces différents objets.

Chaque objet couvre une fonction au sein du cluster. Ces objets interagissent entre eux et peuvent se retrouver liés à travers des labels.

Chaque objet dispose d’un périmètre d’interactions, certains sont limités à un espace de nom spécifique, d’autres peuvent être transverses à tout un cluster.

Chaque objet dispose de ses propriétés, certaines obligatoires d’autres, facultatives. Ces objets peuvent être décrits au sein de fichiers yaml ou être exécutés directement à partir d’une CLI ou d'un SDK.

La manipulation de ces objets est soumise à des contrôles d’accès basés sur des rôles (RBAC ou Role-based access control) permettant une maitrise fine des actions possibles au sein du cluster.

Une application sera représentée par un ensemble d’objets, qui une fois en œuvre, pourront permettre son bon fonctionnement et son exposition.

L’API dispose d’objets natifs, mais peut être étendu avec des objets tiers ajoutant souvent une branche à l’API et autorisant d’autres fonctions au sein du cluster.

Composition

Kubernetes s’appuie sur une composition modulaire.

K8S exploite différentes briques, la plupart sous forme de conteneurs, qui vont avoir la charge d’occuper un rôle bien précis au sein du cluster.

Ces briques peuvent se répartir sur différents serveurs, physique ou virtuel, certaines pouvant être répliquées pour fournir une haute disponibilité du service associé.

Parmi les modules de base, on va retrouver l’API, le scheduler, le control manager et d’autres.

Ces briques de bases se trouvent la plupart du temps hébergées sur une même machine et vont constituer ce qu’on appelle un control plane.

Dans des environnements de production, on va retrouver plusieurs control plane (ou master), travaillant ensemble et se partageant la gestion de la base de données hébergeant la configuration du cluster. (La plupart du temps on va parler de la solution etcd et d’un modèle de base clef/valeur).

S’ajoute à ces control plane des serveurs d’exécution, appelés historiquement worker.

On n’y trouve beaucoup moins de composants, a minima un agent nommé kubelet. Ces serveurs sont chargés d’exécuter les assets et sont pilotés par le ou les control plane. Ils peuvent s’ajouter (et se retirer) très facilement pour étendre les capacités du cluster si nécessaire.

La redondance des applications est directement à charge du cluster, puisque si un worker venait à tomber, ses assets seront automatiquement replanifiés pour être réexécutés sur un autre node sous condition que les ressources sont suffisantes et que les nœuds restants soient compatibles.

Il est important de noter que chaque brique d’un cluster Kubernetes est configurable et adaptable. Il faut voir K8S comme une collection de composants open source dont une implémentation de base est communiquée et conseillée, mais chacun peut les assembler à sa convenance et réécrire le code associé.

De la même manière, ces composants, s’ils permettent la construction d’un cluster, ne sont généralement pas suffisants pour offrir toutes les fonctionnalités attendues au sein d’une production.

Il est courant d’étendre le cluster avec des addons spécialisés dans certains domaines, comme le réseau ou le stockage pour autoriser d’autres services au sein du cluster (le filtrage des flux, la répartition de charges, le stockage persistant....).

Pour cela K8S fournit des standards qui simplifient le développement de ses addons et garantissent une prise en charge de ses derniers par le cluster.

Ces addons peuvent étendre l'API avec de nouveaux objets.

Le choix du moteur d’exécution des conteneurs reste à charge des équipes IT. Kubernetes n’exécute pas les conteneurs à proprement parlé mais pilotes des moteurs d’exécutions compatibles avec son format de prise en charge.

Cette conception modulaire, extensible grace à des normes établies, permet de déployer des cluster Kubernetes dans de multiples environnements.

Certains éditeurs proposent un assemblage de ces composants avec une gestion automatiséee du versionning et des addons, ajoutant un support pour les entreprises: on parle alors de distribution Kubernetes.

Il est également courant de s’appuyer sur des outils d’aide à l’installation, dont certains sont officiellement développés avec les modules de base, comme kubeadm.

Lorsqu’on implémente un cluster via la configuration par défaut combinant les modules minimaux avec leur paramétrage par défaut, on parlera d’installation Vanilla.

Certains composants peuvent être revus et adaptés à des usages plus spécifiques, proposant alors des clusters optimisés et destinés à des plateformes d’exécutions spécifiques, comme l’IOT.

Enfin, les principaux providers de cloud public disposent tous d’une offre « Kubernetes As A service » proposant la plupart du temps de masquer la complexité de gestions des control plane.

Dans la majorité des cas, qu’il s’agisse d’une distribution kubernetes (comme OpenShift), d’une installation Vanilla, d’un cluster adapté (comme k3s) ou d’une offre cloud (comme AKS), il existe une compatibilité minimum des applications développées sur ces plateformes simplifiant les opérations de migration ou de réhébergement.

Les logiques de CICD et les compétences acquises peuvent trouver écho dans toute plateforme reposant sur Kubernetes, ce qui fait de K8S une des solutions les plus efficaces pour construire des infrastructures hybrides.

A noter qu'il est tout à fait possible d'utiliser un seul et meme serveur, virtuel comme physique pour supporter l'intégralité des composants kubernetes. On n'aura un node à la fois control plane et worker. Ce n'est évidamment pas une solution de production, mais c'est très pratique pour du développement ou de la montée en compétence, notamment à travers des solutions comme minikube

Remarques personnelles

Kubernetes ne se résume pas à une simple infrastructure d’orchestration de conteneur. Ces origines se trouvent chez Google qui a rendu publique sa propre solution de gestion d’asset utilisée pour l’usage de ses produits.

Cette dernière a par la suite suivi un développement tourné vers la communauté via la Cloud Native Computing Foundation. Fondation elle-même sous gestion de The Linux Foundation, faisant de Kubernetes l’un des plus gros projets open source du monde.

On y retrouve donc une logique orientée cloud, avec une construction modulaire issue du développement et des architectures micro service (mais pas que).

Le focus est fait sur la disponibilité et la scalabilité.

Au fil des années (Kubernetes a fêté ses 10 ans 2024), K8S s’est enrichi d’un écosystème riche et en constante évolution. De nouveaux usages lui ont été associés.

Une standardisation s’est construite autour de lui autorisant des architectures hybrides et l’usage de différents clusters hébergés au sein de différents fournisseurs, interne comme public.

Son API extensible et facilement manipulable a permis l’émergence de nombreux outils, aussi bien pour la supervision que pour la sécurisation ou le CICD.

S’il existe des concurrents, ces derniers bien qu’également performant et fonctionnel, ont beaucoup de mal à lutter et se retrouve bien souvent relayés à des usages particuliers.

Comme toute technologie, Kubernetes n’est pas magique non plus. Il vient avec son lot de défaut, comme une complexité jugée parfois élevée avec des notions un peu "étonnante" au début comme le pod, un rythme d’évolution difficile à suivre et des engouements marketing un peu trop exagérés.

Mais on ne peut nier sa croissance et son importance. C’est un formidable produit avec lequel on peut construire énormément de choses. L’important est de toujours faire correspondre sa réalisation à son besoin.

Il est préféré de maitriser son architecture finale plutôt que de courir après les dernières implémentations en vogue : rouler en Ferrari n’a jamais été des plus pratiques pour chercher le pain en bas de chez soi, surtout si on n’a pas le permis.

Kubernetes s’apprend vite, mais met du temps à se maitriser. C’est également une plateforme qui se veut transverse aux compétences d’un IT. On n’y retrouve de nombreux principes d’infrastructure comme le SDN (Software-defined networking) ou le (SDS Software-defined storage), des stratégies de déploiement comme le Canary release, ou le Green/Blue et des modèles d’architecture applicative comme les microservices.

Il est donc nécessaire de mêler les compétences, réduire les silos entre équipes (sans forcement, cherchez à les dissoudre) et surtout mettre en avant le bon sens et l’esprit de groupe pour implémenter avec succès un projet Kubernetes.