Mise à l'echelle avec Kubernetes

1. Introduction à Kubernetes

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.

2. 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.

2.1. 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).

2.2. 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.

2.3. 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, …

2.4. 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.

2.5. 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

2.6. 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.

3. Composants des nœuds (nodes)

3.1. 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é.

3.2. 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.

3.3. 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.

4. Les ressources de base de Kubernetes

4.1. 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.

4.2. 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.

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.

4.3. 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.

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)

4.4. 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.

4.5. 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).

4.6. 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)

4.7. 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.

4.8. 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.

4.9. 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.

5. Les commandes de base pour Kubernetes

Kubectl

Kubectl est une interface en ligne de commande qui permet d’exécuter des commandes sur des clusters Kubernetes. C’est avec cela que l’on va pouvoir effectuer diverses opérations sur notre cluster.

Kubectl dépend d’une kubeconfig. Il s’agit d’un fichier de configuration d’accès à un ou plusieurs clusters. On parlera alors de context, pour savoir sur quel cluster est configuré notre commande Kubectl, on peut utiliser :

Kubectl config current-context

Ou bien si l’on veut changer de clusters dans notre config, on peut utiliser :

Kubectl config use-context

Commandes de monitoring Kubectl

Kubectl get pods

Cette commande permet de lister les pods présents sur le cluster Kubernetes. Cette commande fonctionne pour tous les types de ressources Kubernetes: pods, services, deployments, cronjobs, events, ingresses, etc... On peut aussi ajouter des paramètres:

--all-namespaces : Liste toutes les ressources de tous les namespaces.

-o wide : Liste toutes les ressources avec plus de détails.

Kubectl describe pod

La commande describe donne un affichage verbeux du pod contrairement au get et affichage basique. Cela permet d’avoir les events, utile quand un pod ne démarre pas.

Ex : Kubectl describe pods my-pod.

Kubectl logs [-f] POD [-c CONTENEUR]

Cette commande affiche les logs de votre POD. On peut rajouter l’option -c conteneur lorsque l’on veut afficher les logs d’un pod multi-conteneur. La commande -f permet d’afficher la sortie des logs en continue (stream)

Exemple: Kubectl logs -f my_pod -c my_app

• Stream les logs du containeur my_app sur le pod my_pod.

Kubectl logs [-f] POD [-c CONTENEUR]

Affiche les métriques pour un pod donné et ses conteneurs au sein d’un cluster Kubernetes

Commandes de création/suppression Kubectl

Kubectl create -f FICHIER

Créer une ou plusieurs ressources depuis votre fichier ou dossier.

Kubectl apply -f FICHIER

Applique un changement de configuration à une ressource depuis votre fichier.

Kubectl delete (-f FICHIER | TYPE [PREFIXE_NOM | NOM])

Supprime une ou plusieurs ressources Kubernetes à partir d’un fichier de configuration ou bien directement à partir des noms des ressources.

Ex: Kubectl delete my_pod (détruit le pod sur le cluster portant le nom my_pod)

Kubectl port-forward POD [PORT_LOCAL:]PORT_DISTANT

Permet d’exposer un port local vers le port d’un POD qui est en train de tourner sur le cluster Kubernetes. Utile pour débugger.

Ex : Kubectl port-forward my_pod 80:3000 (expose le port 3000 du pod my_pod sur notre port local 80)

Kubectl run NOM --image=image [--env=”cle=valeur”] [--port=port] [--replicas=replicas]

Exécute dans la ressource dans le cluster Kubernetes.

Exemple : Kubectl run -i --tty busybox --image=busybox -- sh

• Exécute un pod comme un shell interactif