Introduction à Kubernetes

Publié le : 30 décembre 2021 | Mis à jour le : 27 juin 2023

Le premier billet de la formation kubernetes qui sera je l’espère une longue série. Ce premier billet permet de définir tous les concepts et objets principaux utilisés sur un cluster Kubernetes. Vous devez posséder au préalable des connaissances sur les conteneurs avant de vous attaquer à Kubernetes. Si certains mots ne sont pas clairs pour vous, vous pouvez aller faire un tour sur mon lexique Devops.

Table des matières

Introduction

Kubernetes, k8s, est un système Open Source qui exécute et coordonne des applications conteneurisées dans des clusters. Kubernetes gère le cycle complet de vie des applications et des services permettant ainsi de limiter le nombre de processus nécessaire au déploiement et à la mise à l’échelle des applications conteneurisées.

À l’origine, la plateforme Kubernetes a été conçue et développée par Google qui déployait depuis une dizaine d’années des conteneurs via une plateforme interne nommée Borg.

Architecture de Kubernetes

Dans un cluster Kubernetes, il existe deux rôles de machines : le(s) nœud(s) maîtres(master) et le(s) nœud(s) de travail (workers).

Le(s) nœud maître exécute(ent) le plan de contrôle Kubernetes, qui est responsable de la gestion des workers, prend les décisions de planification et met en œuvre des modifications pour conduire le cluster à l'état souhaité.

Les workers, comme leur nom l’indique sont chargés de gérer les applications via des pods.

architecture kubernetes

Le Control Plane

Dans le graphique ci-dessus nous voyons que le Control Plane Kubernetes est composé de plusieurs éléments. Chacun de ces éléments sont essentiels à la bonne santé d’un cluster Kubernetes. Si un de ces composants vient à dysfonctionner le cluster devient instable voir irrécupérable (etcd par exemple).

ETCD

ETCD est une base de données distribuée de type clé-valeur, qui a été développée en “Go”, le langage de programmation de Google. Dans un cluster Kubernetes, ETCD est chargé de stocker la configuration et les informations nécessaires au fonctionnement du cluster, c’est-à-dire de tous ses composants : les nœuds, les pods, les configs, les secrets, les rôles, les comptes, etc.

L’API-Server

L'API Server est le composant central du cluster qui expose l'API REST de Kubernetes. C’est donc l’élément “frontal” du Control Plane de Kubernetes et c’est lui qui reçoit tous les appels et demandes, externes ou internes. C’est ce composant qui gère entre autre les appels via les commandes kubectl. Il est donc chargé :

De gérer les authentifications,
De valider les demandes reçues,
De gérer les données stockées dans la base de données ETCD,
De fournir les informations aux autres composants du cluster : kubelet, scheduller, …

Le Scheduler

Le scheduler est chargé de la répartition des pods entre les différents workers nodes. Cette répartition se fait en fonction des ressources disponibles et des contraintes qui lui sont indiquées. Ces contraintes peuvent être des prérequis de type CPU et mémoire, des contraintes hardware, des affinités et anti-affinités.

Les nœuds sont filtrés en supprimant ceux qui ne répondent pas aux exigences du pod. Ensuite, les nœuds retenus sont classés par score, celui ayant obtenu le score le plus élevé est sélectionné.

Le scheduler indique au service kubelet du worker node sélectionné qu’il doit démarrer le pod.

Le Controller-Manager

Dans Kubernetes, le Controller Manager contient plusieurs controllers. Un controller est une boucle de contrôle qui surveille en permanence l’état d’un groupe d’objet qui lui est attribué. Il fera des demandes de modifications au serveur d’API, ou en direct si nécessaire, pour que l’état actuel de ses objets soit celui de l’état souhaité.

Parmi ces contrôleurs on retrouve :

Deployment controller
StatefulSet controller
Node controller
Service controller
Endpoints controller
Namespace controller
PersistentVolume controller
…

La description de ces objets est faite plus bas dans ce billet.

Cloud-Controller-Manager (optionnel)

Kubernetes peut fonctionner sur des clouds publics, privés et hybrides. Le Cloud-Controller-Manager permet de lier votre cluster à l'API de votre fournisseur de cloud. Il permet donc aux fournisseurs de cloud de publier des fonctionnalités à un rythme différent de celui du projet Kubernetes.

Composants des nœuds (nodes)

kubelet

Kubelet est un agent qui tourne sur tous les worker nodes du cluster Kubernetes. Kubelet examine les spécifications qui lui sont transmises par le scheduller et fait en sorte que les conteneurs définis avec ces spécifications tournent et soient en bonne santé.

kube-proxy

