Au quotidien

01Publier une nouvelle version

Changez le tag de l'image dans le manifeste, puis réappliquez. Kubernetes remplace les pods un par un, et n'envoie du trafic aux nouveaux que lorsque leur sonde répond : pas d'interruption.

# image: registry.gitlab.com/mon-equipe/boutique:1.4.2  ->  1.4.3
kubectl apply -f boutique.yaml
kubectl rollout status deploy/boutique

02Revenir en arrière

kubectl rollout history deploy/boutique
kubectl rollout undo deploy/boutique                  # la version précédente
kubectl rollout undo deploy/boutique --to-revision=3  # une version précise

Le retour arrière prend quelques secondes. Pensez ensuite à corriger le manifeste : le prochain apply remettrait sinon la version fautive. Quant au kubectl delete en production un vendredi à 17 heures, même les super-héros l'évitent.

03Les sondes

          readinessProbe:            # puis-je recevoir du trafic ?
            httpGet: { path: /health/ready, port: 8080 }
            periodSeconds: 5
          livenessProbe:             # suis-je bloqué au point d'être redémarré ?
            httpGet: { path: /health/live, port: 8080 }
            initialDelaySeconds: 20
            periodSeconds: 10
            failureThreshold: 3

• readiness retire temporairement le pod du Service : démarrage, base indisponible, surcharge. Indispensable.
• liveness redémarre le pod. À utiliser avec prudence : une sonde de vie qui dépend de la base de données redémarre toute l'application dès que la base tousse.

04Requests et limits

Un conteneur tué pour excès de mémoire apparaît avec la raison OOMKilled dans kubectl describe pod. Pour connaître la consommation réelle : kubectl top pods.

05Traverser les nuits de mise à jour

Les serveurs de la plateforme se mettent à jour certaines nuits, un par un. Chaque serveur est vidé de ses pods avant de redémarrer. Votre application reste en ligne si :

• elle a au moins deux réplicas, que Kubernetes répartit sur des serveurs différents ;
• elle a une readinessProbe, pour ne recevoir du trafic qu'une fois prête ;
• elle déclare un PodDisruptionBudget, qui interdit de vider un serveur si cela laisse l'application sans copie :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: boutique
spec:
  minAvailable: 1
  selector:
    matchLabels: { app: boutique }

Attention au piège inverse : un PodDisruptionBudget à minAvailable: 1 sur une application à un seul réplica bloque la maintenance du serveur. L'administrateur viendra alors vous voir, et pas pour vous féliciter.

06Journaux et shell

Écrivez vos journaux sur la sortie standard, pas dans des fichiers : c'est là que Kubernetes et Rancher les cherchent.

07Mise à l'échelle

kubectl scale deploy/boutique --replicas=4

Pratique pour encaisser un pic, mais reportez la valeur dans le manifeste, sinon le prochain apply la ramènera à l'ancienne. Une mise à l'échelle automatique selon la charge est possible avec un HorizontalPodAutoscaler, à condition d'avoir déclaré des requests réalistes.