Objets avancés de Kubernetes

Namespaces

Dans Kubernetes, un namespace est une méthode utilisée pour partitionner une instance de cluster Kubernetes en plusieurs espaces virtuels. Cela permet d'isoler les ressources dans un cluster pour les organiser, les sécuriser et les gérer de manière plus efficace. Les namespaces agissent comme un conteneur logique, dans lequel les ressources telles que les pods, services, secrets, et autres objets Kubernetes peuvent être isolés les uns des autres.

Objectifs et utilité des namespaces

-> Isolation des ressources

Les namespaces permettent de séparer les ressources utilisées par différents projets ou équipes au sein d'un même cluster.

-> Gestion des ressources partagées

Dans de grands environnements, où plusieurs équipes travaillent sur le même cluster, les namespaces permettent de séparer les environnements de développement, de test, et de production.

-> Gestion des permissions

En utilisant des Role-Based Access Control (RBAC), vous pouvez définir des permissions spécifiques par namespace, permettant à une équipe d'accéder uniquement à ses propres ressources.

-> Limitation des ressources

Vous pouvez limiter les ressources allouées à chaque namespace (comme la mémoire et le CPU) via des quotas, garantissant ainsi que les équipes ne consomment pas trop de ressources du cluster.

Exemples de namespaces par défaut

Kubernetes fournit certains namespaces par défaut :

-> default

Il s'agit du namespace utilisé si aucun namespace spécifique n'est précisé lors de la création d'un objet. Il est utilisé pour les ressources "non isolées".

-> kube-system

