Qu’est-ce qu’un Ku­ber­netes pod ?

Un Ku­ber­netes Pod peut contenir un ou plusieurs con­te­neurs qui sont étroi­te­ment liés entre eux et partagent des res­sources. Ils servent ainsi d‘en­vi­ron­ne­ment coordonné pour les ap­pli­ca­tions.

Ku­ber­netes pod

Les pods sont les unités de dé­ploie­ment de base dans Ku­ber­netes et com­pren­nent un ou plusieurs con­te­neurs in­ter­con­nec­tés. Un pod partage le même espace réseau, la même mémoire et d’autres res­sources et re­pré­sente ainsi un re­grou­pe­ment logique de con­te­neurs. Les con­te­neurs au sein d’un Ku­ber­netes pod in­te­ra­gis­sent étroi­te­ment et com­mu­ni­quent 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 ap­pli­ca­tion ou un micro-service doit fonc­tion­ner dans un en­vi­ron­ne­ment isolé, sans avoir besoin de partager les res­sources et le réseau avec d’autres con­te­neurs. Ce type de pod est certes la forme la plus simple sous Ku­ber­netes, mais il offre les avantages de l’or­ches­tra­tion, de l’évo­lu­ti­vité (scaling) et de la gestion.

Pods avec plusieurs con­te­neurs

Un pod exécutant plusieurs con­te­neurs héberge plus d’un conteneur au sein d’un même pod. Ces con­te­neurs in­te­ra­gis­sent et partagent le même espace réseau et les mêmes res­sources. Ce type de pod est souvent utilisé lorsque des con­te­neurs sont étroi­te­ment liés entre eux et rem­plis­sent une tâche ou une fonction commune. Par exemple, un conteneur d’ap­pli­ca­tion principal et un conteneur side-car pour la connexion ou la sur­veil­lance pour­raient être exécutés dans un seul Ku­ber­netes pod. Cela permet une coor­di­na­tion et une com­mu­ni­ca­tion plus étroites entre les con­te­neurs, tout en les traitant comme une entité unique au sein du cluster Ku­ber­netes.

Création d’un Ku­ber­netes Pod

Pour créer un Ku­ber­netes pod, vous avez besoin d’un fichier YAML qui décrit la spé­ci­fi­ca­tion 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

Uti­li­sa­tion de Ku­ber­netes Pods

L’uti­li­sa­tion de niveaux d’abs­trac­tion su­pé­rieurs tels que De­ploy­ments ou Sta­te­ful­Sets est re­com­man­dée pour gérer les pods dans un en­vi­ron­ne­ment de pro­duc­tion. Ces con­trô­leurs se chargent de définir l’état souhaité de l’ap­pli­ca­tion et de s’assurer qu’il cor­res­pond bien à l’état réel. Ainsi, l’évo­lu­ti­vité, la mise à jour pro­gres­sive et la res­tau­ra­tion au­to­ma­tique des pods sont mises en œuvre.

Lors de la création d’un pod, que ce soit di­rec­te­ment par l’ad­mi­nis­tra­teur ou in­di­rec­te­ment via un con­trô­leur, le nouveau pod est planifié sur un nœud spé­ci­fique 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é ma­nuel­le­ment, manque de res­sources ou d’autres problèmes exigent l’éva­cua­tion 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 dis­po­nible afin de garantir une exécution continue, sans in­ter­rup­tion.

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 clai­re­ment iden­ti­fiable au sein du cluster Ku­ber­netes. Les éti­quettes DNS ne doivent pas dépasser 253 ca­rac­tères, ne peuvent contenir que des ca­rac­tères al­pha­nu­mé­riques et des tirets, et doivent commencer et finir par un caractère al­pha­nu­mé­rique.

Pod OS

Les Ku­ber­netes pods sont gé­né­ra­le­ment con­fi­gu­rés pour fonc­tion­ner sous un système d’ex­ploi­ta­tion Linux. Cependant, il existe des cas où l’exécution d’un pod sous un système d’ex­ploi­ta­tion Windows est souhaitée, par exemple si l’ap­pli­ca­tion ou une partie spé­ci­fique de celle-ci requiert des fonc­tion­na­li­tés spé­ci­fiques à Windows. Pour ce faire, vous pouvez changer le système d’ex­ploi­ta­tion dans le champ .spec.os.name de la spé­ci­fi­ca­tion du pod (fichier YAML).

