Probes Kubernetes : Clé de la disponibilité et résilience

Comment Kubernetes surveille-t-il l’état des conteneurs et agit-il en conséquence pour éviter les défaillances ? C’est là qu’interviennent les probes Kubernetes.

Qu’est-ce qu’une probe Kubernetes ?

Les probes (sondes) Kubernetes jouent donc un rôle important dans la gestion de la disponibilité et de la résilience des applications conteneurisées. Elles permettent au système d’orchestration de surveiller l’état des conteneurs et d’agir en conséquence pour éviter les défaillances.

Quels sont les types de probes Kubernetes ?

Kubernetes propose trois types de probes : liveness, readiness et startup, chacune ayant une fonction spécifique pour assurer un bon fonctionnement des applications.

1. Startup Probe : gérer les longs démarrages

Une startup probe est utilisée pour les applications qui ont besoin d’un long temps de démarrage. Contrairement à la liveness probe, elle empêche Kubernetes de redémarrer prématurément un conteneur en attente de son démarrage complet. Elle est donc optionnelle.

Exemple d’utilisation :

• Une base de données qui charge des données volumineuses en mémoire.
• Une application Java qui doit compiler ou charger de nombreuses dépendances.

2. Liveness Probe : détecter un conteneur en panne

Une liveness probe permet de savoir si une application fonctionne toujours. Si cette sonde échoue, Kubernetes considère que le conteneur est dans un état incohérent et le redémarre. Cela évite qu’un service reste bloqué à cause d’un dysfonctionnement interne, comme une deadlock ou une boucle infinie.

Exemples de problèmes détectés :

• Une application est bloquée dans une boucle infinie.
• Un thread est suspendu, empêchant l’application de répondre aux requêtes.
• Un service perd une connexion essentielle et ne peut plus fonctionner normalement.

3. Readiness Probe : signaler quand un conteneur est prêt

Une readiness probe indique si un conteneur est prêt à recevoir du trafic. Tant qu’elle échoue, le conteneur est exclu des services et ne reçoit aucune requête. Cela est particulièrement utile pour les applications nécessitant un temps d’initialisation avant de pouvoir fonctionner correctement.

Exemples de problèmes détectés :

• Une API doit se connecter à une base de données avant de fonctionner.
• Une application doit charger des fichiers de configuration avant d’accepter des requêtes.
• Un service de messagerie attend l’établissement de connexions externes.

Dans quel ordre les probes Kubernetes sont-elles exécutées ?

Les probes Kubernetes sont exécutées dans un ordre précis illustré par le diagramme suivant :

1. Startup Probe : Si la startup probe échoue, le Pod est redémarré. Si elle réussit, la liveness probe est activée.
2. Liveness Probe : Si la liveness probe échoue, le Pod est redémarré. Si elle réussit, la readiness probe est activée.
3. Readiness Probe : Si la readiness probe échoue, le Pod est retiré temporairement du service.

Les différents types de vérifications pour les probes Kubernetes

Kubernetes propose plusieurs méthodes pour vérifier l’état d’une application à travers les probes. Voici les différents types de vérifications disponibles :

1. HTTPGet

La vérification HTTPGet effectue une requête HTTP sur un chemin spécifié et vérifie le code de réponse. Généralement utilisée pour les applications web exposant un endpoint dédié à la santé de l’application.

Exemple de configuration :

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Cas d’usage :

• Vérifier la réponse d’une API REST.
• Contrôler une application web via un endpoint /health ou /ready.

2. TCPSocket

La vérification par TCPSocket tente d’établir une connexion TCP sur le port spécifié. La probe réussit si le port est ouvert et répond.

Exemple de configuration :

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 5
  periodSeconds: 10

Cas d’usage :

• Vérifier que des services comme MySQL, PostgreSQL, ou Redis acceptent des connexions TCP.
• S’assurer qu’une application écoute bien sur le port prévu.

3. Exec (Commande)

La vérification Exec lance une commande dans le conteneur et vérifie son résultat. Si la commande retourne un code 0, la probe est réussie.

Exemple de configuration :

startupProbe:
  exec:
    command:
    - cat
    - /app/ready
  initialDelaySeconds: 10
  periodSeconds: 5

Cas d’usage :

• Vérifier la présence d’un fichier indiquant que l’application est prête.
• Lancer un script personnalisé pour vérifier des préconditions spécifiques.

4. GRPC

Depuis Kubernetes v1.23, il est possible d’utiliser des gRPC probes pour tester directement un service gRPC.

Exemple de configuration :

readinessProbe:
  grpc:
    port: 50051
    service: myapp.MyService
  initialDelaySeconds: 5
  periodSeconds: 10

Cas d’usage :

• Vérifier l’état d’un service exposant une interface gRPC.

5. Headers HTTP personnalisés

