Mettre à jour des labels + network-policy sans tout casser
Petit retour d’expérience qui a mal tourné…..
Je dédie ce post medium à mon collègue et ami, Clément Fourrel, Lead Senior Developper chez subitoLabs, que j’ai toujours le plaisir de revoir à St Barth.
Un beau matin d’hiver, je regarde mon code YAML gitops, relié à argoCD pour déploiement automatique sur kubenertes, pour déployer un cluster elasticsearch de 3 nodes tout simple, et je me dis “tiens si je changeais ce label: elastic.org/elasticsearch-cluster: hot en elastic.co/elasticsearch: hot” ça sera plus concis.
Je précise que le cluster tourne déjà en dev/prod.
L’idée de merde!!!!
Sur le papier pas de soucis, je change ce label:
- pour mes pods
- pour ma network-policy
donc ça devrait marcher.
Je git push, ça part sur argoCD qui lance la mise à jour des resources kubernetes. La network policy se met à jour, le 3ème pod ES se termine et se relance…. et la ….
Mon cluster de 3 pods se retrouvent dans un état quantique, 2 pods ont les anciens labels, et 1 pod a les nouveaux, la NP a les nouveaux, donc plus personne ne se comprend.
Mutable or immutable, this is the question
Un grand sage a dit:
“ton infra immutable sera”
“en gitops confiance tu as”
etc….
Solution immutable
Une solution serait de faire le déploiement en 3 étapes:
- la NP reste comme ça, je rajoute les nouveaux labels en plus des anciens aux pods
- je modifie la NP
- J’enlève les anciens labels des pods
Mouais bof, tout ça juste pour 2 labels à la con ….
Solution mutable
Vive la mutation!
- je rajoute les nouveaux labels
kubectl label — selector elastic.org/elasticsearch-cluster=hot pods elastic.co/elasticsearch=hot
2. je synchronise (partial synchro) juste la NP avec les nouveaux labels qui vont bien et je check que tout le monde va bien
3. je supprime les anciens labels qui ne sont plus nécessaires
kubectl label — selector elastic.co/elasticsearch=hot pods elastic.org/elasticsearch-cluster-
4. Je check que tout le monde va bien, au pire je peux remettre rapidement les anciens labels
— —
Ca demande un accès à l’API K8S bien sûr, et que votre application argoCD ne soit pas en auto-sync. L’idée est de travailler vite pour ne pas garder cet état trop longtemps.
Reste bien sûr à mettre à jour le StatefulSet par la suite, de façon classique avec argoCD, malheureusement ça fera un restart des pods pour rien.
Une bonne practice serait d’automatiser tout ça sous forme de script, lui même déployé par argoCD.
Façon de travailler
du dev vers la prod, petit conseil gratos:
Tel un ingénieur de la NASA, pensez toujours à partir en dev du même état que la prod, et notez quelque part toutes les étapes que vous réalisez (bonne ou mauvaise, ça évite de refaire des bétises).
Et pour l’histoire, écrivez une story Medium, il faut toujours laisser sa trace !
