Istio & Service Mesh – Contrôlez et tunez les flux entre vos micro services

Load Balancing – Canary release et A/B testing pour tous

La configuration de votre projet est maintenant terminée, nous allons pouvoir nous intéresser aux fonctionnalités offertes par Istio et les Service Mesh. Nous verrons dans cette section la partie Load Balancing sur deux niveaux : global et par route.

Afin de répartir la charge sur votre matière applicative, Kubernetes permet déjà de faire du load balancing entre un service et un ensemble de pods. Istio va permettre de customiser le comportement de ce Load Balancing, mais également d’aller plus loin.

Load Balancing global

Via l’objet Destination Rule, vous allez pouvoir préciser à Istio le comportement souhaité sur le Load Balancing entre les différents pods. Deux principaux types sont disponibles :

• Répartition aleatoire
• Répartition avec affinité de session

Sur la répartition aleatoire plusieurs algoritmes sont disponibles

• Round Robin où chaque pod va recevoir tour à tour une requete
• Random
• Least connection où le pod le moins sollicité recevra la nouvelle requete

Et concernant la répartition avec affinité de session Istio va pouvoir se baser sur plusieurs éléments pour rediriger un utilisateur sur le même pod ce qui vous sera utile dans le cas de pods Stateful :

• IP Source
• Header HTTP
• Cookie

Exemple de configuration de l’objet Destination Rule pour une configuration de Load Balancing sur le pod le moins sollicité.

spec:
  host: workload1-service
  subsets:
  - labels:
      version: v1
    name: v1
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN

Load Balancing manuel

Le Load Balancing manuel d’Istio permet de paramétrer différentes routes pour une requête donnée.
Cette fonctionnalité sera très utile si vous désirez lancer une campagne d’A/B testing par exemple et rediriger un certain pourcentage de vos utilisateurs vers une version possèdent une nouvelle fonctionnalité de votre service/application.
Cette fonctionnalité peut également pour permettre un déploiement Canary de manière sécurisée avec une ouverture progressive du service sur la nouvelle version de votre application. En cas de problème il vous suffira de remettre la configuration initiale pour rediriger vos utilisateurs vers la matière fonctionnelle.

Avec Istio vous pouvez

• Répartir selon un pourcentage souhaité une requête vers plusieurs versions d’une application
• Identifier des requêtes HTTP et les rediriger vers un service ou une version de service
  • En fonction de l’URI demandée
  • En fonction d’un header HTTP
  • Du verbe HTTP de la requête

La prise en compte de la configuration est quasiment immédiate, dans la minute vos requêtes sont redirigées avec le paramétrage demandé.

Une version « 0.1b » de « workload1 » a été déployée. La modification consiste à changer la chaine de caractère retourné par le endpoint « /hello ». Nous allons ajuster la configuration pour que 30% de nos appels soient redirigés vers cette nouvelle version.

Ajout du subset a l’objet Destination Rule

Premièrement, nous allons déclarer un nouveau sous ensemble de version de pod pour ce service dans l’objet Destination Rule

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: workload1-destination-rule
  namespace: workshop
spec:
  host: workload1-service
  subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v1b
    name: v1b
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN

Configuration des routes dans le Virtual Service

Ensuite, nous allons ajouter la règle de répartition de requete dans notre Virtual Service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: workload1-virtual-service
  namespace: workshop
spec:
  gateways:
  - mesh
  - workshop-app-gateway
  hosts:
  - workload1-service
  - myworkshop-app.abcdefab.net
  http:
  - route:
    - destination:
        host: workload1-service
        subset: v1
      weight: 70
    - destination:
        host: workload1-service
        subset: v1b
      weight: 30

Réalisons quelques appels et vérifions dans Kiali ce qu’il se passe.

Le Virtual service peut aussi être paramétré en fonction d’éléments de la requête d’entrée pour rediriger sur un service ou une version souhaitée. Par exemple si un utilisateur ajoute /v1b/hello on souhaite le rediriger vers la version 1b. Notre application va recevoir la requête sur /v1b/hello, mais est configurée pour écouter sur /hello. Une règle de rewrite devra être ajoutée pour que l’appel fonctionne.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: workload1-virtual-service
  namespace: workshop
spec:
  gateways:
  - mesh
  - workshop-app-gateway
  hosts:
  - workload1-service
  - myworkshop-app.abcdefab.net
  http:
  - match:
    - uri:
        prefix: /v1b/
    rewrite:
      uri: /
    route:
    - destination:
        host: workload1-service
        subset: v1b
      weight: 100
  - route:
    - destination:
        host: workload1-service
        subset: v1
      weight: 70
    - destination:
        host: workload1-service
        subset: v1b
      weight: 30