Rechargement automatique de configuration avec Stakater Reloader

Contexte et description de la problématique

Problèmes rencontrés

• Kubernetes ne redémarre pas nativement les workloads lorsque les ConfigMaps ou Secrets changent ; la configuration peut donc rester obsolète.
• La mise à jour manuelle (delete pod / rollout) augmente la charge opérationnelle et le risque d’erreur humaine.
• Les solutions maison (sidecar, scripts) fragmentent la plateforme et complexifient la maintenance.

Alternatives considérées

• Utiliser configmapGenerator de Kustomize pour changer le hash dans l’image ⇒ nécessite quand même un rollout et génère une prolifération d’images.
• Compter sur la mise à jour « projected volume » ⇒ nécessite que l’application recharge les fichiers, ne couvre pas les variables d’environnement.
• Développer un watcher sidecar personnalisé ⇒ ré‑implémente une logique déjà disponible, non mutualisée.
• Ne rien faire ⇒ processus manuel, propice aux erreurs et indisponibilités.

Éléments moteurs de la décision

• Stakater Reloader est un contrôleur léger, maintenu par la communauté, déjà éprouvé en production.
• Modèle opt‑in via l’annotation reloader.stakater.com/auto: "true", évitant les redémarrages inattendus.
• Couvre les principaux types de workload : Deployment, StatefulSet, DaemonSet, Rollout, etc.
• Facilement déployé et mis à jour via Helm (stakater/reloader).
• Expose des métriques Prometheus et des logs intégrables dans notre stack d’observabilité.
• RBAC restreint : seulement watch sur ConfigMaps/Secrets et patch sur les workloads ciblés.

Conclusion

• ✅ Déployer Stakater Reloader sur tous les clusters (toutcasser, kity).
• ✅ Activer l’opt‑in par annotation reloader.stakater.com/auto: "true" sur les workloads nécessitant un refresh.
• ✅ Activer l’export Prometheus et configurer une alerte si un restart échoue >30 s.
• ✅ Documenter l’usage dans le README plateforme et former les équipes à l’ajout d’annotations.

Conséquences

• 👍 Mises à jour de configuration automatiques, sans intervention manuelle et sans changement de code.
• 👍 Réduction du risque d’erreur et des temps d’indisponibilité grâce aux rollouts contrôlés.
• 👍 Cohérence entre environnements via un composant unique.
• 👎 Possibilité de redémarrages non souhaités si l’annotation est posée par erreur ; mitigé par GitOps et revue de code.
• 👎 Dépendance à un contrôleur supplémentaire ; en cas de panne, la fonction d’auto‑reload est temporairement perdue, mais les workloads continuent de tourner.