Déploiement Canary dans Kubernetes #3 : Istio

Utiliser Istio+Kiali pour lancer et visualiser un déploiement Canary

Articles de cette série

1. Déploiement Canary dans Kubernetes #1 : Gitlab CI
2. Déploiement Canary dans Kubernetes #2 : déploiements Argo
3. (Cet article)
4. Déploiement Canary à l'aide de Jenkins-X Istio Flagger

Déploiement canari

Nous espérons que vous lirez la première partie, où nous avons brièvement expliqué ce que sont les déploiements Canary et montré comment les implémenter à l'aide des ressources Kubernetes standard.

Istio

Et nous supposons qu’en lisant cet article vous savez déjà ce qu’est Istio. Si ce n'est pas le cas, vous pouvez lire à ce sujet ici.

Demande de tests

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

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

• frontend.yaml
• backend.yaml
• istio.yaml

Exécuter vous-même l'application de test

Si vous souhaitez suivre mon exemple et utiliser vous-même cette application de test, voir fichier Lisez-moi du projet.

Déploiement initial

Lorsque nous lançons le premier Déploiement, nous constatons que les pods de notre application n'ont que 2 conteneurs, c'est-à-dire que le side-car Istio vient d'être implémenté :

Et nous voyons également Istio Gateway Loadbalancer dans l'espace de noms istio-system:

Génération de trafic

Nous utiliserons l'adresse IP suivante pour générer du trafic qui sera reçu par les pods frontend et transmis aux 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 à notre fichier hosts.

Voir le maillage via Kiali

Nous avons installé l'application de test et Istio ainsi que Tracing, Grafana, Prometheus et Kiali (voir ci-dessous pour plus de détails). fichier Lisez-moi du projet). On peut donc utiliser Kiali via :

istioctl dashboard kiali # admin:admin

Kiali visualise le trafic actuel via Mesh

Comme nous pouvons le constater, 100 % du trafic va vers le service frontend, puis vers les pods frontend avec le label v1, puisque nous utilisons un simple proxy nginx qui redirige les requêtes vers le service backend, qui à son tour les redirige vers les pods backend. avec l'étiquette v1.

Kiali fonctionne très bien avec Istio et fournit une solution de rendu Mesh en boîte. Tout simplement génial.

Déploiement canari

Notre backend dispose déjà de deux déploiements k8, un pour la v1 et un pour la v2. Il ne nous reste plus qu'à dire à Istio de transférer un certain pourcentage de requêtes vers la v2.

Étape 1 : 10 %

Et tout ce que nous avons à 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

On constate que 10% des requêtes sont redirigées vers la v2.

Étape 2 : 50 %

Et maintenant, il suffit de l'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 de Canary peut désormais être considéré comme terminé et tout le trafic est redirigé vers la v2 :

Tester Canary manuellement

Disons que nous envoyons désormais 2 % de toutes les requêtes au backend v10. Que se passe-t-il si nous voulons tester manuellement la v2 pour nous assurer que tout fonctionne comme prévu ?

Nous pouvons ajouter une règle de correspondance 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

Maintenant, en utilisant curl, nous pouvons forcer une requête v2 en envoyant l'en-tête :

Les requêtes sans en-tête seront toujours pilotées par le ratio 1/10 :

Canary pour deux versions dépendantes

Nous allons maintenant considérer l'option où nous avons la version v2 pour le frontend et le backend. Pour les deux, nous avons précisé que 10 % du trafic devait aller vers la v2 :

Nous voyons que les frontends v1 et v2 transmettent tous deux le trafic dans un rapport de 1/10 par rapport aux backends v1 et v2.

Et si nous devions transférer le trafic du frontend-v2 uniquement vers le backend-v2 car il n'est pas compatible avec la v1 ? Pour ce faire, nous définirons un ratio de 1/10 pour le frontend, qui contrôle le trafic arrivant au backend-v2 à l'aide de la négociation. 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

En conséquence, nous obtenons ce dont nous avons besoin :

Différences par rapport à l’approche manuelle Canary

В la première partie Nous avons effectué le déploiement Canary manuellement, en utilisant également deux déploiements k8. Là, nous avons contrôlé le ratio de requêtes en modifiant le nombre de répliques. Cette approche fonctionne, mais présente de sérieux inconvénients.

Istio permet de déterminer le ratio de requêtes quel que soit le nombre de réplicas. Cela signifie, par exemple, que nous pouvons utiliser des HPA (Horizontal Pod Autoscalers) et n'avons pas besoin d'être configurés en fonction de l'état actuel du déploiement de Canary.

Total

Istio fonctionne très bien et son utilisation avec Kiali constitue une combinaison très puissante. Le prochain sur ma liste d'intérêts consiste à combiner Spinnaker avec Istio pour l'automatisation et l'analyse Canary.

Source: habr.com