Comportement anormal du scheduler Bunkerweb après redémarrage des pods (Helm chart 1.0.3 / Bunkerweb 1.6.4)

Community Support Kubernetes
1

Contexte

  • Mode de déploiement : Bunkerweb déployé via le Helm chart officiel, en version 1.0.3

  • Version Bunkerweb : 1.6.4

  • Environnement : cluster Kubernetes (préproduction / production – à adapter), avec un peu plus d’une centaine de services exposés via Bunkerweb

Description du problème

Suite à une modification sur le cluster Kubernetes, plusieurs nœuds sont passés en état MemoryPressure. En conséquence, le contrôleur Kubernetes a procédé à l’éviction de certains pods, dont les pods Bunkerweb (et potentiellement le pod MariaDB déployé via le même chart).

Lors du redémarrage des pods Bunkerweb :

  • Le processus de scheduler se lance en mode failover.

  • Aucun message d’erreur explicite n’apparaît dans les logs du scheduler.

  • On observe notamment au démarrage la ligne :

    • [SCHEDULER] [26] [ℹ️ ] - ✅ Database connection established

  • Peu après, le pod affiche les logs suivants :

    • Start rendering template

    • puis : Caught Stop operation

  • À chaque occurrence de ce log, le pod redémarre systématiquement (boucle de redémarrage).

Du côté du pod MariaDB inclus dans le chart Bunkerweb, à exactement le même moment, nous observons le message suivant dans les logs :

  • [Warning] Aborted connection 19 to db: 'db' user: 'bunkerweb' host: '10.2.22.105' (Got an error reading communication packets)

Ce comportement suggère un problème de communication entre Bunkerweb et la base MariaDB (du même déploiement Helm) après l’épisode de MemoryPressure, entraînant un redémarrage en boucle des pods Bunkerweb, sans message d’erreur explicite dans les logs applicatifs Bunkerweb.

Impact

  • Indisponibilité fonctionnelle des services :

    • Depuis l’UI Bunkerweb, l’ensemble des services apparaît bien listé.

    • Cependant, aucun de ces services n’est effectivement disponible côté trafic.

  • Configuration Nginx non appliquée :

    • Les pods Bunkerweb redémarrent sans embarquer aucune des configurations Nginx qui devraient être générées et poussées par le scheduler.

    • Concrètement, les fichiers de configuration attendus ne sont pas rendus/appliqués sur les pods Bunkerweb.

Étapes ayant conduit à l’incident

  1. Déploiement de Bunkerweb via Helm chart 1.0.3 (version Bunkerweb 1.6.4), avec MariaDB incluse dans le même chart.

  2. Montée de charge sur le cluster

  3. Passage de certains nœuds Kubernetes en état MemoryPressure.

  4. Éviction automatique des pods Bunkerweb (et possiblement du pod MariaDB) par l’API Kubernetes.

  5. Redémarrage des pods Bunkerweb :

    • Scheduler en failover, pas d’erreur dans les logs.

    • Log : ✅ Database connection established.

    • Puis : Start rendering template → Caught Stop operation → redémarrage du pod.

  6. Constat parallèle dans les logs du pod MariaDB du chart Bunkerweb :
    [Warning] Aborted connection 19 to db: 'db' user: 'bunkerweb' host: '10.2.22.105' (Got an error reading communication packets).

Attentes / Demande d’assistance

  • Compréhension de la raison pour laquelle :

    • L’UI affiche les services,

    • Mais aucune configuration Nginx n’est effectivement appliquée sur les pods Bunkerweb après redémarrage.

  • Recommandations :

    • Bonnes pratiques de configuration Bunkerweb + MariaDB (déployés via le même chart) pour résister à ce type d’incident (evictions, pertes temporaires de ressources).

    • Éventuels paramètres à ajuster côté Bunkerweb (timeouts, retry, configuration du scheduler, etc.).

    • Indication si ce comportement est attendu ou s’il s’agit d’un bug connu dans la version 1.6.4 ou dans le Helm chart 1.0.3.