Article

CI/CD sur Kubernetes : changer de version sans tout casser

Rolling, blue/green, canary : comment remplacer une version en douceur.

CI/CD sur Kubernetes : changer de version sans tout casser

Sur Kubernetes, tu ne "copies" pas un fichier sur un serveur. Tu remplaces des pods (petites boites) pendant que le service continue.

Schema strategies de deploiement Kubernetes — Rolling, blue/green, canary et rollback.

Trois strategies en francais

Rolling : on remplace peu a peu. Simple et courant.
Blue/Green : deux versions cote a cote, on bascule le trafic d'un coup.
Canary : on envoie un petit pourcentage d'utilisateurs sur la nouveaute.

Toujours prevoir un rollback (revenir en arriere) et des sondes (est-ce que l'app repond ?). Voir aussi Deployments et Services.

Articles recommandés

Apres le deploiement : voir si ca va vraiment bien

Logs, mesures et alertes utiles pour savoir si la nouvelle version tient la route.

Versions et retours arriere : livrer sans paniquer

Tags, releases et rollback : savoir exactement ce qui tourne, et revenir vite.

GitOps : le cluster suit Git (pas l'inverse)

Argo CD ou Flux : deployer en declarant l'etat souhaite dans un depot Git.

GitLab CI : des etapes claires jusqu'au deploiement

Stages, cache et deploiement : une pipeline GitLab simple a suivre.