Gestion de pods

Bien qu’il soit possible de créer des pods ma­nuel­le­ment, la com­plexité crois­sante des ap­pli­ca­tions et des charges de travail rend souvent cette solution peu pratique. Les con­trô­leurs Ku­ber­netes offrent un niveau d’abs­trac­tion basé sur une con­fi­gu­ra­tion dé­cla­ra­tive. Il existe dif­fé­rents types de con­trô­leurs :

• Ku­ber­netes De­ploy­ment
• Ku­ber­netes Sta­te­ful­Set
• Ku­ber­netes DaemonSet

Les con­trô­leurs de dé­ploie­ment sur­veil­lent en per­ma­nence l’état du cluster. Cela permet des actions au­to­ma­ti­sées telles que l’évo­lu­ti­vité, la mise à jour et la main­te­nance des ap­pli­ca­tions. Des ensembles de réplicas (Re­pli­ca­Sets) assurent l’exécution d’un nombre constant de pods iden­tiques. Les con­trô­leurs Sta­te­ful­Set sont es­sen­tiels pour les ap­pli­ca­tions gour­mandes en données, car ils ga­ran­tis­sent des identités réseau stables pour les pods.

Pod Templates

Un pod template est une partie de la con­fi­gu­ra­tion d’un con­trô­leur qui décrit les pro­prié­tés sou­hai­tées d’un Ku­ber­netes pod. Celles-ci com­pren­nent les con­te­neurs, l’image Docker, les variables d’en­vi­ron­ne­ment, les exigences en termes de res­sources et plus encore. Le con­trô­leur utilise le pod template pour déployer ou mettre à jour les pods. Par exemple, lors d’un dé­ploie­ment, il crée de nouveaux pods si un scaling (évo­lu­ti­vité) est né­ces­saire, ou met à jour les pods existants lors de Rolling Updates (mises à jour pro­gres­sives au­to­ma­ti­sé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 con­fi­gu­rons 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 ten­ta­tives étant donné qu’une backoffLimit a été fixée.

Mise à jour de Ku­ber­netes pods

Ku­ber­netes propose plusieurs méthodes pour mettre à jour les res­sources. Les deux plus utilisées sont patch et replace.

La méthode patch sert à effectuer des mises à jour ciblées et par­tielles d’une ressource, sans remplacer sa dé­fi­ni­tion complète. Cette opération se fait en four­nis­sant un patch qui ne contient que les champs à modifier. Cela permet de mettre à jour des parties spé­ci­fiques d’une ressource tout en laissant les autres intactes. Cette méthode efficace permet d’apporter un minimum de mo­di­fi­ca­tions à une ressource, en par­ti­cu­lier lorsque seuls certains champs re­quiè­rent une mise à jour.

En revanche, la méthode replace remplace tous les champs de la ressource par les champs cor­res­pon­dants, dans la nouvelle dé­fi­ni­tion. Elle est utilisée lorsqu’une mise à jour complète est né­ces­saire ou lorsque des mo­di­fi­ca­tions struc­tu­relles fon­da­men­tales sont apportées à la ressource.

Certaines mé­ta­don­nées et certains champs dans les dé­fi­ni­tions YAML de res­sources Ku­ber­netes sont immuables. Il s’agit notamment de :

• apiVersion et kind : ces mé­ta­don­nées dé­fi­nis­sent le type et la version de la ressource et ne doivent nor­ma­le­ment pas être modifiées.
• metadata.name et metadata.namespace : le nom et l’espace de nom (namespace) d’une ressource sont gé­né­ra­le­ment in­va­riables, afin de garantir l’iden­ti­fi­ca­tion 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 res­sources

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

Chaque Ku­ber­netes pod a sa propre adresse IP qui est unique au sein du réseau du cluster. Cette adresse IP permet une com­mu­ni­ca­tion directe entre les pods. Si plusieurs con­te­neurs s’exécutent dans un pod, ils peuvent com­mu­ni­quer entre eux via localhost et dif­fé­rents ports. Cela facilite l’in­te­rac­tion entre les dif­fé­rentes parties d’une ap­pli­ca­tion dans le même pod.

Pri­vi­le­ged Modus

Lorsqu’un conteneur est exécuté en Pri­vi­le­ged Modus (mode pri­vi­lé­gié), il dispose de droits étendus et peut accéder à des res­sources système qui ne sont nor­ma­le­ment pas dis­po­nibles dans un conteneur isolé par défaut. Dans Ku­ber­netes, le Pri­vi­le­ged Modus est activé en dé­fi­nis­sant l’option securityContext.privileged dans les spé­ci­fi­ca­tions du conteneur.

Il est toutefois important de noter que l’uti­li­sa­tion du Pri­vi­le­ged Modus s’ac­com­pagne de risques de sécurité im­por­tants. En raison des droits étendus, un conteneur compromis ou une ap­pli­ca­tion mal­veil­lante sur le système hôte pourrait, en effet, causer de graves problèmes de sécurité. Par con­sé­quent, il convient de n’utiliser le Pri­vi­le­ged Modus que lorsque cela est ab­so­lu­ment né­ces­saire et que les risques pour la sécurité ont été évalués avec soin.

Static Pods

Les Static Pods (pods statiques) dans Ku­ber­netes sont des pods qui ne sont pas sur­veil­lés ou gérés par le niveau de contrôle central du cluster. Con­trai­re­ment aux pods standards qui dépendent des con­trô­leurs Ku­ber­netes, les pods statiques sont di­rec­te­ment initiés par un nœud. Ces pods sont liés à un nœud spé­ci­fique et leurs dé­fi­ni­tions sont placées sur le nœud lui-même, gé­né­ra­le­ment dans un ré­per­toire comme /etc/kubernetes/manifests/. Kubelet sur le nœud surveille et démarre le pod statique, en ef­fec­tuant au­to­ma­ti­que­ment des re­dé­mar­rages si le pod tombe en panne.

Con­trai­re­ment aux pods standards, les Static Pods ne sont pas contrôlés par l’API Ku­ber­netes et sont in­vi­sibles pour le niveau de contrôle central du cluster. Les Static Pods offrent une méthode simple pour déployer des ap­pli­ca­tions ou des services sur un nœud sans passer par un cluster Ku­ber­netes central. En revanche, ils ne disposent pas de toutes les fonc­tion­na­li­tés des pods standards qui eux sont gérés par le Ku­ber­netes Con­trol­ler Manager (ges­tion­naire du con­trô­leur).

Sondes de conteneur

Les sondes de conteneur (Container probes) sont des mé­ca­nismes dans Ku­ber­netes qui sur­veil­lent l’état et la santé d’un conteneur.

Pour effectuer un diag­nos­tic, le Kubelet peut dé­clen­cher dif­fé­rentes actions :

• Exe­cAc­tion (exécutée à l’aide de l’en­vi­ron­ne­ment 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é­ri­fi­ca­tions ou des tests spé­ci­fiques à l’uti­li­sa­teur à l’intérieur du conteneur. Si la commande est activée, le test est considéré comme réussi.
• TCP­So­cke­tAc­tion (vérifiée di­rec­te­ment par le Kubelet) : cela permet au Kubelet de vérifier l’ac­ces­si­bi­lité d’un port TCP donné, à l’intérieur du conteneur. Si le port indiqué est ouvert, la vé­ri­fi­ca­tion est con­si­dé­rée comme réussie.
• HTTP­Ge­tAc­tion (vérifiée di­rec­te­ment par Kubelet) : avec cette action, Kubelet effectue une requête HTTP-GET sur un chemin et un port spé­ci­fiques au sein du conteneur. Cette action est souvent utilisée pour les points de ter­mi­nai­son HTTP afin de s’assurer qu’une ap­pli­ca­tion répond dûment aux requêtes. Si la requête déclenche un code d’état 2xx, la sonde est con­si­dé­rée comme réussie.