Un déploiement serveur sûr avec les tests canari

• Retour d’expérience sur le déploiement canari dans un environnement Kubernetes, rédigé par Taeho Kim de VCNC, l’entreprise qui exploite Tada.

• Le nom « déploiement canari » vient de l’époque où les mineurs emmenaient un canari en cage dans les mines afin de détecter les fuites de gaz.

• Lors d’une montée de version majeure de Spring Boot, les versions des bibliothèques dont il dépend changent aussi de manière forcée ; afin de minimiser les problèmes de performance ou les incidents non testés que cela peut provoquer, ils ont tenté un déploiement canari.

• Le déploiement est effectué sur Kubernetes avec le gestionnaire de paquets Helm ; l’unité de paquetage de Helm est appelée un « chart », et lorsqu’un chart est installé sur un cluster Kubernetes, cela crée une release.

• Ils ont créé un chart/une release pour le canari, puis ajouté des annotations au contrôleur Ingress afin que seule une proportion définie des requêtes soit envoyée vers l’Ingress canari.

Travaux à venir

• Lorsqu’un problème survient sur la release canari, il est difficile de déterminer s’il vient des changements du canari ou d’un problème déjà existant ; il faut donc une méthode consistant à maintenir un groupe de contrôle avec le même ratio, puis à comparer les métriques.

• Comme une partie des requêtes est envoyée vers le canari indépendamment de l’utilisateur, même si le canari a un problème, une nouvelle tentative peut parfois aboutir parce que l’ancienne version traite finalement la requête ; mais à l’échelle globale, la proportion d’utilisateurs exposés aux problèmes du canari peut augmenter. Il semble donc possible d’améliorer le contrôle en routant vers le canari selon des groupes d’utilisateurs, comme on le ferait avec un traitement sticky côté LB.