kube-proxy est un proxy réseau qui s’exécute sur chaque worker node de du cluster et gère les règles réseau. Ces règles réseau permettent une communication réseau vers les Pods depuis des sessions réseau à l’intérieur ou à l’extérieur du cluster. kube-proxy utilise la couche de filtrage de paquets du système d’exploitation hôte s’il y en a une de disponible. Sinon, kube-proxy transmet le trafic lui-même.

Container Runtime

L’environnement d’exécution de conteneurs (Container Runtime) est le logiciel responsable de l’exécution des conteneurs. Le CRI est une interface de plug-in qui permet à kubelet d’utiliser différents environnements d’exécution de conteneurs, sans à avoir besoin de recompiler les composants du cluster. Kubernetes est compatible avec : Docker, ContainerD, cri-o, rktlet entre autre.

Les ressources Kubernetes

Ressources de base

NameSpaces

Dans Kubernetes, les namespaces ou espaces de noms fournissent un mécanisme pour isoler des groupes de ressources au sein d’un seul cluster. Les noms de ressources doivent être uniques au sein d’un même namespace, mais pas entre namespaces. La portée basée sur un namespace s’applique uniquement aux objets avec namespace (par exemple, déploiements, services, etc.) et non aux objets à l’échelle du cluster (par exemple, StorageClass, Nodes, PersistentVolumes, etc.)

Il n’est pas nécessaire d’utiliser plusieurs namespaces pour séparer des ressources légèrement différentes, telles que des versions différentes de la même application : utilisez plutôt les labels (étiquettes) pour distinguer les ressources au sein du même namespace.

Pods

Les pods sont les plus petites unités déployables que vous pouvez créer et gérer dans Kubernetes. Un Pod est un groupe d’un ou plusieurs conteneurs partageant des ressources réseau, de stockage et d’un ensemble d’espaces de noms qui s’exécutent sur les workers.

kubernetes pods

Un pod peut aussi contenir des conteneurs d’initialisation qui s’exécutent lors du démarrage de celui-ci.

Vous créerez rarement des pods directement dans Kubernetes! Vous les instancierez à l’aide de ressources de charge de travail telles que les déployments, les daemonsets ou les statefulets.

Services

Comme les pods sont des objets non permanents comment y accéder si leur IP changent ? C’est à ce niveau qu’interviennent les Services. Un service est une couche d’abstraction qui définit des règles permettant d’accéder à un ensemble logique de pods. Un Service permet donc aux pods de recevoir du trafic.

Pour cibler des pods un service va utiliser ce qu’on appelle un selector, qui va rechercher dans le cluster des objets possédant des paires clé/valeurs correspondantes à celles attendues.

kubernetes pods

Il existe différentes manières d’exposer un service :

ClusterIP (par défaut) : expose le Service sur une adresse IP interne au cluster
NodePort : expose le Service sur un port statique du node
Loadbalancer : expose le Service à l’extérieur en utilisant l’équilibreur de charge d’un fournisseur de cloud computing
ExternalName : Mappe le service à un nom externe (exemple : artefacts.robert.local)

Volumes

Par défaut les fichiers d’un pod sont éphémères, lorsqu’un conteneur plante, kubelet va le redémarrer, mais les fichiers du pod précédent sont perdus.

Pour ajouter de la persistance de données dans kubernetes il est possible d’utiliser des volumes. Kubernetes prend en charge plusieurs types de stockage dont les principaux sont : hostPath, emptyDir, configMap, nfs, secret, local, PersistentVolumeClaim, … La liste complète se trouve ici

Les volumes permettent également de partager des fichiers entre conteneurs.

Les Workloads

Un workload (charge de travail) est une application fonctionnant sur Kubernetes faisant appel à un ou à une série de pods. Un workload Kubernetes permet d’automatiser le processus de publication d’une application et de la rendre ainsi reproductible. Tout est géré par le back-end de Kubernetes sans intervention de votre part, sauf bien sur sa déclaration.

Nous ne verrons ici les ressources standards de Kubernetes, mais il est possible d’en ajouter de nouveaux via ce qu’on appelle un CustomResourceDefinition (CRD).

Déployments

Un déploiement permet de décrire le cycle de vie d’une application sans état, en spécifiant en autre les images à utiliser, la façon dont les pods doivent être mis à jour ou mis à l’échelle (scaling)

StatefulSet

Contrairement à un déployment, un StatefulSet conserve une identité persistante pour chacun de ses pods. Les pods d’un StatefulSet sont créés à partir de la même spécification, mais ne sont pas interchangeables : chacun a un identifiant persistant qu’il conserve lors de toute reconstruction.

Par exemple si vous souhaitez utiliser des volumes de stockage pour assurer la persistance de vos données, un StatefulSet peut être la solution surtout si les volumes sont spécifiques à chaque pod.

