Le déploiement d’applications avec Kubernetes est devenu de plus en plus populaire en raison de ses nombreux avantages. Kubernetes facilite la gestion des applications conteneurisées, en fournissant une plate-forme pour le déploiement, la mise à l’échelle et la gestion des applications. Avec Kubernetes, les applications peuvent être déployées rapidement et de manière cohérente dans différents environnements, y compris sur site et sur des plates-formes cloud.
Lors du déploiement d’applications avec Kubernetes, beaucoup d’entre nous auront des questions sur le type de déploiement à utiliser – roulant, bleu-vert, canari, etc. Dans cet article, nous discuterons de ces types de déploiement (canari, roulant et bleu-vert), comment ils fonctionnent et lequel choisir.
Déploiement canari
Le déploiement Canary de Kubernetes est une technique permettant de déployer de nouvelles fonctionnalités ou modifications sur un petit sous-ensemble d’utilisateurs ou de serveurs avant de publier la mise à jour sur l’ensemble du système. Cela se fait en créant un nouveau jeu de répliques avec la version mise à jour du logiciel tout en conservant le jeu de répliques d’origine en cours d’exécution. Un petit pourcentage du trafic est ensuite acheminé vers le nouveau jeu de répliques, tandis que la majorité du trafic continue d’être desservie par le jeu de répliques d’origine. Cela permet de tester la nouvelle version dans un environnement réel tout en minimisant le risque de problèmes affectant l’ensemble du système. Si des problèmes sont détectés lors du déploiement Canary, il peut être rapidement restauré vers le jeu de réplicas d’origine. Les déploiements Canary sont un outil précieux pour minimiser les risques et garantir une haute disponibilité dans les systèmes distribués complexes, en permettant des tests contrôlés des modifications avant qu’elles ne soient publiées sur l’ensemble du système.
Voici un exemple de fichier YAML de déploiement Canary dans Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp:v1
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
Dans cet exemple, nous déployons un déploiement Kubernetes qui créera trois répliques de notre application. Le déploiement utilise un sélecteur pour trouver les pods appropriés à gérer en fonction de l’étiquette application : mon application.
La section de modèle spécifie la configuration des pods créés par le déploiement. Dans ce cas, nous exécutons un seul conteneur dans chaque pod, qui est spécifié avec le champ containers. L’image de conteneur utilisée est monapp:v1qui est la première version de notre application.
Nous avons également ajouté deux sondes au conteneur pour vérifier son état. Le état de préparationProbe vérifie si le conteneur est prêt à recevoir du trafic, et le vivacitéSonde vérifie si le conteneur est toujours en cours d’exécution. Si l’une de ces sondes échoue, le pod sera redémarré.
Pour effectuer un déploiement Canary, nous créons un deuxième fichier YAML de déploiement qui spécifie la nouvelle version de l’application, par exemple, monapp:v2. Nous mettrons ensuite à jour le déploiement d’origine pour mettre en place un test canary en faisant évoluer les répliques de la nouvelle version à 1 tout en gardant les répliques de l’ancienne version à 2.
Une fois la nouvelle version en cours d’exécution, nous pouvons la tester pour nous assurer qu’elle fonctionne correctement. Si tout semble bon, nous pouvons mettre à jour le déploiement d’origine pour augmenter les répliques de la nouvelle version et réduire progressivement les répliques de l’ancienne version.
Cela entraînera le passage progressif d’un petit pourcentage du trafic de l’ancienne version à la nouvelle version jusqu’à ce que tout le trafic soit dirigé vers la nouvelle version. Si des problèmes surviennent avec la nouvelle version, nous pouvons rapidement revenir à l’ancienne version en inversant le processus.
Déploiement progressif
Le déploiement progressif de Kubernetes est une stratégie de mise à jour et de déploiement de nouvelles versions de logiciels de manière contrôlée et progressive. Au lieu de déployer toutes les mises à jour en même temps, Kubernetes déploie les modifications de manière incrémentielle, réduisant ainsi le risque de temps d’arrêt et permettant des retours en arrière faciles en cas d’erreurs. Le déploiement progressif implique la création d’un nouveau jeu de répliques avec la version mise à jour du logiciel tout en réduisant progressivement l’ancien jeu de répliques. Cela permet de déployer la nouvelle version pendant que l’ancienne version est toujours en cours d’exécution, garantissant ainsi qu’il n’y a pas d’interruption de service. Une fois la nouvelle version entièrement déployée, l’ancien jeu de répliques est supprimé et le déploiement est terminé. Le déploiement progressif de Kubernetes est essentiel pour garantir une disponibilité et une fiabilité élevées dans les systèmes distribués complexes.
Voici un exemple de fichier YAML de déploiement progressif dans Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp:v1
ports:
- containerPort: 8080
Dans cet exemple, nous déployons un déploiement Kubernetes qui créera trois répliques de notre application. Le déploiement utilise un sélecteur pour trouver les pods appropriés à gérer en fonction de l’étiquette application : mon application.
La section stratégie spécifie la stratégie que Kubernetes doit utiliser pour mettre à jour le déploiement. Dans ce cas, nous utilisons une stratégie RollingUpdate. Cela signifie que Kubernetes mettra progressivement à jour le déploiement en remplaçant les anciennes répliques par de nouvelles répliques.
Le maxSurge et maxIndisponible les champs contrôlent le processus de mise à jour progressive. maxSurge détermine le nombre maximum de répliques pouvant être créées au-delà du nombre de répliques souhaité, et maxIndisponible détermine le nombre maximum de répliques qui peuvent être indisponibles pendant la mise à jour.
La section de modèle spécifie la configuration des pods créés par le déploiement. Dans ce cas, nous exécutons un seul conteneur dans chaque pod, qui est spécifié avec le champ containers. L’image de conteneur utilisée est monapp:v1qui est la première version de notre application.
Pour mettre à jour le déploiement, nous créons un nouveau fichier YAML de déploiement qui spécifie la nouvelle version de l’application, par exemple, monapp:v2. Nous mettrons ensuite à jour le déploiement d’origine pour qu’il pointe vers le nouveau fichier YAML.
Une fois la mise à jour lancée, Kubernetes remplacera progressivement les anciennes répliques par de nouvelles jusqu’à ce que toutes les répliques exécutent la nouvelle version. Le processus de mise à jour progressive permet d’effectuer les mises à jour avec un minimum de perturbations pour les utilisateurs, car il garantit toujours qu’au moins une réplique de l’ancienne version est en cours d’exécution pendant le déploiement de la nouvelle version.
Stratégie de déploiement bleu-vert
La stratégie de déploiement bleu-vert de Kubernetes est une technique permettant de publier de nouvelles versions d’une application afin de minimiser les temps d’arrêt et les risques. Il implique l’exécution de deux environnements identiques, l’un servant d’environnement de production actif (bleu) et l’autre de nouvelle version candidate (vert). La nouvelle version candidate est minutieusement testée avant d’être basculée dans l’environnement de production, ce qui permet une transition en douceur sans temps d’arrêt ni erreur.
Voici un exemple de fichier YAML pour un déploiement bleu-vert sur Kubernetes :
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
version: blue
spec:
containers:
- name: my-app
image: myregistry/my-app:blue
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
Dans cet exemple, nous définissons un déploiement pour une application appelée « mon-application » avec deux répliques. Le déploiement a un sélecteur d’étiquette de « application : mon-application« , qui correspondra au service correspondant qui achemine le trafic vers le déploiement.
Le premier modèle définit le « bleu » version de l’application. Elle est définie par le libellé « version : bleu« , ce qui permet d’identifier facilement la version actuellement en production. L’image du conteneur pour cette version est extraite du registre Docker à « monregistre/mon-app:bleu« .
Lorsqu’une nouvelle version est prête, un nouveau modèle est ajouté avec le libellé « version : vert« . Ce nouveau modèle aura une image de conteneur mise à jour avec la nouvelle version de l’application. Une fois ce nouveau modèle créé et prêt à être publié, le service Kubernetes peut être mis à jour pour acheminer le trafic vers le nouveau « vert » déploiement.
Cette stratégie de déploiement bleu-vert garantit que la nouvelle version de l’application peut être entièrement testée avant sa sortie, sans temps d’arrêt ni erreur.
Lequel devriez-vous choisir ?
Le choix de la stratégie de déploiement de Kubernetes dépend des besoins et des exigences spécifiques de l’application ou du service déployé.
UN cstratégie de déploiement anaire est généralement utilisé lors du déploiement de nouvelles fonctionnalités ou mises à jour sur un sous-ensemble d’utilisateurs ou de serveurs pour les tester dans un environnement réel et est souvent utilisé pour les applications qui nécessitent des mises à jour fréquentes. Cette stratégie permet de tester de nouvelles fonctionnalités avec un impact minimal sur l’environnement de production et peut aider à identifier les problèmes avant qu’ils n’affectent l’ensemble du système.
UN rstratégie de déploiement de roulement est idéal pour les applications qui ne nécessitent aucun temps d’arrêt pendant le déploiement. Cela implique de déployer progressivement de nouvelles versions d’une application tout en s’assurant que l’ancienne version est toujours en cours d’exécution, ce qui réduit le risque de temps d’arrêt et permet des retours en arrière faciles en cas de problème.
UN bstratégie de déploiement verte est utile pour les applications où les temps d’arrêt sont acceptables mais doivent être minimisés. Il s’agit d’exécuter deux environnements identiques, l’un servant d’environnement de production actif et l’autre…