Qu’est-ce qu’un Kubernetes pod ?

Un Kubernetes Pod peut contenir un ou plusieurs conteneurs qui sont étroitement liés entre eux et partagent des ressources. Ils servent ainsi d‘environnement coordonné pour les applications.

Kubernetes pod

Les pods sont les unités de déploiement de base dans Kubernetes et comprennent un ou plusieurs conteneurs interconnectés. Un pod partage le même espace réseau, la même mémoire et d’autres ressources et représente ainsi un regroupement logique de conteneurs. Les conteneurs au sein d’un Kubernetes pod interagissent étroitement et communiquent entre eux.

Le modèle un-conteneur-par-Pod

Un pod à un conteneur encapsule un conteneur unique. Cette structure est souvent utilisée lorsqu’une application ou un micro-service doit fonctionner dans un environnement isolé, sans avoir besoin de partager les ressources et le réseau avec d’autres conteneurs. Ce type de pod est certes la forme la plus simple sous Kubernetes, mais il offre les avantages de l’orchestration, de l’évolutivité (scaling) et de la gestion.

Pods avec plusieurs conteneurs

Un pod exécutant plusieurs conteneurs héberge plus d’un conteneur au sein d’un même pod. Ces conteneurs interagissent et partagent le même espace réseau et les mêmes ressources. Ce type de pod est souvent utilisé lorsque des conteneurs sont étroitement liés entre eux et remplissent une tâche ou une fonction commune. Par exemple, un conteneur d’application principal et un conteneur side-car pour la connexion ou la surveillance pourraient être exécutés dans un seul Kubernetes pod. Cela permet une coordination et une communication plus étroites entre les conteneurs, tout en les traitant comme une entité unique au sein du cluster Kubernetes.

Création d’un Kubernetes Pod

Pour créer un Kubernetes pod, vous avez besoin d’un fichier YAML qui décrit la spécification du pod. Voici un exemple simple de Nginx-Pod :

apiVersion: v1
kind: Pod
metadata:
    name: nginx-pod
spec:
    containers:
    - name: nginx-container
        image: nginx:latest

Ce document YAML définit un pod nommé nginx-pod qui contient un seul conteneur nommé nginx-container. Le conteneur utilise la dernière image Nginx du hub Docker.

Saisissez la commande suivante pour créer le pod :

kubectl apply -f nginx-pod.yaml

Utilisation de Kubernetes Pods

L’utilisation de niveaux d’abstraction supérieurs tels que Deployments ou StatefulSets est recommandée pour gérer les pods dans un environnement de production. Ces contrôleurs se chargent de définir l’état souhaité de l’application et de s’assurer qu’il correspond bien à l’état réel. Ainsi, l’évolutivité, la mise à jour progressive et la restauration automatique des pods sont mises en œuvre.

Lors de la création d’un pod, que ce soit directement par l’administrateur ou indirectement via un contrôleur, le nouveau pod est planifié sur un nœud spécifique dans le cluster. Le pod reste sur ce nœud assigné tant que l’un des cas suivants ne se présente pas : il termine son exécution, l’objet pod associé est supprimé manuellement, manque de ressources ou d’autres problèmes exigent l’évacuation du pod vers un autre nœud, ou le nœud actuel tombe en panne. Dans ce cas, le pod est redémarré sur un autre nœud disponible afin de garantir une exécution continue, sans interruption.

Le nom d’un pod doit être défini comme une valeur de sous-domaine DNS valide. Ceci est important pour que le pod soit clairement identifiable au sein du cluster Kubernetes. Les étiquettes DNS ne doivent pas dépasser 253 caractères, ne peuvent contenir que des caractères alphanumériques et des tirets, et doivent commencer et finir par un caractère alphanumérique.

Pod OS

Les Kubernetes pods sont généralement configurés pour fonctionner sous un système d’exploitation Linux. Cependant, il existe des cas où l’exécution d’un pod sous un système d’exploitation Windows est souhaitée, par exemple si l’application ou une partie spécifique de celle-ci requiert des fonctionnalités spécifiques à Windows. Pour ce faire, vous pouvez changer le système d’exploitation dans le champ .spec.os.name de la spécification du pod (fichier YAML).

Gestion de pods

Bien qu’il soit possible de créer des pods manuellement, la complexité croissante des applications et des charges de travail rend souvent cette solution peu pratique. Les contrôleurs Kubernetes offrent un niveau d’abstraction basé sur une configuration déclarative. Il existe différents types de contrôleurs :

• Kubernetes Deployment
• Kubernetes StatefulSet
• Kubernetes DaemonSet

Les contrôleurs de déploiement surveillent en permanence l’état du cluster. Cela permet des actions automatisées telles que l’évolutivité, la mise à jour et la maintenance des applications. Des ensembles de réplicas (ReplicaSets) assurent l’exécution d’un nombre constant de pods identiques. Les contrôleurs StatefulSet sont essentiels pour les applications gourmandes en données, car ils garantissent des identités réseau stables pour les pods.

Pod Templates

Un pod template est une partie de la configuration d’un contrôleur qui décrit les propriétés souhaitées d’un Kubernetes pod. Celles-ci comprennent les conteneurs, l’image Docker, les variables d’environnement, les exigences en termes de ressources et plus encore. Le contrôleur utilise le pod template pour déployer ou mettre à jour les pods. Par exemple, lors d’un déploiement, il crée de nouveaux pods si un scaling (évolutivité) est nécessaire, ou met à jour les pods existants lors de Rolling Updates (mises à jour progressives automatisées).

apiVersion: batch/v1
kind: Job
metadata:
    name: new-job