DaemonSet

Le DaemonSet est utilisé pour le déploiement, comme son nom l’indique d’un daemon. Il va lancer une instance unique de pod sur chacun des workers nodes du cluster Kubernetes. En cas d’ajout d’un worker node, le controle plane de Kubernetes va programmer l’ajout d’un Pod pour ce DaemonSet sur ce nouveau noeud.

On l’utilise le plus souvent pour gérer du stockage, du monitoring ou de la journalisation de log.

Jobs et CronJobs

Les Jobs permettent d’exécuter des tâches ponctuelles voir des batchs plus complets. CronJob, en analogie avec les crons linux, permet de planifier à quels moments (minute, heure, jour du mois, mois et jour de la semaine) ces tâches doivent s’exécuter.

Extensions de Kubernetes

Kubernetes est hautement configurable et extensible via des plugins sur une grande partie des composants du cluster. Il est donc possible d’étendre au niveau de l’infrastructure du cluster :

Les ressources de type réseau
Les ressources de type volume
D’intégrer de nouveaux devices
D’intégrer, voir de remplacer le scheduller par un autre.

Un autre moyen d’étendre les fonctionnalités d’un cluster Kubernetes est d’ajouter des points d’entrée à l’API. Cela permet d’intégrer des nouvelles méthodes d’authentification, d’autorisations et de contrôle d’admission.

Administration d’un cluster Kubernetes : le client officiel kubectl

Kubectl est l’outil officiel en ligne de commande pour administrer des clusters Kubernetes. Il permet de gérer l’ensemble des objets définis sur un cluster Kubernetes.

Installation de kubectl

Pour installer kubectl je vous conseille d’utiliser asdf qui permet d’installer une très grande partie des outils permettant de gérer des clusters kubernetes.

asdf plugin add kubectl
asdf install kubectl latest
asdf global kubectl latest

kubectl version --output=yaml
clientVersion:
  buildDate: "2023-04-14T13:21:19Z"
  compiler: gc
  gitCommit: 4c9411232e10168d7b050c49a1b59f6df9d7ea4b
  gitTreeState: clean
  gitVersion: v1.27.1
  goVersion: go1.20.3
  major: "1"
  minor: "27"
  platform: linux/amd64
kustomizeVersion: v5.0.1
serverVersion:
  buildDate: "2023-03-27T22:23:17Z"
  compiler: gc
  gitCommit: 01ea3ff27be0b04f945179171cec5a8e11a14f7b
  gitTreeState: clean
  gitVersion: v1.26.3+k3s1
  goVersion: go1.19.7
  major: "1"
  minor: "26"
  platform: linux/amd64

Syntaxe de kubectl

Sa syntaxe est la suivante :

kubectl [commande] [TYPE] [NOM] [flags]

commande : Indique l’opération que vous désirez exécuter sur une ou plusieurs ressources, par exemple create, get, describe, delete.
TYPE : Indique le type de ressources que vous voulez manipuler
NOM : Indique le nom de la ressource (sensible à la casse)
flags : flags optionnels

Mode de fonctionnement de Kubectl

Il existe deux modes de fonctionnement de la cli kubectl. Le mode impératif et le mode déclaratif.

Le mode déclaratif utilisera principalement la commande apply et fera appel à un fichier manifest écrit en yaml décrivant un ou plusieurs ressources à créer. Si la ressource n’existe pas elle sera créée, si elle existe kubernetes adaptera les ressources en fonction des modifications éventuellement apportées.

Le mode impératif permet de créer une ressource directement sans utiliser forcément un fichier manifest. Si une ressource existe la commande kubectl create .. retournera une erreur.

Le mode impératif utilise essentiellement les commandes create, delete et replace.

Déployer un cluster Kubernetes

Maintenant que nous avons mis en place tous ces concepts passons à l’installation d’un cluster Kubernetes. Je vous propose de suivre ce tutoriel montrant comment l’installer avec kubeadm sur des VM provisionnées avec vagrant. Ou si vous êtes à court de ressources matérielles avec kind.

Plus d’informations

Comme dis en au début du billet, ce billet fait partie d’une série. Je vous invite donc à revenir de temps en temps, car je risque de le compléter comme je l’ai déjà fait avec Ansible. Parmi les sujets prévus : la création d’applications, les bonnes pratiques, une aide à la résolution d’incident, une sélection d’outils, etc.

Voici la liste des billets existants (certains sont en cours de réécriture, Eh oui je progresse et les outils évoluent également) :

Vous pouvez également regarder du côté de mon Home Lab Devops ou j’utilise k3s pour :

Source Principal

Stéphane ROBERT

Tous les billets sur :