Nous utiliserons le contrôleur de déploiement Argo Rollouts natif de k8s et GitlabCI pour exécuter les déploiements Canary sur Kubernetes.
Articles de cette série
- (Cet article)
- Déploiement Canary à l'aide d'Istio
- Déploiement Canary à l'aide de Jenkins-X Istio Flagger
Déploiement canari
Nous espérons que vous lirez , où nous avons brièvement expliqué ce que sont les déploiements Canary. Nous avons également montré comment l'implémenter à l'aide des ressources Kubernetes standard.
Déploiements Argo
Argo Rollouts est un contrôleur de déploiement natif Kubernetes. Il fournit un CRD (Custom Resource Definition) pour Kubernetes. Grâce à lui, nous pouvons utiliser une nouvelle entité : Rollout, qui gère les déploiements bleu-vert et canari avec diverses options de configuration.
Contrôleur Argo Rollouts utilisé par une ressource personnalisée
Rollout,Permet des stratégies de déploiement supplémentaires telles que bleu-vert et Canary pour Kubernetes. RessourceRolloutoffre une fonctionnalité équivalenteDeployment, uniquement avec des stratégies de déploiement supplémentaires.
ressourceDeploymentsdispose de deux stratégies de déploiement :RollingUpdateиRecreate. Bien que ces stratégies conviennent dans la plupart des cas, pour un déploiement sur des serveurs à très grande échelle, des stratégies supplémentaires sont utilisées, telles que bleu-vert ou canari, qui ne sont pas disponibles dans le contrôleur de déploiement. Pour utiliser ces stratégies dans Kubernetes, les utilisateurs devaient écrire des scripts en plus de leurs déploiements. Le contrôleur Argo Rollouts expose ces stratégies sous forme de paramètres simples, déclaratifs et configurables.
Il existe également Argo CI, qui fournit une interface Web pratique à utiliser avec les déploiements, nous y reviendrons dans le prochain article.
Installation des déploiements Argo
Du côté serveur
kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
Dans notre navet d'infrastructure (voir ci-dessous), nous avons déjà ajouté install.yaml sous le nom i/k8s/argo-rollouts/install.yaml. De cette façon, GitlabCI l'installera dans le cluster.
Côté client (plugin kubectl)
Exemple d'application
Il est recommandé de disposer de référentiels distincts pour le code d'application et l'infrastructure.
Référentiel pour l'application
Il s'agit d'une API Python+Flask très simple qui renvoie une réponse au format JSON. Nous allons construire le package à l'aide de GitlabCI et transférer le résultat vers le registre Gitlab. Dans le registre, nous avons deux versions différentes :
- wuestkamp/k8s-deployment-example-app:v1
- wuestkamp/k8s-deployment-example-app:v2
La seule différence entre eux est le fichier JSON renvoyé. Nous utilisons cette application pour visualiser le plus facilement possible avec quelle version nous communiquons.
Référentiel d'infrastructure
Dans ce référentiel, nous utiliserons GitlabCI pour le déploiement sur Kubernetes, .gitlab-ci.yml ressemble à ceci :
image: traherom/kustomize-dockerbefore_script:
- printenv
- kubectl versionstages:
- deploydeploy test:
stage: deploy
before_script:
- echo $KUBECONFIG
script:
- kubectl get all
- kubectl apply -f i/k8s only:
- masterPour l'exécuter vous-même, vous aurez besoin d'un cluster, vous pouvez utiliser Gcloud :
gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80Tu dois bifurquer et crée une variable KUBECONFIG dans GitlabCI, qui contiendra la configuration d'accès kubectl à votre cluster.
Vous pouvez découvrir comment obtenir les informations d'identification pour un cluster (Gcloud).
Infrastructure Yaml
Dans le référentiel d'infrastructure, nous avons le service :
apiVersion: v1
kind: Service
metadata:
labels:
id: rollout-canary
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalanceret rollout.yaml :
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
replicas: 10
revisionHistoryLimit: 2
selector:
matchLabels:
id: rollout-canary
template:
metadata:
labels:
id: rollout-canary
spec:
containers:
- name: rollouts-demo
image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
imagePullPolicy: Always
strategy:
canary:
steps:
- setWeight: 10
# Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
- pause: {}
- setWeight: 50
- pause: { duration: 120 } # two minutesRollout fonctionne de la même manière que le déploiement. Si nous ne définissons pas de stratégie de mise à jour (comme Canary ici), elle se comportera comme le déploiement de mise à jour continue par défaut.
Nous définissons deux étapes dans yaml pour le déploiement de Canary :
- 10 % du trafic vers Canary (attendre l'accord manuel)
- 50 % de trafic vers Canary (attendez 2 minutes puis continuez jusqu'à 100 %)
Effectuer le déploiement initial
Après le déploiement initial, nos ressources ressembleront à ceci :
Et nous obtenons une réponse uniquement à partir de la première version de l'application :
Effectuer un déploiement Canary
Étape 1 : 10 % de trafic
Pour démarrer un déploiement Canary, il suffit de changer la version de l'image comme nous le faisons habituellement avec les déploiements :
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
...
template:
metadata:
labels:
id: rollout-canary
spec:
containers:
- name: rollouts-demo
image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...Et nous poussons les changements, donc Gitlab CI se déploie et nous voyons les changements :
Maintenant, si nous accédons au service :
Super! Nous sommes au milieu de notre déploiement Canary. Nous pouvons voir les progrès en exécutant :
kubectl argo rollouts get rollout rollout-canary
Étape 2 : 50 % de trafic :
Passons maintenant à l'étape suivante : rediriger 50 % du trafic. Nous avons configuré cette étape pour qu'elle soit exécutée manuellement :
kubectl argo rollouts promote rollout-canary # continue to step 2
Et notre application a renvoyé 50 % des réponses des nouvelles versions :
Et revue du déploiement :
Super.
Étape 3 : 100 % de trafic :
Nous l'avons configuré pour qu'après 2 minutes, l'étape 50 % se termine automatiquement et que l'étape 100 % démarre :
Et le résultat de l'application :
Et revue du déploiement :
Le déploiement de Canary est terminé.
Plus d'exemples avec les déploiements Argo
Il existe d'autres exemples ici, tels que la façon de configurer des aperçus et des comparaisons d'environnement basées sur Canary :
Vidéo sur les déploiements Argo et Argo CI
Je recommande vraiment cette vidéo, elle montre comment Argo Rollouts et Argo CI fonctionnent ensemble :
Total
J'aime beaucoup l'idée d'utiliser des CRD qui gèrent la création de types supplémentaires de déploiements ou de jeux de réplicas, redirigent le trafic, etc. Travailler avec eux se passe bien. Ensuite, j'aimerais tester l'intégration avec Argo CI.
Cependant, il semble y avoir une grande fusion entre Argo CI et Flux CI, donc je pourrais attendre la sortie de la nouvelle version : .
Avez-vous eu une expérience avec Argo Rollouts ou Argo CI ?
Lisez également d'autres articles sur notre blog:
Source: habr.com