🥇Déploiement Canary dans Kubernetes #3 : Istio

Utilisation d'Istio+Kiali pour le déploiement et la visualisation des déploiements Canary

Articles de ce cycle

Déploiement Canary dans Kubernetes #1 : Gitlab CI
Déploiement Canary dans Kubernetes #2 : Argo Rollouts
(cet article)
Déploiement Canary utilisant Jenkins-X Istio Flagger

Déploiement Canary

Nous espérons que vous avez lu la première partie, où nous expliquions brièvement ce qu'est le déploiement Canary et montrions comment le réaliser à l'aide des ressources standard de Kubernetes.

Istio

Et nous supposons qu'en lisant cet article, vous savez déjà ce qu'est Istio. Sinon, vous pouvez lire à son sujet ici.

Application pour les tests

Chaque pod contient deux conteneurs : notre application et istio-proxy.

Nous utiliserons une simple application de test avec des pods frontend-nginx et backend en python. Le pod avec nginx redirigera simplement chaque requête vers le pod avec le backend et fonctionnera comme un proxy. Les détails peuvent être consultés plus en détail dans les yamls suivants :

Lancement de l'application de test par soi-même

Si vous souhaitez suivre mon exemple et utiliser cette application de test par vous-même, voir le readme du projet.

Déployment initial

Lors du lancement du premier déploiement, nous voyons que les pods de notre application ont seulement 2 conteneurs, c'est-à-dire qu'Istio sidecar est encore en phase d'intégration :

Et nous voyons également le Loadbalancer Istio Gateway dans le namespace istio-system:

Création de trafic

Nous allons utiliser l'IP suivante pour générer du trafic, qui sera accepté par les pods frontend et redirigé vers les pods backend :

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Nous ajouterons également frontend.istio-test dans notre fichier hosts.

Visualisation du Mesh via Kiali

Nous avons installé l'application de test et Istio avec Tracing, Grafana, Prometheus et Kiali (voir plus en détail le readme du projet). Par conséquent, nous pouvons utiliser Kiali via :

istioctl dashboard kiali # admin:admin

Kiali visualise le trafic actuel à travers le Mesh

Comme nous le voyons, 100 % du trafic parvient au service frontend, puis au pod du frontend avec l'étiquette v1, car nous utilisons un proxy nginx simple qui redirige les requêtes vers le service backend, qui à son tour les redirige vers les pods backend avec l'étiquette v1.

Kiali fonctionne parfaitement avec Istio et offre une solution prête à l'emploi pour visualiser le Mesh. C'est vraiment fantastique.

Déploiement Canary

Notre backend a déjà deux déploiements k8s, un pour v1 et un pour v2. Maintenant, il nous suffit de dire à Istio de rediriger un certain pourcentage des requêtes vers v2.

Étape 1 : 10%

Et tout ce que nous devons faire est d'ajuster le poids du VirtualService dans istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Nous voyons que 10% des demandes sont redirigées vers v2.

Étape 2 : 50%

Et maintenant, il suffit d'augmenter à 50 % :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Étape 3 : 100%

Le déploiement Canary peut maintenant être considéré comme terminé et tout le trafic est redirigé vers v2 :

Test manuel du Canary

Supposons qu'actuellement nous envoyons 10 % de toutes les demandes vers le backend v2. Que faire si nous souhaitons tester manuellement v2 pour nous assurer que tout fonctionne comme prévu ?

Nous pouvons ajouter une règle correspondante spéciale, basée sur les en-têtes HTTP :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Nous pouvons maintenant forcer la demande vers v2 en envoyant l'en-tête avec curl :

Les demandes sans en-tête seront toujours gérées avec un ratio de 1/10 :

Canary pour deux versions dépendantes

Considérons maintenant un cas où nous avons une version v2 pour le frontend et le backend. Pour les deux, nous avons spécifié que 10 % du trafic doit aller vers v2 :

Nous constatons que les frontends v1 et v2 redirigent tous deux le trafic dans un ratio de 1/10 vers les backends v1 et v2.

Que faire si nous devions rediriger le trafic de frontend-v2 uniquement vers backend-v2, car il n'est pas compatible avec v1 ? Pour cela, nous établirons un ratio de 1/10 pour le frontend, qui contrôle quel trafic va vers backend-v2 en utilisant des correspondances par sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Nous obtenons donc ce dont nous avons besoin :

Différences par rapport à l'approche manuelle de Canary

Dans de la première partie Nous avons réalisé le déploiement Canary manuellement, en utilisant également deux déploiements k8s. Nous gérions le ratio de requêtes en modifiant le nombre de réplications. Cette approche fonctionne, mais présente des inconvénients majeurs.

Istio permet de définir le ratio de requêtes indépendamment du nombre de réplications. Cela signifie, par exemple, que nous pouvons utiliser des HPAs (Horizontal Pod Autoscalers — mise à l'échelle horizontale des pods) sans avoir à les configurer en fonction de l'état actuel du déploiement Canary.

Conclusion

Istio fonctionne très bien et en l'utilisant avec Kiali, nous obtenons une combinaison très puissante. La prochaine chose qui m'intéresse est la combinaison de Spinnaker avec Istio pour l'automatisation et l'analyse Canary.

Source : habr.com