¶ Présentation
Dans ce nouveau volet, nous allons explorer des apsects encore plus avancés de Kubernetes, toujours au travers du mini-cluster packagé Minikube :
- Comprendre et utiliser les ConfigMaps et Secrets
- Configurer les limites de ressources (CPU et mémoire) pour les conteneurs
- Créer et utiliser des volumes persistants
- Comprendre le cycle de vie complet des pods et leurs états
¶ Prérequis
- Minikube et kubectl installés et configurés (Kubernetes 1)
- Connaissance des déploiements de base (Kubernetes 2)
Il est recommandé de faire un fresh start du cluster en le supprimant :
minikube delete
puis en relançant le cluster minikube :
minikube start
¶ Utilisation des ConfigMaps
¶ Introduction aux ConfigMaps
- Les ConfigMaps permettent de séparer les configurations des images conteneurs
- Ils rendent les déploiements plus portables et plus faciles à maintenir
- Formats supportés : paires clé-valeur, fichiers de configuration
¶ Création d'un ConfigMap en ligne de commande
kubectl create configmap app-config --from-literal=APP_ENV=production --from-literal=APP_DEBUG=false
¶ Création d'un ConfigMap à partir d'un fichier "à plat"
Créez un fichier config.properties:
nano config.properties
avec :
app.env=production
app.debug=false
app.log.level=info
Puis créez depuis ce fichier le ConfigMap appelé... configmap tout simplement
kubectl create configmap app-config-file --from-file=config.properties
¶ Création d'un ConfigMap avec YAML
Changeons de format, passons de clé-valeur à des fichiers.
Créez un fichier nginx-config.yaml :
nano nginx-config.yaml
avec :
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
server {
listen 80;
server_name _;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
index.html: |
<!DOCTYPE html>
<html>
<head>
<title>Kubernetes ConfigMap Example</title>
</head>
<body>
<h1>Hello from Kubernetes ConfigMap!</h1>
</body>
</html>
Nous voyons que ce manifeste définit le contenu de deux fichiers : nginx.conf et index.html.
Appliquez le ConfigMap :
kubectl apply -f nginx-config.yaml
¶ Afficher les ConfigMaps
¶ Lister tous les ConfigMaps dans le namespace courant
kubectl get configmaps
ou encore en forme abrégée :
kubectl get cm
¶ Obtenir les détails d'un ConfigMap spécifique
kubectl describe configmap <nom-du-configmap>
Par exemple
kubectl describe configmap app-config
¶ Utilisation d'un ConfigMap dans un Pod
Créez un fichier nginx-pod-configmap.yaml :
apiVersion: v1
kind: Pod
metadata:
name: nginx-configmap
spec:
containers:
- name: nginx
image: nginx:1.20
ports:
- containerPort: 80
volumeMounts:
- name: nginx-config-volume
mountPath: /etc/nginx/conf.d
- name: nginx-index-volume
mountPath: /usr/share/nginx/html
volumes:
- name: nginx-config-volume
configMap:
name: nginx-config
items:
- key: nginx.conf
path: default.conf
- name: nginx-index-volume
configMap:
name: nginx-config
items:
- key: index.html
path: index.html
Prenez le temps de bien faire le lien entre les éléments déclarés et le fichier précédent :
- le pod
nginx-configmapcontient un containernginxbasé sur l'imagenginx:1.20 - on expose deux volumes de ce conteneur :
nginx-config-volume(relié au répertoire/etc/nginx/conf.ddans le conteneur)nginx-index-volume(relié à/usr/share/nginx/htmldans le conteneur)
- au niveau du pod, on associe chacun de ces deux volumes aux éléments issus de la ConfigMap
nginx-config
Appliquez :
kubectl apply -f nginx-pod-configmap.yaml
et testez en exposant temporairement ce pod :
kubectl port-forward nginx-configmap 8080:80
Depuis le navigateur, accédez à la page http://localhost:8080 :
¶ Utilisation de ConfigMap pour des variables d'environnement
Créez un fichier env-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: env-pod
spec:
containers:
- name: env-container
image: alpine
command: ["sh", "-c", "echo APP_ENV=$APP_ENV && sleep 3600"]
env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV
restartPolicy: Never
Appliquez :
kubectl apply -f env-pod.yaml
et vérifiez :
kubectl logs env-pod
¶ Gestion des Secrets
¶ Introduction aux Secrets
- Les Secrets sont semblables aux ConfigMaps mais conçus pour stocker des données sensibles
- Ils sont encodés en base64 par défaut (mais non chiffrés)
- Types de Secrets : generics, docker-registry, tls
¶ Création d'un Secret à partir de valeurs littérales
kubectl create secret generic db-credentials --from-literal=username=admin --from-literal=password=secretpass
¶ Création d'un Secret à partir de fichiers
Créez des fichiers pour vos informations sensibles :
echo -n "admin" > username.txt
echo -n "secretpass" > password.txt
kubectl create secret generic db-credentials-file --from-file=username=username.txt --from-file=password=password.txt
¶ Création d'un Secret avec YAML
Créez un fichier secret.yaml :
apiVersion: v1
kind: Secret
metadata:
name: api-secrets
type: Opaque
data:
api-key: VGhpc0lzTXlBUElLZXk= # 'ThisIsMyAPIKey' encodé en base64
api-token: VGhpc0lzTXlBUElUb2tlbg== # 'ThisIsMyAPIToken' encodé en base64
Rappel - pour encoder en base64 :
echo -n "ThisIsMyAPIKey" | base64
echo -n "ThisIsMyAPIToken" | base64
Appliquez le Secret :
kubectl apply -f secret.yaml
¶ Utilisation d'un Secret dans un Pod comme variable d'environnement
Créez un fichier secret-env-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: secret-container
image: alpine
command: ["sh", "-c", "echo The API Key is $API_KEY && sleep 3600"]
env:
- name: API_KEY
valueFrom:
secretKeyRef:
name: api-secrets
key: api-key
restartPolicy: Never
Appliquez :
kubectl apply -f secret-env-pod.yaml
et vérifiez :
kubectl logs secret-env-pod
¶ Utilisation d'un Secret avec un volume
Créez maintenant un fichier secret-volume-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: secret-volume-pod
spec:
containers:
- name: secret-container
image: alpine
command: ["sh", "-c", "echo -n 'Contenu de api-key : '; cat /etc/secrets/api-key; echo && sleep 3600"]
volumeMounts:
- name: secret-volume
mountPath: /etc/secrets
readOnly: true
volumes:
- name: secret-volume
secret:
secretName: api-secrets
restartPolicy: Never
Appliquez :
kubectl apply -f secret-volume-pod.yaml
et vérifiez :
kubectl logs secret-volume-pod
¶ Gestion des ressources (CPU et mémoire)
¶ Introduction aux limites de ressources
¶ Pourquoi limiter les ressources ?
Dans un cluster Kubernetes, plusieurs applications partagent les ressources physiques des nœuds. Sans limites appropriées, une application gourmande en ressources pourrait :
- Consommer toutes les ressources disponibles
- Causer des problèmes de performance pour d'autres applications
- Provoquer des évictions (OOMKilled) imprévisibles de pods
- Rendre le cluster instable
La gestion des ressources permet d'optimiser l'utilisation du cluster et d'augmenter sa fiabilité.
¶ Concepts clés : Requests et Limits
Kubernetes utilise deux concepts distincts pour gérer les ressources :
-
Requests (Demandes)
- Quantité de ressources garantie pour un conteneur
- Le scheduler utilise cette valeur pour placer les pods sur des nœuds ayant suffisamment de ressources
- Les pods ne seront pas placés sur un nœud si la somme des requests dépasse les ressources du nœud
- Les requests réservent des ressources même si elles ne sont pas utilisées
-
Limits (Limites)
- Quantité maximale de ressources qu'un conteneur peut utiliser
- Si un conteneur dépasse sa limite de mémoire, il sera terminé (OOMKilled)
- Si un conteneur dépasse sa limite de CPU, il sera limité (throttled) mais pas terminé
¶ Unités de mesure des ressources
- CPU
- Mesurée en "cpu units" ou millicores
- 1000m (millicores) = 1 CPU (un cœur complet)
- 500m = 0.5 CPU = 50% d'un cœur
- 100m = 0.1 CPU = 10% d'un cœur
- Valeur minimale : 1m
- Mesurée en "cpu units" ou millicores
Exemples :
cpu: "500m" # 500 millicores (0.5 CPU)
cpu: "1" # 1 CPU (équivalent à 1000m)
cpu: "1.5" # 1.5 CPU (équivalent à 1500m)
- Mémoire
- Mesurée en bytes
- Peut utiliser des suffixes : K, M, G, T, Ki, Mi, Gi, Ti
- K, M, G, T (base de 1000) : 1K = 1000 bytes
- Ki, Mi, Gi, Ti (base de 1024) : 1Ki = 1024 bytes
Exemples :
memory: "256Mi" # 256 mebibytes
memory: "1Gi" # 1 gibibyte
memory: "512M" # 512 megabytes (à éviter, préférer Mi)
¶ Comportement de la planification (scheduling)
- Avec Request < Limit
- Le conteneur peut utiliser plus que sa request mais jamais plus que sa limit
- Cas idéal pour les applications à charge variable
- Avec Request = Limit
- Allocation fixe, prévisible (QoS Guaranteed)
- Idéal pour les applications critiques
- Avec Request uniquement (sans Limit)
- Le conteneur peut utiliser autant de ressources que disponibles
- Risqué car peut causer des problèmes pour d'autres pods
- Sans Request ni Limit
- Non recommandé en production
- Allocation imprévisible, risque d'éviction
¶ Quality of Service (QoS) Classes
Kubernetes attribue automatiquement une classe QoS à chaque pod, qui détermine sa priorité d'éviction en cas de pression sur les ressources :
- Guaranteed (Garanti)
- Requests = Limits pour tous les conteneurs
- Priorité d'éviction la plus basse (derniers à être évincés)
- Burstable (Variable)
- Au moins une request définie mais pas toutes égales aux limits
- Priorité d'éviction intermédiaire
- BestEffort (Au mieux)
- Aucune request ni limit définie
- Première priorité d'éviction (premiers à être évincés)
¶ Impact sur la facturation (dans les clouds publics)
En environnement cloud, il est important de noter que :
- Les requests sont généralement ce qui est facturé, pas l'utilisation réelle
- Des requests trop élevées peuvent entraîner des coûts inutiles
- Des requests trop basses peuvent causer des problèmes de performance
¶ Bonnes pratiques
- Toujours définir des requests et des limits
- Éviter les pods "BestEffort" en production
- Viser des pods "Guaranteed" pour les applications critiques
- Basez vos valeurs sur des mesures réelles
- Surveillez l'utilisation réelle et ajustez
- Effectuez des tests de charge
- Ratios recommandés (request:limit)
- CPU : 1:2 ou 1:3 (permettre des pics)
- Mémoire : 1:1.25 ou 1:1.5 (être plus conservateur)
¶ Définition des limites de ressources dans un Pod
Créez un fichier resource-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: resource-demo
spec:
containers:
- name: resource-container
image: nginx
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Appliquez :
kubectl apply -f resource-pod.yaml
et vérifiez :
kubectl describe pod resource-demo
¶ Test des limites de mémoire
Nous allons utiliser une image spéciale pour le stress mémoire.
Créez un fichier memory-test-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: memory-test
spec:
containers:
- name: memory-container
image: polinux/stress
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
resources:
limits:
memory: "128Mi"
restartPolicy: Always
Appliquez :
kubectl apply -f memory-test-pod.yaml
Observez les redémarrages :
kubectl get pod memory-test -w
Vérifiez les événements :
kubectl describe pod memory-test
Enfin, supprimons ce pod au comportement désastreux :
kubectl delete pod memory-test
¶ Définition des limites dans un Deployment
Allons au-delà du pod, avec maintenant un déploiement sur trois replicas.
Créez un fichier resource-deployment.yaml :
apiVersion: apps/v1
kind: Deployment
metadata:
name: resource-deployment
spec:
replicas: 3
selector:
matchLabels:
app: resource-app
template:
metadata:
labels:
app: resource-app
spec:
containers:
- name: resource-container
image: nginx
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "128Mi"
cpu: "200m"
Appliquez :
kubectl apply -f resource-deployment.yaml
et vérifiez :
kubectl describe deployment resource-deployment
¶ Volumes persistants
¶ Introduction aux volumes persistants
¶ Types de volumes dans Kubernetes
Kubernetes propose plusieurs types de volumes pour répondre à différents besoins de stockage :
- Volumes éphémères (liés au cycle de vie du pod) :
- emptyDir : stockage temporaire créé quand un pod est assigné à un nœud, supprimé quand le pod est retiré
- hostPath : monte un fichier ou dossier du système de fichiers du nœud hôte
- configMap et secret : Montage des données de configuration ou de secrets
- Volumes persistants (indépendants du cycle de vie du pod) :
- awsElasticBlockStore : Volumes EBS d'AWS
- azureDisk / azureFile : Disques et partages de fichiers Azure
- gcePersistentDisk : Disques persistants Google Cloud
- nfs : Volumes Network File System
- iscsi : Volumes iSCSI
- cephfs / rbd : Volumes Ceph
- glusterfs : Volumes GlusterFS
- local : Stockage local monté directement depuis le nœud (nécessite une gestion manuelle)
- StorageClasses : provisions dynamiques des volumes persistants selon des paramètres prédéfinis
¶ Cycle de vie des volumes par rapport aux pods
- Volumes standards (emptyDir, hostPath, etc.) :
- Créés au moment où le pod est programmé sur un nœud
- Supprimés lorsque le pod est supprimé
- Les données sont perdues lors de la suppression du pod
- Utiles pour le partage de données entre conteneurs d'un même pod
- Volumes persistants (PV) :
- Ressources indépendantes du cycle de vie des pods
- Existent avant et après la durée de vie des pods qui les utilisent
- Peuvent être provisionnés statiquement par l'administrateur ou dynamiquement via les StorageClasses
- Leur cycle de suppression est défini par leur politique de réclamation (Retain, Delete, Recycle)
¶ Cycle de données selon le type de volume
- Durée de vie d'un conteneur : Données perdues lors du redémarrage du conteneur (ex: mémoire du conteneur)
- Durée de vie d'un pod : Données conservées lors des redémarrages de conteneurs, perdues à la suppression du pod (ex: emptyDir)
- Durée de vie indépendante : Données conservées indépendamment des pods (ex: PersistentVolumes)
¶ Différence entre Volume, PersistentVolume (PV) et PersistentVolumeClaim (PVC)
- Volume
- Concept de base pour monter du stockage dans un pod
- Défini directement dans la spécification du pod
- Étroitement couplé au pod et son cycle de vie
- Exemple : emptyDir, hostPath, configMap
volumes:
- name: data-volume
emptyDir: {}
- PersistentVolume (PV)
- Ressource de cluster indépendante des pods
- Abstraction de stockage physique (disque, partition, etc.)
- Provisionné par l'administrateur ou dynamiquement via StorageClass
- Possède son propre cycle de vie
- Définit des caractéristiques : capacité, mode d'accès, classe de stockage, politique de réclamation
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-example
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
hostPath:
path: /mnt/data
- PersistentVolumeClaim (PVC)
- Demande de stockage par un utilisateur/application
- Consomme les ressources PV
- Utilisé par les pods pour accéder au stockage persistant
- Agit comme un intermédiaire entre le pod et le PV
- Spécifie les besoins : taille, mode d'accès, classe de stockage
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-example
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
¶ Workflow complet
- Un administrateur crée des PV ou configure des StorageClasses
- Un utilisateur crée un PVC qui demande un certain stockage
- Kubernetes lie (bind) le PVC à un PV approprié
- Le pod référence le PVC dans sa définition
- Le PVC permet au pod d'utiliser le stockage du PV
# Dans la définition du pod
volumes:
- name: data-volume
persistentVolumeClaim:
claimName: pvc-example
¶ Avantages de ce modèle :
- Séparation des responsabilités : les administrateurs gèrent le stockage, les développeurs consomment
- Abstraction : les pods n'ont pas besoin de connaître les détails du stockage sous-jacent
- Portabilité : les applications peuvent être déplacées entre environnements sans modification
- Gestion du cycle de vie : le stockage existe indépendamment des applications
Ce modèle en trois couches (Volume, PVC, PV) permet de séparer les préoccupations entre développeurs et administrateurs tout en offrant une flexibilité dans la gestion du stockage.
¶ Création d'un volume emptyDir
Créons un pod avec deux conteneurs qui vont partager un volume (shared-data). L'un (writer) va écrire des données, l'autre (reader) va les lire.
Créez un fichier emptydir-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: emptydir-pod
spec:
containers:
- name: writer
image: alpine
command: ["/bin/sh", "-c", "while true; do echo $(date) >> /data/output.txt; sleep 10; done"]
volumeMounts:
- name: shared-data
mountPath: /data
- name: reader
image: alpine
command: ["/bin/sh", "-c", "while true; do cat /data/output.txt; sleep 15; done"]
volumeMounts:
- name: shared-data
mountPath: /data
volumes:
- name: shared-data
emptyDir: {}
La gymnastique habituelle :
Appliquez :
kubectl apply -f emptydir-pod.yaml
Vérifiez :
watch kubectl logs emptydir-pod -c reader
¶ Création d'un PersistentVolume (PV) et PersistentVolumeClaim (PVC)
Nous allons créer ces deux ressources au sein d'un même manifeste.
- un PV (task-pv) ressource de base, lié ici à un répertoire local sur l'hôte (/mnt/data)
- un PVC, demande d'attribution d'un stockage persistant.
Créez un fichierpv-pvc.yaml:
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
hostPath:
path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
Appliquez et vérifiez :
kubectl apply -f pv-pvc.yaml
kubectl get pv
kubectl get pvc
¶ Utilisation d'un PVC dans un Pod
Nous allons maintenant utiliser ce volume persistant au sein d'un pod. Créez un fichier pvc-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: pvc-pod
spec:
containers:
- name: pvc-container
image: nginx
volumeMounts:
- name: task-volume
mountPath: "/usr/share/nginx/html"
volumes:
- name: task-volume
persistentVolumeClaim:
claimName: task-pvc
Prenez le temps de bien comprendre tout le processus logique qui va du volume "physique" hôte (
/mnt/data) jusqu'au volume persistant utilisé par le conteneur/usr/share/nginx/html.
Appliquez et testez :
kubectl apply -f pvc-pod.yaml
kubectl exec -it pvc-pod -- sh -c "echo 'Hello from PV' > /usr/share/nginx/html/index.html"
kubectl port-forward pvc-pod 8081:80
Dans un autre terminal ou navigateur, accédez à http://localhost:8081
Vérifions la persistance, en supprimant le pod :
kubectl delete pod pvc-pod
Puis en le recréant :
kubectl apply -f pvc-pod.yaml
Ajoutons quelque chose :
kubectl exec -it pvc-pod -- sh -c "echo '<br>Hello again from PV !' >> /usr/share/nginx/html/index.html"
et réexposons le pod pour vérifier :
kubectl port-forward pvc-pod 8081:80
¶ Création d'un déploiement avec PVC
Pour finir, illustrons avec un manifeste de déploiement avec le service associé. Créez un fichier stateful-app.yaml :
apiVersion: apps/v1
kind: Deployment
metadata:
name: stateful-app
spec:
replicas: 1
selector:
matchLabels:
app: stateful-app
template:
metadata:
labels:
app: stateful-app
spec:
containers:
- name: app-container
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: data-volume
mountPath: /usr/share/nginx/html
volumes:
- name: data-volume
persistentVolumeClaim:
claimName: task-pvc
---
apiVersion: v1
kind: Service
metadata:
name: stateful-app-service
spec:
type: NodePort
selector:
app: stateful-app
ports:
- port: 80
targetPort: 80
nodePort: 30085
Appliquez le manifeste :
kubectl apply -f stateful-app.yaml
Accédez au service via Minikube :
minikube service stateful-app-service
Écrire des données dans le volume persistant :
kubectl exec -it deployment/stateful-app -- sh -c "echo '<h1>Contenu persistant cree le $(date)</h1>' > /usr/share/nginx/html/index.html"
Rafraîchir le navigateur pour voir le contenu mis à jour.
Supprimer le pod pour forcer sa recréation :
kubectl delete pod -l app=stateful-app
Attendre que le nouveau pod soit prêt :
kubectl wait --for=condition=Ready pods -l app=stateful-app
Rafraîchir à nouveau le navigateur pour vérifier que le contenu persiste
Ajouter maintenant plus de contenu :
kubectl exec -it deployment/stateful-app -- sh -c "echo '<p>Modification apres recreation du pod, $(date)</p>' >> /usr/share/nginx/html/index.html"
Rafraîchir le navigateur une dernière fois pour voir les modifications.
¶ Cycle de vie des pods
¶ États du cycle de vie d'un pod
- Pending : Le pod est accepté par le système mais les conteneurs ne sont pas encore créés
- Running : Au moins un conteneur est en cours d'exécution
- Succeeded : Tous les conteneurs ont terminé avec succès
- Failed : Au moins un conteneur a échoué
- Unknown : L'état du pod ne peut pas être déterminé
¶ Configuration des sondes (probes)
Les sondes de disponibilité (probes) sont des mécanismes essentiels pour la fiabilité des applications dans Kubernetes. Kubernetes propose deux types principaux de sondes :
- livenessProbe : Détermine si le conteneur est en fonctionnement. Si cette sonde échoue, Kubernetes redémarre le conteneur.
- readinessProbe : Détermine si le conteneur est prêt à recevoir du trafic. Si cette sonde échoue, le pod est retiré de la liste des endpoints du service (ne reçoit plus de trafic) mais n'est pas redémarré.
Créez un fichier probes-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: probes-pod
spec:
containers:
- name: probes-container
image: nginx
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 15
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
¶ Configuration des sondes dans ce fichier
livenessProbe
- Type :
httpGet(vérifie l'URL HTTP) - Chemin :
/(racine du serveur web) - Port :
80(port HTTP standard) - initialDelaySeconds :
15(attendre 15 secondes après le démarrage du conteneur avant de commencer les vérifications) - periodSeconds :
10(vérifier toutes les 10 secondes)
readinessProbe
- Type :
httpGet(même méthode que la liveness) - Chemin et port : identiques à la liveness
- initialDelaySeconds :
5(démarrage plus rapide des vérifications) - periodSeconds :
5(vérification plus fréquente)
Autres paramètres possibles pour les sondes (non utilisés ici mais importants)
timeoutSeconds: Temps maximum pour considérer la sonde comme échouée si pas de réponsesuccessThreshold: Nombre de succès consécutifs nécessaires après un échecfailureThreshold: Nombre d'échecs consécutifs tolérés avant action
Types de sondes disponibles
httpGet: Vérifie une URL HTTP (utilisé dans cet exemple)tcpSocket: Vérifie si un port TCP est ouvertexec: Exécute une commande dans le conteneur et vérifie le code de sortie
Appliquez et vérifiez :
kubectl apply -f probes-pod.yaml
kubectl describe pod probes-pod
Comment provoquer un redémarrage automatique du pod ?
On peut par exemple lancer un shell interactif sur le pod ...
kubectl exec -it probes-pod -- /bin/bash
.. puis modifier le port d'écoute de Nginx :
sed -i 's/80;/8080;/' /etc/nginx/conf.d/default.conf
On relance Nginx :
nginx -s reload
et on attend...
Au bout de quelques secondes, le pod va être stoppé, et le terminal ouvert sur le pod fermé avec ce genre d'erreur :
root@probes-pod:/# command terminated with exit code 137
et la commande
kubectl describe pod probes-pod
doit indiquer des traces du problème dans la section events (lignes 6 à 8) :
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 6m37s default-scheduler Successfully assigned default/probes-pod to minikube
Normal Pulled 6m35s kubelet Successfully pulled image "nginx" in 1.124s (1.124s including waiting). Image size: 191998640 bytes.
Warning Unhealthy 4m57s (x8 over 5m22s) kubelet Readiness probe failed: Get "http://10.244.0.45:80/": dial tcp 10.244.0.45:80: connect: connection refused
Warning Unhealthy 4m57s (x3 over 5m17s) kubelet Liveness probe failed: Get "http://10.244.0.45:80/": dial tcp 10.244.0.45:80: connect: connection refused
Normal Killing 4m57s kubelet Container probes-container failed liveness probe, will be restarted
Normal Pulling 4m56s (x2 over 6m36s) kubelet Pulling image "nginx"
Normal Created 4m55s (x2 over 6m35s) kubelet Created container: probes-container
Normal Started 4m55s (x2 over 6m35s) kubelet Started container probes-container
Normal Pulled 4m55s kubelet Successfully pulled image "nginx" in 1.127s (1.127s including waiting). Image size: 191998640 bytes.
¶ Hooks de cycle de vie
Créez un fichier lifecycle-pod.yaml (attention ce pod va utiliser le PVC task-pvc précédemment mis en place ; au besoin, recrééz-le) :
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-pod
spec:
containers:
- name: lifecycle-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo \"postStart hook executed at $(date)\" >> /mnt/data/lifecycle-events.log"]
preStop:
exec:
command: ["/bin/sh", "-c", "echo \"Container stopping at $(date)\" >> /mnt/data/lifecycle-events.log"]
volumeMounts:
- name: lifecycle-data
mountPath: /mnt/data
volumes:
- name: lifecycle-data
persistentVolumeClaim:
claimName: task-pvc
Explications :
-
Section lifecycle : Cette section définit les comportements spéciaux qui doivent se produire à des moments précis du cycle de vie du conteneur.
-
Hook postStart :
- S'exécute immédiatement après la création du conteneur
- S'exécute de manière asynchrone par rapport au processus principal du conteneur
- N'est pas garanti de s'exécuter avant la commande ENTRYPOINT du conteneur
Dans cet exemple, il écrit "postStart hook executed" dans le fichier index.html de nginx
-
Hook preStop :
- S'exécute juste avant que le conteneur ne soit terminé
- Bloque la séquence d'arrêt jusqu'à ce qu'il soit complété (ou jusqu'à expiration du délai)
- Donne au conteneur la possibilité de se terminer proprement
- Dans cet exemple, il enregistre "Container stopping..." dans un fichier journal temporaire
Utilité et cas d'usage :
-
postStart est utile pour :
- Initialiser l'application (créer des fichiers, définir des permissions)
- Enregistrer le service auprès d'un registre
- Notification de démarrage
- Vérifications supplémentaires après le démarrage
-
preStop est utile pour :
- Fermeture propre des connexions
- Enregistrement de l'état final
- Notification de l'arrêt imminent
- Désinscription d'un service du registre
- Transfert de données en cours de traitement
Comportements importants à noter :
- Si le hook postStart échoue, le conteneur sera terminé.
- Le hook preStop doit se terminer avant que le signal TERM ne soit envoyé au conteneur.
- Les hooks ne sont pas réessayés s'ils échouent.
- Ces hooks s'appliquent au niveau du conteneur, pas du pod entier.
Ces hooks sont essentiels pour implémenter des applications robustes qui peuvent démarrer et s'arrêter proprement dans un environnement Kubernetes.
Appliquez :
kubectl apply -f lifecycle-pod.yaml
et consultez le fichier /mnt/data/lifecycle-events.log depuis le pod :
kubectl exec lifecycle-pod -- cat /mnt/data/lifecycle-events.log
Pour observer le hook preStop, on supprime le pod :
kubectl delete pod lifecycle-pod
puis on le relance :
kubectl apply -f lifecycle-pod.yaml
Une nouvelle consultation du fichier devait indiquer les étapes :
¶ Initialisation avec initContainers
Découvrons ici les initContainers qui permettent d'ordonnancer le lancement des containers d'un pod (ou d'un déploiement).
Les initContainers sont particulièrement utiles dans les Deployments pour :
- Attendre que des dépendances soient prêtes (bases de données, API, etc.)
- Préparer des configurations ou des données
- Initialiser des volumes partagés
- Effectuer des migrations de schéma de base de données
- Récupérer des certificats ou des secrets
Créez un fichier init-container-pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: init-container-pod
spec:
initContainers:
- name: init-container
image: alpine
command: ["/bin/sh", "-c", "echo 'Init container executed' > /data/init.txt"]
volumeMounts:
- name: data-volume
mountPath: /data
containers:
- name: main-container
image: alpine
command: ["/bin/sh", "-c", "cat /data/init.txt && sleep 3600"]
volumeMounts:
- name: data-volume
mountPath: /data
volumes:
- name: data-volume
emptyDir: {}
Appliquez et vérifiez :
kubectl apply -f init-container-pod.yaml
kubectl logs init-container-pod
La sortie contient deux parties importantes :
Defaulted container "main-container" out of: main-container, init-container (init)indique que Kubernetes a choisi par défaut d'afficher les logs du conteneur principal, car le pod contient plusieurs conteneurs.Init container executed: C'est le contenu réel du fichier/data/init.txtqui a été créé par l'init container et qui est maintenant lu par le conteneur principal.
Cela démontre que l'init container a bien fonctionné :
- Il s'est exécuté avant le conteneur principal
- Il a créé le fichier avec le message "Init container executed"
- Le conteneur principal peut maintenant lire ce fichier
¶ Bilan
Et nous voici au bout d'une nouvelle étape dans cette découverte de Kubernetes, où nous avons pu :
À la fin du TP, les étudiants doivent être capables de :
- Configurer et utiliser les ConfigMaps et Secrets
- Gérer efficacement les ressources système
- Comprendre et utiliser les volumes persistants
- Maîtriser le cycle de vie complet des pods
Prêts pour un nouvel épisode ?