Lors de l’utilisation de HTTPGet, il est également possible de fournir des headers HTTP personnalisés, ce qui permet d’ajouter de la sécurité ou de vérifier des comportements spécifiques.

Exemple de configuration :

livenessProbe:
  httpGet:
    path: /health
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: Awesome
  initialDelaySeconds: 5
  periodSeconds: 10

Cas d’usage :

• Ajouter une clé API ou des jetons d’authentification aux vérifications HTTP.

Récapitulatif des méthodes de check

Type de vérification	Protocole	Utilisation typique
HTTPGet	HTTP(s)	Applications Web, API REST
TCPSocket	TCP	Bases de données, services TCP
Exec	Commande	Vérification personnalisée (fichier, processus)
gRPC (alpha)	gRPC	Services gRPC
Headers HTTP	HTTP(s)	Vérifications avec authentification

Chaque méthode de vérification est adaptée à des scénarios précis. Choisissez celle qui correspond le mieux au mode de fonctionnement de votre application.

Comment configurer des probes Kubernetes ?

Les probes Kubernetes sont configurées dans le fichier de déploiement (Deployment) ou de Pod. Elles sont définies par des options qui spécifient le type de sonde, le port à interroger, le chemin de la requête et les paramètres de la requête.

Configuration d’une startup probe

Une Startup Probe utilise des mécanismes similaires aux autres probes (HTTP, TCP, Command), mais avec une logique adaptée au démarrage.

Exemple de configuration HTTP :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tests-probe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 5

Explication des paramètres :

• httpGet : type de sonde HTTP :
  • path : chemin de la requête.
  • port : port à interroger.
• initialDelaySeconds : délai avant le premier test.
• periodSeconds : intervalle entre chaque test.
• failureThreshold : nombre de tests avant de considérer la sonde comme échouée.

Bonnes pratiques

• Utiliser une Startup Probe pour les applications à démarrage long.
• Définir un failureThreshold élevé pour éviter des redémarrages inutiles.
• Utiliser un periodSeconds adapté au temps de démarrage réel de l’application.
• Tester la Startup Probe localement avant de la déployer en production.

Configuration d’une Liveness Probe

Voici un exemple de Liveness Probe intégrée dans un Deployment, avec une requête HTTP sur le port 8080.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Explication des paramètres :

• httpGet : Vérifie si l’URL /health répond bien sur le port 8080.
• initialDelaySeconds : Attend 5 secondes avant la première vérification.
• periodSeconds : Vérifie l’état de l’application toutes les 10 secondes.

Bonnes pratiques

• Commencez par des vérifications de santé de base, puis développez-les au fur et à mesure que les besoins de votre application augmentent.
• Les liveness probes doivent être légères pour éviter de consommer excessivement du CPU ou de la mémoire.
• Ajustez initialDelaySeconds, timeoutSeconds, failureThreshold, et periodSeconds en fonction des performances et des caractéristiques de stabilité de votre application.
• Surveillez continuellement les échecs des sondes et ajustez les paramètres si l’application est redémarrée trop fréquemment.

Configurer une Readiness Probe

Voici un exemple d’intégration d’une Readiness Probe dans un Deployment, vérifiant un endpoint HTTP sur le port 8080.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-readiness-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Explication des paramètres :

• httpGet : Vérifie si l’URL /ready répond bien sur le port 8080.
• initialDelaySeconds : Kubernetes attend 5 secondes avant la première vérification.
• periodSeconds : Kubernetes vérifie l’état de l’application toutes les 10 secondes.

Bonnes pratiques

• Commencez par des vérifications de santé de base et affinez progressivement votre readiness probe au fur et à mesure que votre application évolue.
• Pour les sondes HTTP et gRPC, utilisez un endpoint /readiness dédié, distinct des autres.
• Utilisez des commandes légères et non bloquantes dans les sondes exec pour minimiser l’impact sur les performances du conteneur.
• Utilisez initialDelaySeconds, periodSeconds et failureThreshold pour tenir compte du temps de démarrage et des caractéristiques de performance de votre application.
• Évitez la Surcharge: Des sondes trop fréquentes ou des commandes gourmandes en ressources peuvent causer une charge inutile ou des ralentissements.

Conclusion

Comprendre la différence entre les Startup Probe, Liveness Probe et Readiness Probe est primordial pour garantir un bon fonctionnement des applications Kubernetes. Chaque probe a un rôle spécifique : éviter un redémarrage prématuré, détecter une application bloquée ou empêcher l’envoi de requêtes à un service non prêt.

Les utiliser à bon escient permet d’optimiser la gestion des conteneurs, d’éviter des interruptions inutiles et d’assurer une haute disponibilité des services. Une mauvaise configuration peut entraîner des redémarrages en boucle ou des indisponibilités évitables. Adapter chaque probe aux besoins réels de l’application est donc essentiel pour un déploiement fiable et efficace.