spec:
    template:
        metadata:
            name: pod
        spec:
            containers:
            - name: container
                image: ubuntu:latest
                command: ["echo", "Hello from Kubernetes"]
    backoffLimit: 3

Dans l’exemple ci-dessus, nous configurons un job nommé new-job. Le pod template crée un pod unique avec un conteneur qui utilise l’image Ubuntu et exécute la commande echo "Hello from Kubernetes". En cas d’erreur, le job n’aura pas droit à plus de trois tentatives étant donné qu’une backoffLimit a été fixée.

Mise à jour de Kubernetes pods

Kubernetes propose plusieurs méthodes pour mettre à jour les ressources. Les deux plus utilisées sont patch et replace.

La méthode patch sert à effectuer des mises à jour ciblées et partielles d’une ressource, sans remplacer sa définition complète. Cette opération se fait en fournissant un patch qui ne contient que les champs à modifier. Cela permet de mettre à jour des parties spécifiques d’une ressource tout en laissant les autres intactes. Cette méthode efficace permet d’apporter un minimum de modifications à une ressource, en particulier lorsque seuls certains champs requièrent une mise à jour.

En revanche, la méthode replace remplace tous les champs de la ressource par les champs correspondants, dans la nouvelle définition. Elle est utilisée lorsqu’une mise à jour complète est nécessaire ou lorsque des modifications structurelles fondamentales sont apportées à la ressource.

Certaines métadonnées et certains champs dans les définitions YAML de ressources Kubernetes sont immuables. Il s’agit notamment de :

• apiVersion et kind : ces métadonnées définissent le type et la version de la ressource et ne doivent normalement pas être modifiées.
• metadata.name et metadata.namespace : le nom et l’espace de nom (namespace) d’une ressource sont généralement invariables, afin de garantir l’identification univoque de la ressource.
• metadata.creationTimestamp : la date de création d’une ressource est immuable et indique quand la ressource a été créée.

Partage de ressources

Les pods peuvent utiliser des volumes pour partager des données entre des conteneurs au sein d’un même pod. Un volume est un système de fichiers ou un répertoire partagé par un ou plusieurs conteneurs dans le pod. Les volumes sont des mécanismes efficaces pour stocker des données qui dépassent le cycle de vie d’un seul conteneur.

Chaque Kubernetes pod a sa propre adresse IP qui est unique au sein du réseau du cluster. Cette adresse IP permet une communication directe entre les pods. Si plusieurs conteneurs s’exécutent dans un pod, ils peuvent communiquer entre eux via localhost et différents ports. Cela facilite l’interaction entre les différentes parties d’une application dans le même pod.

Privileged Modus

Lorsqu’un conteneur est exécuté en Privileged Modus (mode privilégié), il dispose de droits étendus et peut accéder à des ressources système qui ne sont normalement pas disponibles dans un conteneur isolé par défaut. Dans Kubernetes, le Privileged Modus est activé en définissant l’option securityContext.privileged dans les spécifications du conteneur.

Il est toutefois important de noter que l’utilisation du Privileged Modus s’accompagne de risques de sécurité importants. En raison des droits étendus, un conteneur compromis ou une application malveillante sur le système hôte pourrait, en effet, causer de graves problèmes de sécurité. Par conséquent, il convient de n’utiliser le Privileged Modus que lorsque cela est absolument nécessaire et que les risques pour la sécurité ont été évalués avec soin.

Static Pods

Les Static Pods (pods statiques) dans Kubernetes sont des pods qui ne sont pas surveillés ou gérés par le niveau de contrôle central du cluster. Contrairement aux pods standards qui dépendent des contrôleurs Kubernetes, les pods statiques sont directement initiés par un nœud. Ces pods sont liés à un nœud spécifique et leurs définitions sont placées sur le nœud lui-même, généralement dans un répertoire comme /etc/kubernetes/manifests/. Kubelet sur le nœud surveille et démarre le pod statique, en effectuant automatiquement des redémarrages si le pod tombe en panne.

Contrairement aux pods standards, les Static Pods ne sont pas contrôlés par l’API Kubernetes et sont invisibles pour le niveau de contrôle central du cluster. Les Static Pods offrent une méthode simple pour déployer des applications ou des services sur un nœud sans passer par un cluster Kubernetes central. En revanche, ils ne disposent pas de toutes les fonctionnalités des pods standards qui eux sont gérés par le Kubernetes Controller Manager (gestionnaire du contrôleur).

Sondes de conteneur

Les sondes de conteneur (Container probes) sont des mécanismes dans Kubernetes qui surveillent l’état et la santé d’un conteneur.

Pour effectuer un diagnostic, le Kubelet peut déclencher différentes actions :

• ExecAction (exécutée à l’aide de l’environnement d’exécution du conteneur) : cette action permet à Kubelet d’exécuter une commande à l’intérieur du conteneur. Ceci est très utile notamment pour effectuer des vérifications ou des tests spécifiques à l’utilisateur à l’intérieur du conteneur. Si la commande est activée, le test est considéré comme réussi.
• TCPSocketAction (vérifiée directement par le Kubelet) : cela permet au Kubelet de vérifier l’accessibilité d’un port TCP donné, à l’intérieur du conteneur. Si le port indiqué est ouvert, la vérification est considérée comme réussie.
• HTTPGetAction (vérifiée directement par Kubelet) : avec cette action, Kubelet effectue une requête HTTP-GET sur un chemin et un port spécifiques au sein du conteneur. Cette action est souvent utilisée pour les points de terminaison HTTP afin de s’assurer qu’une application répond dûment aux requêtes. Si la requête déclenche un code d’état 2xx, la sonde est considérée comme réussie.