Aller au contenu principal

Healthchecks et scaling

Disponible

Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.

Un healthcheck dit à la plateforme quand un conteneur est prêt à recevoir du trafic et quand il faut le redémarrer. replicas, strategy et autoscale règlent combien d'exemplaires tournent et comment ils sont remplacés lors d'une mise à jour.

Prérequis​

  • Un service de kind deployment (ces champs ne s'appliquent qu'à lui).
  • Pas de volumes sur le service pour replicas > 1 ou autoscale (Stockage).

Étapes​

1. Ajouter une sonde et des réplicas​

api.yml
apiVersion: deploy.stackngo.io/v1alpha1
kind: App
metadata:
  name: api
spec:
  services:
    api:
      image: registry.gitlab.com/acme/api:1.2.0
      ports: ["8080"]
      healthcheck:
        http: /healthz          # GET /healthz sur le premier port
        interval: 15s
        timeout: 5s
        retries: 3
        startPeriod: 30s        # laisse 30 s à l'application pour démarrer
      replicas: 2
      strategy: { type: rolling, maxSurge: 1, maxUnavailable: 0 }
      autoscale: { max: 6, cpu: 70 }
      ingress: { port: 8080 }
sng apply api.yml

2. Suivre une mise à jour​

sng app patch api --image registry.gitlab.com/acme/api:1.3.0
sng app describe api
App      : api
Statut   : en cours
Message  : api : 1/2 à jour, 2 disponibles
SERVICE  KIND        IMAGE                               PHASE        URL                                          DETAIL
api      deployment  registry.gitlab.com/acme/api:1.3.0  Progressing  https://api-api.<tenant>.dev.stackngo.app/  RollingOut 1/2 à jour, 2 disponibles

Avec maxUnavailable: 0, il y a toujours 2 exemplaires disponibles pendant le remplacement.

Vérification​

sng app describe api revient à Statut : prête, Reconciled 2/2 prêts. Pendant une montée en charge, le nombre d'exemplaires affiché dépasse replicas jusqu'à autoscale.max.

healthcheck​

Exactement un des trois tests, plus des réglages communs :

ChampDéfautRôle
http: /chemin—requête GET ; sain si la réponse est 2xx ou 3xx
portpremier port TCP de portsport du test http
tcp: 5432—sain si la connexion TCP s'ouvre
cmd: ["pg_isready"]—commande exécutée dans le conteneur ; sain si elle sort avec le code 0
interval10sdélai entre deux tests (arrondi à la seconde, 1 s à 1 h)
timeout5sdurée maximale d'un test
retries3échecs consécutifs avant de déclarer le conteneur malade (1 à 30)
startPeriodaucundélai avant le premier test de vivacité, pour les démarrages lents

La même sonde sert deux fois :

  • disponibilité : un exemplaire qui échoue ne reçoit plus de trafic, sans être redémarré ;
  • vivacité : après retries échecs, le conteneur est redémarré. startPeriod ne s'applique qu'à ce test.

Sans healthcheck, un exemplaire est considéré prêt dès que son conteneur a démarré.

Choisir le bon test

http pour une API ou un site, tcp pour une base ou un cache sans endpoint HTTP, cmd quand l'image fournit un outil (pg_isready, redis-cli ping). Les healthcheck compose CMD / CMD-SHELL se traduisent en cmd.

replicas et strategy​

ChampDéfautRôle
replicas1nombre d'exemplaires (0 à 100) ; 0 arrête le service sans le supprimer
strategy.typerollingrolling : remplacement progressif ; recreate : arrêt complet puis redémarrage
strategy.maxSurge1exemplaires en plus pendant la mise à jour (nombre ou 25%) ; rolling seulement
strategy.maxUnavailable0exemplaires indisponibles tolérés pendant la mise à jour ; rolling seulement

maxSurge: 0 et maxUnavailable: 0 ensemble sont refusés (la mise à jour ne pourrait pas avancer). Un service avec volumes est toujours en recreate.

sng app scale api 3 change replicas sans toucher au reste ; il est refusé si le service a un autoscale (modifiez autoscale.max) ou un volume avec un nombre supérieur à 1.

autoscale​

replicas: 2
autoscale: { max: 6, cpu: 70 }
ChampDéfautRôle
max—nombre maximal d'exemplaires (1 à 100), ≥ replicas
cpu80utilisation cible, en % de la réservation CPU de la size

Le minimum est replicas (1 si absent ou 0). Le nombre d'exemplaires monte quand l'utilisation CPU moyenne dépasse la cible, redescend ensuite. La cible se mesure par rapport à la réservation de la taille : un service xs (500m réservés) à 70 % déclenche vers 350m de CPU utilisé.

Avec autoscale, le nombre d'exemplaires n'est plus piloté par le manifeste ; replicas ne sert plus qu'à fixer le plancher.

Pour aller plus loin​

  • Un déploiement qui n'aboutit pas (exemplaires qui ne deviennent jamais prêts) finit en Failed, raison RolloutFailed. Les causes habituelles : image qui démarre en root, sonde sur un mauvais port ou chemin, Secret manquant. sng app logs api donne la réponse.
  • Il n'existe pas de commande de retour arrière pour un service : réappliquez l'ancienne image.
  • Une mise à jour progressive crée temporairement replicas + maxSurge exemplaires : avec une offre serrée, c'est ce pic qui peut déclencher QuotaExceeded (Tailles et ressources).

Voir aussi​