Ce namespace contient les composants du système Kubernetes qui sont essentiels au fonctionnement du cluster (comme l'API Server, le Scheduler, etc.).

-> kube-public

Ce namespace est accessible en lecture pour tous les utilisateurs, y compris ceux qui ne sont pas authentifiés. Il est souvent utilisé pour stocker des informations publiques.

-> kube-node-lease

Utilisé pour la gestion des leases (baux) des nœuds, qui est une fonctionnalité essentielle pour le contrôle de la santé et la disponibilité des nœuds.

Exemple de création de namespace personnalisé

Voici un exemple simple de création d'un namespace personnalisé avec kubectl :

En pratique

-> Commencez par réinitialiser votre cluster en mono noeud

minikube stop
minikube delete
minikube start --driver=virtualbox

-> Redéployez redis

kubectl apply -f redis-service.yaml -f redis-deployment.yaml

Quand on récupère la liste des pods, on récupère les pods présents dans le namespace default.

kubectl get pods --all-namespaces
# NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
# default       redis-94997cf6f-54plv              1/1     Running   0             24s
# kube-system   coredns-6f6b679f8f-6lw65           1/1     Running   0             74s
# kube-system   etcd-minikube                      1/1     Running   0             81s
# kube-system   kube-apiserver-minikube            1/1     Running   0             81s
# kube-system   kube-controller-manager-minikube   1/1     Running   0             79s
# kube-system   kube-proxy-mtn65                   1/1     Running   0             74s
# kube-system   kube-scheduler-minikube            1/1     Running   0             79s
# kube-system   storage-provisioner                1/1     Running   1 (44s ago)   78s

-> Créez un namespace custom nommé test

kubectl create ns test
# namespace/test created
kubectl get ns
# NAME              STATUS   AGE
# default           Active   9h
# kube-node-lease   Active   9h
# kube-public       Active   9h
# kube-system       Active   9h
# test              Active   14m

-> Redéployez redis sur ce namespace

kubectl apply -f redis-pod.yaml -n test
# pod/redis created

-> Lister à nouveau les pods

kubectl get pods 
# NAME                    READY   STATUS    RESTARTS   AGE
# redis-94997cf6f-54plv   1/1     Running   0          20m

Le pod créé précédemment n'apparaît pas parce que le namespace default est utilisé implicitement. Pour le visualiser il convient de spécifier le namespace

kubectl get pods -n test
# NAME    READY   STATUS    RESTARTS   AGE
# redis   1/1     Running   0          8m19s
kubectl get pods -A
# NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
# default       redis-94997cf6f-h5bqq              1/1     Running   0             10m
# kube-system   coredns-6f6b679f8f-m2pxg           1/1     Running   0             10m
# kube-system   etcd-minikube                      1/1     Running   0             10m
# kube-system   kube-apiserver-minikube            1/1     Running   0             10m
# kube-system   kube-controller-manager-minikube   1/1     Running   0             10m
# kube-system   kube-proxy-6h9hs                   1/1     Running   0             10m
# kube-system   kube-scheduler-minikube            1/1     Running   0             10m
# kube-system   storage-provisioner                1/1     Running   1 (10m ago)   10m
# test          redis                              1/1     Running   0             8m43s

-> Il est cependant possible de changer le contexte par défaut, de lui donner le namespace test précédemment créé. Cela peut se faire en changeant la configuration de kubectl ou plus simplement via la commande suivante :

kubectl config set-context --current --namespace=test

Une autre solution consiste à utiliser un outil dédié tel que https://github.com/ahmetb/kubectx

kubens

-> Supprimez maintenant le namespace

kubectl delete ns test

La suppression est un peu lente, le temps de supprimer les objets du namespace. Ces derniers sont protégés par des finalizers qui sont des controllers s'assurant de la suppression des objets avant la suppression du namespace.

Pour le constater, recréez à nouveau le namespace et éditez sa configuration

kubectl create ns test
kubectl edit ns test
# apiVersion: v1
# kind: Namespace
# metadata:
#   creationTimestamp: "2024-10-13T07:30:17Z"
#   labels:
#     kubernetes.io/metadata.name: test
#   name: test
#   resourceVersion: "2369"
#   uid: 8d9ec1cb-5260-4049-b906-13cc1e222ac3
# spec:
#   finalizers:
#   - kubernetes
# status:
#   phase: Active

Replicasets

Un ReplicaSet est un objet qui assure qu’un nombre spécifié de copies d’un pod (appelées réplicats) s'exécutent en permanence. Il surveille l'état des pods, et si certains d'entre eux meurent ou sont supprimés, il les remplace automatiquement pour maintenir le nombre défini de réplicats.

L'objectif principal d'un ReplicaSet est de s'assurer que le nombre de pods actifs correspond au nombre souhaité, appelé replicas. Si un pod échoue, le ReplicaSet crée un nouveau pod pour le remplacer. Si le nombre de pods est supérieur au nombre de réplicats spécifié, il en supprimera un ou plusieurs pour revenir à l'état désiré.

Fonctionnement

kubectl get replicasets.apps
# NAME              DESIRED   CURRENT   READY   AGE
# redis-94997cf6f   1         1         1       44m

Si on compare aux pods précédemment déployés on constate que les replicasets ont été générés avec des noms "randoms".

kubectl get deployments.apps
# NAME    READY   UP-TO-DATE   AVAILABLE   AGE
# redis   1/1     1            1           50m

Pour chaque pod il existe donc un replicatset.

On peut le décrire, comme on le ferait pour chaque autre objet du cluster, mais l'intérêt reste limité

kubectl describe rs redis-94997cf6f
# Name:           redis-94997cf6f
# Namespace:      default
# Selector:       app=redis,pod-template-hash=94997cf6f,tier=backend
# Labels:         app=redis
#                 pod-template-hash=94997cf6f
#                 role=master
#                 tier=backend
# Annotations:    deployment.kubernetes.io/desired-replicas: 1
#                 deployment.kubernetes.io/max-replicas: 2
#                 deployment.kubernetes.io/revision: 1
# Controlled By:  Deployment/redis
# Replicas:       1 current / 1 desired
# Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
# Pod Template:
#   Labels:  app=redis
#            pod-template-hash=94997cf6f
#            role=master
#            tier=backend
#   Containers:
#    master:
#     Image:         redis
#     Port:          6379/TCP
#     Host Port:     0/TCP
#     Environment:   <none>
#     Mounts:        <none>
#   Volumes:         <none>
#   Node-Selectors:  <none>
#   Tolerations:     <none>
# Events:            <none>

Daemonsets

Un DaemonSet est une ressource Kubernetes qui permet de garantir que chaque nœud (ou certains nœuds) du cluster exécute une instance spécifique d'un pod. En d'autres termes, un DaemonSet veille à ce qu'un pod soit automatiquement déployé sur tous les nœuds ou sur un sous-ensemble de nœuds répondant à certains critères, comme les labels des nœuds.

Fonctionnalité principale

• Le DaemonSet veille à ce que chaque nœud ait exactement une instance d'un pod, au lieu de répliquer un pod sur un nombre fixe de nœuds comme le ferait un ReplicaSet ou un Deployment.
• Lorsqu'un nouveau nœud est ajouté au cluster, Kubernetes va automatiquement y déployer le pod du DaemonSet.
• Inversement, si un nœud est supprimé, les pods du DaemonSet qui y étaient déployés seront également supprimés.

Utilisations typiques

-> Outils de monitoring

Pour collecter des métriques à partir de chaque nœud (exemple : Prometheus Node Exporter).

-> Outils de logging

Pour collecter les journaux de tous les nœuds (exemple : Fluentd, Logstash).

-> Outils de mise en réseau

Pour gérer la configuration réseau ou fournir des fonctionnalités comme un proxy (exemple : CNI plugins, Calico).

Exécution sélective

Si vous souhaitez déployer des pods sur un sous-ensemble spécifique de nœuds, vous pouvez utiliser des labels et des selectors dans la définition du DaemonSet. Cela permet de cibler certains nœuds plutôt que de déployer des pods sur tous les nœuds du cluster.

Exemple

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Mécanique du daemonset

Mise en pratique

-> Ajoutez un noeud au cluster appliquez le daemonset

kubectl apply -f daemonset.yaml
# daemonset.apps/nginx-daemonset created

-> Vérifiez le bon fonctionnement

kubectl get ds
# NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
# nginx-daemonset   2         2         1       2            1           <none>          5m59s

-> Ajoutez un noeud au cluster

minikube node add

--> Un nouveau pod est alors créé sur le nouveau noeud

kubectl get pods -o wide 
# NAME                    READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
# nginx-daemonset-6rxh5   1/1     Running   0          6m17s   10.244.0.3   minikube       <none>           <none>
# nginx-daemonset-lns6m   1/1     Running   0          6m17s   10.244.1.2   minikube-m02   <none>           <none>
# nginx-daemonset-qpscg   1/1     Running   0          4m5s    10.244.2.2   minikube-m03   <none>           <none>

Port forwarding

Le port forwarding sur Kubernetes est une fonctionnalité qui permet de rediriger le trafic réseau entre votre machine locale (ou une autre source externe) et un pod spécifique dans un cluster Kubernetes. Cela permet d'accéder directement à des applications qui tournent dans un pod, sans avoir besoin de configurer des services exposant ces applications ou d'utiliser un LoadBalancer ou un Ingress.

Voici une explication détaillée de son fonctionnement et de son utilité :

Principe de base

Le port forwarding redirige les requêtes envoyées vers un port local (de votre machine par exemple) vers un port d'un pod particulier dans Kubernetes. Cela permet, par exemple, d'accéder à une application web qui tourne à l'intérieur d'un pod via un navigateur ou de se connecter à une base de données qui tourne dans un pod via un client local.

Cas d'usage

• Développement et débogage : Vous pouvez utiliser le port forwarding pour tester et déboguer des applications exécutées dans un cluster Kubernetes sans avoir besoin de configurer un service ou un Ingress. C'est très pratique pour des tests rapides ou des tâches d'administration.

• Accès direct à un pod : Si une application n'est pas exposée publiquement (par exemple, elle est uniquement accessible au sein du cluster), vous pouvez toujours y accéder à partir de votre machine locale en redirigeant le port.

kubectl port-forward nginx-daemonset-6rxh5 8000:80
# Forwarding from 127.0.0.1:8000 -> 80
# Forwarding from [::1]:8000 -> 80

Nginx est alors accessible sur http://localhost:8000/

Statefulset

Un StatefulSet est un type de ressource dans Kubernetes qui est utilisé pour déployer et gérer des applications avec un état persistant. Contrairement à un Deployment, qui gère des applications stateless (sans état), le StatefulSet est conçu pour les applications où chaque instance (ou Pod) doit être identifiée de manière unique et conserver des données spécifiques.

Voici quelques points essentiels pour comprendre le StatefulSet :

Identité Stable

Chaque Pod dans un StatefulSet possède une identité unique et stable, même après un redémarrage. Cela signifie qu'un Pod aura toujours le même nom et le même identifiant réseau (DNS) tout au long de son cycle de vie.

Par exemple, si vous avez un StatefulSet nommé app avec 3 répliques, les Pods seront nommés de manière prévisible comme suit :

• app-0
• app-1
• app-2

Ordre de Déploiement et de Mise à Jour

Les Pods dans un StatefulSet sont créés et mis à jour de manière ordonnée. Kubernetes déploie ou supprime les Pods l'un après l'autre, dans l'ordre numérique. Cela est particulièrement important pour des bases de données distribuées ou des systèmes où un ordre précis de démarrage ou d'arrêt est nécessaire.

• Lorsque vous redémarrez un StatefulSet, les Pods sont arrêtés dans l'ordre inverse de leur création, puis recréés dans l'ordre correct.

Stockage Persistant

Les StatefulSets sont généralement utilisés avec des volumes de stockage persistants (PersistentVolume), garantissant que chaque Pod garde son propre espace de stockage à travers les redémarrages. Chaque Pod dans le StatefulSet peut avoir son propre volume associé, qui ne sera pas partagé avec d'autres Pods, garantissant l'isolation des données.

Cela est crucial pour les bases de données et les services qui nécessitent une persistance des données locales sur chaque instance.

Cas d’utilisation typiques

Voici quelques exemples d’applications qui tirent parti des StatefulSets :

• Bases de données distribuées : Cassandra, MongoDB, etc.
• Systèmes de fichiers distribués : HDFS, GlusterFS.
• Services nécessitant un état persistant par instance : Elasticsearch, Kafka.

Différences clés entre StatefulSet et Deployment

• Déploiement ordonné : Les Pods dans un StatefulSet sont créés et supprimés dans un ordre défini.
• Identité stable : Les noms des Pods et leurs adresses IP restent constants au fil du temps, même après des redémarrages.
• Stockage persistant : Chaque Pod dans un StatefulSet est associé à un volume persistant unique.

Exemple

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

-> Pour illustrer déployez le statefulset

kubectl apply -f statefulset.yaml
# statefulset.apps/web created

-> Listez les objets

kubectl get sts
# NAME   READY   AGE
# web    1/1     56s

-> Le storage a été créé, un volume claim associé et un volume créé

kubectl get pvc
# NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
# www-web-0   Bound    pvc-74d4dae8-1002-47ac-9656-ebc17c68a732   1Gi        RWO            standard       <unset>                 2m16s

kubectl get pv
# NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
# pvc-74d4dae8-1002-47ac-9656-ebc17c68a732   1Gi        RWO            Delete           Bound    default/www-web-0   standard       <unset>                          3m38s

Exec

Comme avec docker il est possible d'exécuter des commandes dans un container

kubectl exec -it web-0 -- bash

NOTE

-- précise que la commande est à exécuter à l'intérieur du pod

-> Observez où le volume créé précemment est monté dans le pod

kubectl describe po web-0
#    Mounts:
#      /usr/share/nginx/html from www (rw)
#      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-fkk87 (ro)

-> Dans le container modifiez le fichier index.html de /usr/share/nginx/html/index.html

echo "Hello World" > /usr/share/nginx/html/index.html

-> Supprimez ensuite le pod

kubectl delete pods web-0
# pod "web-0" deleted

-> Observez à nouveau les pods disponibles

kubectl get pods
# NAME                    READY   STATUS    RESTARTS   AGE
# nginx-daemonset-6rxh5   1/1     Running   0          29m
# nginx-daemonset-lns6m   1/1     Running   0          29m
# nginx-daemonset-qpscg   1/1     Running   0          27m
# web-0                   1/1     Running   0          35s

-> Retournez dans le container et constatez que vos modifications sont toujours présentes

kubectl exec -it web-0 -- bash
cat /usr/share/nginx/html/index.html
# hello world

Jobs

Un job Kubernetes est une ressource Kubernetes utilisée pour exécuter des tâches ou des processus éphémères, c'est-à-dire des processus qui ne sont pas censés s'exécuter en continu. Contrairement à des Pods ou des Deployments, qui sont souvent utilisés pour des services en cours d'exécution (comme des serveurs web), les Jobs sont conçus pour accomplir une tâche spécifique et se terminer une fois cette tâche effectuée.

Fonctionnement d'un Job Kubernetes

• Un Job crée un ou plusieurs Pods pour exécuter une tâche donnée.
• Lorsque la tâche est terminée avec succès, les pods sont détruits, et le Job est considéré comme accompli.
• Un Job assure également que la tâche spécifiée est exécutée un certain nombre de fois, selon les spécifications de répétition ou de parallélisme indiquées.

Types de Jobs

Kubernetes offre trois types de Jobs selon le comportement souhaité :

• Job simple : Exécute une tâche une seule fois jusqu'à son achèvement.
• Job avec parallélisme : Exécute plusieurs pods en parallèle, chaque pod accomplissant une partie de la tâche.
• Job avec tentatives multiples : Réexécute le Job jusqu'à ce qu'il réussisse, selon un nombre de tentatives configuré.

Cas d'utilisation

Les Jobs sont souvent utilisés pour des tâches qui ne nécessitent pas une exécution continue, comme :

• Des tâches de traitement par lot (batch processing).
• Des opérations de maintenance ou de migration ponctuelles (mises à jour de base de données, par exemple).
• Des tests ponctuels ou des scripts de calcul.

Exemple

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example
        image: busybox:latest
        command: ["sh", "-c", "echo Hello, Kubernetes! && sleep 10"]
      restartPolicy: Never
  backoffLimit: 4

• restartPolicy

Cela spécifie que le conteneur ne sera jamais redémarré en cas d'échec ou après l'exécution normale de la tâche. Cela fait sens pour les Jobs, car ils ne sont pas destinés à être exécutés en continu.

• backoffLimit

Ce paramètre indique combien de fois Kubernetes essaiera de redémarrer le Job en cas d'échec avant de l'abandonner. Ici, Kubernetes tentera de redémarrer le Job jusqu'à 4 fois en cas d'échec

-> Pour illustrer, déployez le job

kubectl apply -f job.yaml
# job.batch/example-job created

-> Vérifiez sa bonne exécution

kubectl get pods 
# NAME                    READY   STATUS      RESTARTS   AGE
# example-job-vp5pp       0/1     Completed   0          41s
kubectl logs example-job-vp5pp
# Hello, Kubernetes!

Le job a été exécuté et est passé en statut completed

-> Notez que les jobs peuvent être listés de la même manière que tous les autres objets du cluster

kubectl get job
# NAME          STATUS     COMPLETIONS   DURATION   AGE
# example-job   Complete   1/1           16s        3m5s

-> Ou encore décrits pour plus d'informations

kubectl describe job example-job
# Name:             example-job
# Namespace:        default
# Selector:         batch.kubernetes.io/controller-uid=71570332-773f-46d8-a030-e186901e4e6f
# Labels:           batch.kubernetes.io/controller-uid=71570332-773f-46d8-a030-e186901e4e6f
#                   batch.kubernetes.io/job-name=example-job
#                   controller-uid=71570332-773f-46d8-a030-e186901e4e6f
#                   job-name=example-job
# Annotations:      <none>
# Parallelism:      1
# Completions:      1
# Completion Mode:  NonIndexed
# Suspend:          false
# Backoff Limit:    4
# Start Time:       Sun, 13 Oct 2024 11:34:23 +0200
# Completed At:     Sun, 13 Oct 2024 11:34:39 +0200
# Duration:         16s
# Pods Statuses:    0 Active (0 Ready) / 1 Succeeded / 0 Failed
# Pod Template:
#   Labels:  batch.kubernetes.io/controller-uid=71570332-773f-46d8-a030-e186901e4e6f
#            batch.kubernetes.io/job-name=example-job
#            controller-uid=71570332-773f-46d8-a030-e186901e4e6f
#            job-name=example-job
#   Containers:
#    example:
#     Image:      busybox:latest
#     Port:       <none>
#     Host Port:  <none>
#     Command:
#       sh
#       -c
#       echo Hello, Kubernetes! && sleep 10
#     Environment:   <none>
#     Mounts:        <none>
#   Volumes:         <none>
#   Node-Selectors:  <none>
#   Tolerations:     <none>
# Events:
#   Type    Reason            Age    From            Message
#   ----    ------            ----   ----            -------
#   Normal  SuccessfulCreate  4m24s  job-controller  Created pod: example-job-vp5pp
#   Normal  Completed         4m8s   job-controller  Job completed

CronJobs

Les CronJobs sont des tâches planifiées qui permettent d'exécuter des travaux (jobs) de manière périodique à des moments spécifiques. Ils sont similaires à la commande cron dans Linux, mais ils sont gérés et exécutés au sein d'un cluster Kubernetes.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-cronjob
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: example
            image: busybox:latest
            command: ["sh", "-c", "echo Hello, Kubernetes! && sleep 10"]
          restartPolicy: Never
      backoffLimit: 4

Ils sont identiques aux jobs mais rajoutent une ligne schedule qui décrit la fréquence d'exécution

TIP

*/5 * * * *
|   | | | |
|   | | | └── Jour de la semaine (n'importe quel jour)
|   | | └──── Mois (n'importe quel mois)
|   | └────── Jour du mois (n'importe quel jour)
|   └──────── Heure (n'importe quelle heure)
└──────────── Toutes les 5 minutes

ConfigMap

Un ConfigMap est un objet qui permet de stocker des données de configuration sous forme de paires clé-valeur. Ces données peuvent être utilisées par des pods ou d'autres ressources Kubernetes pour personnaliser le comportement des applications sans qu'il soit nécessaire de modifier l'image du conteneur.

À quoi sert un ConfigMap ?

Un ConfigMap permet d'externaliser les données de configuration des applications, facilitant ainsi la gestion des configurations de manière plus flexible. Par exemple, si une application nécessite un fichier de configuration ou certaines variables d'environnement spécifiques, le ConfigMap permet de les définir et de les injecter dans le pod à son lancement.

Principales utilisations d'un ConfigMap

-> Variables d'environnement

Injecter des configurations sous forme de variables d'environnement dans les pods.

-> Fichiers de configuration

Injecter des données de configuration sous forme de fichiers montés dans le système de fichiers du conteneur.

-> Lignes de commande

Passer des options ou des configurations directement dans les arguments de commande du conteneur.

Exemple

Considérant le ConfigMap suivant

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  my-config-key: "This is the config value"

Et le pod suivant

apiVersion: v1
kind: Pod
metadata:
  name: pod-using-configmap
spec:
  containers:
  - name: example-container
    image: busybox:latest
    command: ["sh", "-c", "echo $(MY_CONFIG_KEY) && sleep 3600"]
    env:
    - name: MY_CONFIG_KEY
      valueFrom:
        configMapKeyRef:
          name: example-configmap
          key: my-config-key
  restartPolicy: Never

la variable d'environnement MY_CONFIG_KEY prendra la valeur définie dans le ConfigMap nommé exemple-configmap sur la clé my-config-key

-> Pour l'éprouvez appliquez le configmap

kubectl apply -f configmap.yaml
# configmap/example-configmap created

-> Vérifiez son bon fonctionnement

kubectl get cm
# NAME                DATA   AGE
# example-configmap   1      53s
# kube-root-ca.crt    1      71m
kubectl describe cm example-configmap
# Name:         example-configmap
# Namespace:    default
# Labels:       <none>
# Annotations:  <none>
# 
# Data
# ====
# my-config-key:
# ----
# This is the config value
# 
# 
# BinaryData
# ====
# 
# Events:  <none>

-> Déployez alors un pod utilisant le configmap

kubectl apply -f pod-using-cm.yaml
# pod/pod-using-configmap created

-> Il utilise bien la variable définie

kubectl logs pod-using-configmap
# This is the config value

Liveness Probe

Le Liveness Probe (ou son terme français, « sonde de vivacité ») est une fonctionnalité clé dans Kubernetes, utilisée pour déterminer si un conteneur fonctionne correctement. Si un conteneur ne répond plus ou se trouve dans un état bloqué, il ne pourra plus servir les requêtes correctement. Dans ce cas, Kubernetes utilise la sonde de vivacité pour détecter ce dysfonctionnement et redémarrer automatiquement le conteneur défaillant afin de garantir une meilleure disponibilité de l'application.

Fonctionnement du Liveness Probe

Le Liveness Probe vérifie la santé d’un conteneur en effectuant l'une des trois actions suivantes :

HTTP Request (requête HTTP) : Kubernetes effectue une requête HTTP vers un point de terminaison défini dans le conteneur. Si le conteneur renvoie une réponse avec un code d'état HTTP compris entre 200 et 399, Kubernetes considère que le conteneur est vivant et en bonne santé. Si la réponse est autre (comme 500 ou aucune réponse), Kubernetes déclenche un redémarrage du conteneur.

Exemple de configuration d’une sonde HTTP dans un fichier de manifeste YAML

---
apiVersion: v1
kind: Pod
metadata:
  name: http-liveness-pod
spec:
  containers:
    - name: liveness-test
      image: nginx:latest
      ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
        timeoutSeconds: 1
        failureThreshold: 3
        successThreshold: 1

-> Appliquez le manifeste

kubectl apply -f liveness-pod.yaml

-> Supprimez le fichier index.html au sein du container

kubectl exec -it http-liveness-pod -- rm /usr/share/nginx/html/index.html
kubectl exec -it http-liveness-pod -- curl -v http://localhost

-> Vérifiez les pods

kubectl get pods
# NAME                READY   STATUS    RESTARTS     AGE
# http-liveness-pod   1/1     Running   1 (4s ago)   55s

# Events:
#   Type     Reason     Age                    From               Message
#   ----     ------     ----                   ----               -------
#   Normal   Scheduled  6m26s                  default-scheduler  Successfully assigned default/liveness-pod to minikube
#   Normal   Pulled     6m17s                  kubelet            Successfully pulled image "nginx:latest" in 8.014s (8.014s including waiting). Image size: 191670478 bytes.
#   Normal   Pulling    5m35s (x2 over 6m25s)  kubelet            Pulling image "nginx:latest"
#   Warning  Unhealthy  5m35s (x3 over 5m45s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 403
#   Normal   Killing    5m35s                  kubelet            Container liveness-test failed liveness probe, will be restarted
#   Normal   Created    5m34s (x2 over 6m17s)  kubelet            Created container liveness-test
#   Normal   Started    5m34s (x2 over 6m17s)  kubelet            Started container liveness-test
#   Normal   Pulled     5m34s                  kubelet            Successfully pulled image "nginx:latest" in 992ms (992ms including waiting). Image size: 191670478 bytes.

-> Décrivez le pod pour voir ce qu'il s'est passé

Liveness Probe avec un socket TCP

apiVersion: v1
kind: Pod
metadata:
  name: tcp-liveness-pod
spec:
  containers:
  - name: tcp-liveness-container
    image: k8s.gcr.io/liveness
    ports:
    - containerPort: 8080
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 3 
      periodSeconds: 1
      timeoutSeconds: 1
      failureThreshold: 3
      successThreshold: 1