Commandes de suivi et de diagnostic

Exposer les ports d'un pod

Le pod que nous avons créé dans le TP précédent écoute sur le port 8080 et répond avec les requêtes qu'il reçoit. - Nous allons commencer par recréer ce pod

kubectl apply -f echoserver-pod.yaml

En l'état, nous n'avons aucun moyen d'accéder au port 8080 exposé par le conteneur de ce pod. - Grâce à kubectl, nous pouvons exposer le port de manière simple, à des fins de développement/diagnostic

kubectl port-forward <nom du pod> 8080:8080

Cette commande créé un tunnel entre le port local 8080 et le port 8080 du pod cible. Il est désormais possible d'accéder au pod avec une requête locale

curl localhost:8080

Hostname: hello

Pod Information:
    -no pod information available-

Server values:
    server_version=nginx: 1.13.3 - lua: 10008

Request Information:
    client_address=127.0.0.1
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://localhost:8080/

Request Headers:
    accept=*/*
    host=localhost:8080
    user-agent=curl/7.54.0

Request Body:
    -no body in request-

Accès aux logs

Conserver un terminal avec le port-forward et lancer watch -n 1 curl localhost:8080

Kubectl permet d'accéder aux logs d'un pod ou d'un ensemble de pods

kubectl logs <nom du pod>

L'interface de la commande logs est similaire à la commande logs de docker

kubectl logs -f <nom du pod>
curl localhost:8080

Lorsqu'un pod contient plusieurs conteneurs, il faut spécifier le conteneur dont on veut obtenir les logs

kubectl logs -c <nom du conteneur> <nom du pod>

Il est également possible d'obtenir les logs de tous les conteneurs d'un coup

kubectl logs --all-containers <nom du pod>

Dans le cas où un conteneur s'arrête et qu'un nouveau le remplace, il peut être utile de consulter les logs du conteneur qui s'est arrêté

kubectl logs -p <nom du pod>

Enfin, lorsqu'une application est constituée de plusieurs pods, il est possible d'afficher les logs par sélecteur de label

kubectl logs -l app=echo-server

Exécuter des commandes à l'intérieur du pod

Kubectl propose une commande exec qui a elle aussi une interface similaire à celle de docker. Elle permet d'exécuter des commandes directement à l'intérieur d'un pod.

Exécuter une commande simple, le résultat de la commande s'affichera sur la sortie standard du terminal

kubectl exec <nom du pod> -- ls

Il est possible d'exécuter des commandes intéractives et de simuler un terminal, l'usage le plus courant de ces options est l'exécution d'un shell à l'intérieur du conteneur

kubectl exec -it <nom du pod> -- /bin/sh

De la même manière que pour kubectl log, dans le cas où un pod est constitué de plusieurs conteneurs, il faut spécifier le nom du conteneur

kubectl exec -c <nom du conteneur> <nom du pod> ls

Échanger des fichiers avec le pod

La commande kubectl cp permet de transférer des fichiers vers ou depuis le pod. Encore une fois, l'interface de la commande est très similaire à celle de docker, qui est elle-même similaire à celle de scp

Transférer un fichier vers le pod

echo "test" > test.txt
kubectl cp test.txt <nom du pod>:/tmp

Transférer un fichier depuis le pod

kubectl cp <nom du pod>:/usr/share/nginx/html/index.html .

Sondes de bonne santé et de disponibilité

Les sondes sont cruciale au bon fonctionnement de l'orchestration fournie par Kubernetes. Elles permettent de déterminer à quel moment un pod peut être inclu dans le load-balancing, ou à quel moment il doit être détruit et recréé.

Sondes de bonne santé

Pour expérimenter avec ces sondes, nous allons commencer par créer un nouveau pod - Créer un fichier de manifeste nommé liveness.yaml avec le contenu suivant

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

Ce pod créé un fichier /tmp/healthy vide puis le supprime au bout de 30 secondes. Ceci va nous permettre de simuler un pod qui fonctionne un temps avant de tomber en panne. Nous considèrerons que le pod fonctionne tant que le fichier /tmp/healthy est présent.

Nous allons donc écrire une sonde de bonne santé (livenessProbe) qui va vérifier le bon fonctionnement de ce pod.

Cette sonde aura les caractéristiques suivantes :

Elle exécute la commande cat /tmp/healthy (quand le fichier sera supprimé, la commande retournera un code erreur)
Elle devra s'exécuter toutes les 5 secondes
Elle devra s'exécuter avec un délai initial de 5 secondes

Écrire la définition de cette sonde et l'ajouter à la définition du conteneur liveness (s'appuyer sur la documentation de référence)

...
image: busybox
args:
  ...
livenessProbe:
  ...

Sondes de disponibilité

Nous allons créer un nouveau pod basé sur l'image k8s.gcr.io/liveness qui va nous permettre de créer une sonde de disponibilité.

Créer un fichier manifeste nommé readiness avec le contenu suivant

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness
spec:
  containers:
  - name: readiness
    image: k8s.gcr.io/liveness
    args:
    - /server

Le point d'entrée (/server) démarre un point d'accès http qui répond 200 OK pendant 10 secondes, puis se met à répondre une erreur 500.

De la même manière que l'exercice précédent, écrire une sonde de disponibilité avec les caractéristiques suivantes:

Elle accède au point d'accès http /healthz sur le port 8080
Elle s'exécute toutes les 3 secondes
Elle s'exécute avec un délai initial de 3 secondes

Utiliser les go-template

L'utilisation des go-templates est une fonctionnalité puissance de kubectl permettant de créer des formats de sortie sur-mesure, notamment très utile pour l'écriture de scripts de gestion

Exemple, afficher le nom du pod

kubectl get pod hello -o go-template="{{.metadata.name}}"

Exercice: utiliser l'option go-template-file pour générer un résumé de l'état des pods sous la forme suivante

<nom du pod> | <phase du pod> | <ip du pod>