Introduction
Les journaux (logs), les événements, la commande exec et le transfert de port (port-forwarding) vous aident à inspecter une application. Les sondes permettent à Kubernetes d'inspecter l'application en continu. Une sonde de préparation (readiness probe) répond à la question : « Ce Pod doit-il recevoir du trafic ? ». Une sonde de vivacité (liveness probe) répond à la question : « Ce conteneur doit-il être redémarré ? ».
Dans ce laboratoire, vous configurerez la préparation et la vivacité séparément. Tout d'abord, vous créerez une application qui ne devient prête (Ready) qu'après avoir créé un point de terminaison /ready. Ensuite, vous créerez une autre application avec une sonde de vivacité, supprimerez son fichier de santé avec kubectl exec, et observerez Kubernetes redémarrer le conteneur.
Préparer un espace de noms pour la pratique des sondes
Dans cette étape, vous allez préparer un espace de noms (namespace) propre pour pratiquer les sondes.
Commencez dans /home/labex/project. Vous conserverez les manifestes des sondes dans ce répertoire.
mkdir -p /home/labex/project
cd /home/labex/project
Vérifiez que le serveur API Kubernetes est accessible. Si la machine virtuelle vient de démarrer et que le nœud n'est pas encore prêt, attendez quelques secondes et exécutez à nouveau la commande.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Attendez que le Pod réseau du cluster soit prêt. Les sondes et les Services dépendent d'un réseau de Pods sain.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Sortie attendue :
pod/calico-node-... condition met
Créez un espace de noms nommé ckad-prep-probes et définissez-le comme espace de noms actuel :
kubectl create namespace ckad-prep-probes
kubectl config set-context --current --namespace=ckad-prep-probes
Confirmez l'espace de noms actuel :
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Sortie attendue :
ckad-prep-probes
Configurer une sonde de préparation
Dans cette étape, vous configurerez une sonde de préparation et observerez que le Service n'utilise que les Pods prêts.
Le conteneur démarre un serveur HTTP immédiatement, mais il crée /www/ready quelques secondes plus tard. La sonde de préparation vérifie GET /ready sur le port 8080. Tant que ce chemin n'existe pas, le Pod peut être en état Running mais pas Ready, et le Service ne doit pas lui envoyer de trafic.
Créez readiness-web.yaml :
cat > readiness-web.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: readiness-web
spec:
replicas: 2
selector:
matchLabels:
app: readiness-web
template:
metadata:
labels:
app: readiness-web
spec:
terminationGracePeriodSeconds: 0
containers:
- name: web
image: busybox:1.36
command:
- /bin/sh
- -c
- |
mkdir -p /www
echo readiness-ok > /www/index.html
(sleep 12; echo ready > /www/ready) &
httpd -f -p 8080 -h /www
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 1
periodSeconds: 2
failureThreshold: 1
---
apiVersion: v1
kind: Service
metadata:
name: readiness-web
spec:
selector:
app: readiness-web
ports:
- port: 80
targetPort: 8080
EOF
Appliquez le manifeste et observez les Pods peu après la création :
kubectl apply -f readiness-web.yaml
sleep 3
kubectl get pods -l app=readiness-web
La sortie attendue peut montrer des Pods qui sont Running mais pas encore Ready :
NAME READY STATUS RESTARTS AGE
readiness-web-... 0/1 Running 0 ...
Attendez que le déploiement soit disponible :
kubectl rollout status deployment/readiness-web --timeout=120s
Sortie attendue :
deployment "readiness-web" successfully rolled out
Inspectez les points de terminaison du Service via EndpointSlice. Une fois la sonde de préparation validée, le Service devrait avoir deux points de terminaison prêts.
kubectl get endpointslice -l kubernetes.io/service-name=readiness-web
La sortie attendue inclut :
NAME ADDRESSTYPE PORTS ENDPOINTS
readiness-web-... IPv4 8080 ... + 1 more...
Créez un Pod client et testez le Service :
kubectl run probe-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
kubectl wait --for=condition=Ready pod/probe-client --timeout=120s
kubectl exec probe-client -- wget -qO- http://readiness-web
Sortie attendue :
readiness-ok
Configurer une sonde de vivacité
Dans cette étape, vous configurerez une sonde de vivacité qui vérifie un fichier de santé.
Une sonde de vivacité décide si Kubernetes doit redémarrer un conteneur. Cet exemple utilise une sonde exec qui exécute test -f /tmp/healthy à l'intérieur du conteneur. Le conteneur crée ce fichier au démarrage, il est donc considéré comme sain initialement.
Créez liveness-web.yaml :
cat > liveness-web.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: liveness-web
spec:
replicas: 1
selector:
matchLabels:
app: liveness-web
template:
metadata:
labels:
app: liveness-web
spec:
terminationGracePeriodSeconds: 0
containers:
- name: web
image: busybox:1.36
command:
- /bin/sh
- -c
- |
touch /tmp/healthy
mkdir -p /www
echo liveness-ok > /www/index.html
httpd -f -p 8080 -h /www
ports:
- containerPort: 8080
livenessProbe:
exec:
command:
- test
- -f
- /tmp/healthy
initialDelaySeconds: 3
periodSeconds: 3
failureThreshold: 1
EOF
Appliquez le manifeste et attendez le déploiement :
kubectl apply -f liveness-web.yaml
kubectl rollout status deployment/liveness-web --timeout=120s
La sortie attendue inclut :
deployment.apps/liveness-web created
deployment "liveness-web" successfully rolled out
Stockez le nom du Pod et confirmez que le fichier de santé existe :
LIVE_POD="$(kubectl get pods -l app=liveness-web -o jsonpath='{.items[0].metadata.name}')"
echo "$LIVE_POD"
kubectl exec "$LIVE_POD" -- test -f /tmp/healthy
echo "health file exists"
La sortie attendue inclut le nom du Pod et :
health file exists
Décrivez le Pod et recherchez la configuration de la sonde de vivacité :
kubectl describe pod "$LIVE_POD" | grep -A3 'Liveness:'
La sortie attendue inclut :
Liveness: exec [test -f /tmp/healthy] delay=3s timeout=1s period=3s
Déclencher un redémarrage par la sonde de vivacité
Dans cette étape, vous supprimerez le fichier de santé et observerez la sonde de vivacité redémarrer le conteneur.
L'objet Pod peut rester le même pendant que le conteneur à l'intérieur redémarre. C'est pourquoi vous surveillerez le compteur de redémarrages du conteneur au lieu de vous attendre à un nouveau nom de Pod.
Stockez le nom du Pod actuel :
LIVE_POD="$(kubectl get pods -l app=liveness-web -o jsonpath='{.items[0].metadata.name}')"
echo "$LIVE_POD"
Supprimez le fichier de santé à l'intérieur du conteneur :
kubectl exec "$LIVE_POD" -- rm /tmp/healthy
Surveillez le compteur de redémarrages jusqu'à ce qu'il devienne supérieur à zéro. La sonde de vivacité s'exécute toutes les trois secondes, cela peut donc prendre un court instant.
for i in $(seq 1 20); do
RESTARTS="$(kubectl get pod "$LIVE_POD" -o jsonpath='{.status.containerStatuses[0].restartCount}')"
echo "restart-count=$RESTARTS"
if [ "$RESTARTS" != "0" ]; then
break
fi
sleep 3
done
La sortie attendue finit par inclure :
restart-count=1
Après le redémarrage du conteneur, la commande de démarrage recrée /tmp/healthy. Confirmez que le fichier est de retour :
kubectl exec "$LIVE_POD" -- test -f /tmp/healthy
echo "health file recreated"
Sortie attendue :
health file recreated
Lisez les événements du Pod et recherchez l'échec de la sonde de vivacité :
kubectl describe pod "$LIVE_POD" | sed -n '/Events:/,$p'
La sortie attendue inclut :
Warning Unhealthy ... Liveness probe failed
Normal Killing ... Container web failed liveness probe
Résumé
Vous avez configuré les deux principales sondes d'application. La sonde de préparation a contrôlé le moment où les Pods rejoignaient les points de terminaison du Service, tandis que la sonde de vivacité a redémarré un conteneur après la suppression de son fichier de santé. Vous avez également inspecté les EndpointSlices, les descriptions de Pods, les compteurs de redémarrages et les événements pour lier la configuration des sondes au comportement visible de Kubernetes.
