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

Adapter votre projet existant pour être géré par Istio en service mesh

Considérons un projet simple dans l’exemple qui suit. Un micro service exposant une API REST sur un port. Cette API peut être mise à l’échelle, être exposée en interne et en externe. Je mets de coté l’aspect sécurité pour l’instant, nous y reviendrons dans une section ultérieure.

Cette API expose entre autre un endpoint /hello répondant une chaine de caractère. Nous appellerons ce endpoint en fin de configuration pour vérifier que tout est correct.

Pour rappel, pour que Istio gère votre application, un sidecar Envoy doit être injecté. Le premier point à vérifier est comment Istio doit être configuré pour gérer le namespace en tant que service mesh, cela peut différer d’une distribution Kubernetes à une autre.

Différentes étapes sur différentes distributions Kubernetes

Avec Rancher par exemple, vous configurez l’injection sur un namespace et le sidecar est automatiquement ajouté.

Avec Openshift, cela requiert deux étapes supplémentaires.

• Configurer le namespace dans le composant « ServiceMeshMemberRoll » de l’opérateur RedHat Service Mesh au sein du namespace « istio-system »
• Ajouter une annotation sur votre déploiement YAML pour demander l’injection du sidecar Envoy.

spec:
  replicas: 1 
  selector: 
    matchLabels: 
      app: workload1 
      version: 0.1 
  template: 
    metadata: 
      creationTimestamp: null 
      labels: 
        app: workload1 
        version: 0.1
      annotations: 
        sidecar.istio.io/inject: 'true' 

Les pods déployés doivent être identifiables facilement par des labels, à la fois pour la configuration de vos services via les attributs selector, mais aussi pour la visualisation de votre mesh. L’outil Kiali vous permet d’avoir une cartographie de votre service mesh et pour cela, il s’appuie sur deux labels :

• app
• version

Chaque déploiement de matière doit posséder ces deux attributs au minimum. Ils doivent être présent sur le Pod mais aussi le service associé pour le label « app ».

Si tout est bien configuré, vos pods devraient être re-déployés avec un nouveau conteneur nommé « istio-proxy » :

Vous pouvez également vérifier que l’application Kiali génère correctement le graphe de votre service mesh avec l’ensemble de vos applications actives. L’outil utilise le label « app » pour grouper les composants et le label « version » pour distinguer les différentes versions de votre application.

Ajouter les trois briques de bases

Maintenant que votre projet fait partie d’un service mesh il reste à ajouter trois types d’objets apportés par Istio afin d’avoir la vision de l’interaction réseau entre un utilisateur et votre matière applicative.

Gateway, le point d’entrée depuis l’exterieur vers votre Service Mesh

Le premier élément de la chaine pour gérer un appel depuis l’extérieur est la Gateway. Kubernetes propose l’objet Ingress pour exposer des services internes au cluster vers l’extérieur. Istio propose le meme composant mais permettant l’exposition du service mesh à l’extérieur.

En prérequis, votre domaine devra pointer vers un node avec le NodePort utilisé par Istio pour l’entrée des flux (ou vers un Load Balancer qui redirigera vers le/les nodes et le port configuré) vers votre Service Mesh.
Pour les utilisateur d’OpenShift il vous faudra créer une route dans le namespace istio-system qui pointe vers le service istio-ingressgateway.

kind: Gateway
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: workshop-app-gateway
  namespace: workshop
spec:
  servers:
    - hosts:
        - myworkshop-app.abcdefab.net
      port:
        name: http
        number: 80
        protocol: HTTP
  selector:
    istio: ingressgateway

Le code ci dessus permet de définir une configuration de Gateway sur le service ingressgateway d’istio (via le selector) qui va écouter les appels dont le nom de domaine d’origine est « myworkshop-app.abcdefab.net« . Cette configuration ne s’occupe pas de diriger l’appel vers une quelconque matière applicative, simplement de déclarer un point d’entrée dans le service mesh.

Destination Rule, la configuration générale de votre service interne

Seconde brique à ajouter : la Destination Rule. Cet objet va permettre de définir un certain nombre de paramètre en fonction d’un nom d’hôte. Si le service Kubernetes déclaré pour contacter notre matière applicative s’appelle « workload1-service », l’objet Destination Rule va permettre de définir des règles qui seront exécutées dès lors qu’une connexion à « workload1-service » sera initiée.

Sur cet objet que nous verrons plus en détail dans une section ultérieure vous pourrez définir

• La stratégie de LoadBalancing vers votre service
• La configuration d’un Circuit Breaker pour protéger votre service
• Le paramétrage du chiffrement des communications de votre service
• La déclaration de sous ensemble de votre matière application, le plus courant étant le groupement par version

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

Sur cet exemple, l’objet « workload1-destination-rule » va concerner le service « workload1-service ». Nous déclarons que pour ce service, la stratégie de Load Banlancing doit être l’appel vers le pod le moins sollicité. Nous déclarons également qu’il existe un seul sous ensemble de pods nommé « v1 » dont le groupement se fera par le label « version » avec la valeur « v1 ».

Virtual Service, paramétrer les routes et le comportement de votre service

Le service virtuel va s’appuyer sur les deux éléments précédemment décrits pour vous permettre de personnaliser différents éléments de votre service kubernetes :

• Règles de routages offrant la possibilité d’un Load Balancing manuel
• Politique de retry
• Timeout

D’autres elements sont disponibles sur les Virtual Service qui vous permettront de tester la résilience de votre chaine d’appel :

• Injection de faute
• Ajout d’un délais dans la réponse

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

La configuration ci dessus permet de déclarer un service virtual service permettant :

• De traiter les appels à destination « workload1-service » ou « myworkshop-app.abcdefab.net » selon si l’appel est interne ou externe
• Depuis la gateway interne « mesh » gérée de base par Istio ou depuis la gateway créée par nous même « workshop-app-gateway » qui écoute les appels vers « myworkshop-app.abcdefab.net »
• De connecter ces appels au service voulu par une « route » par defaut
  • La destination sera « workload1-service »
  • Sur les pods du sous ensemble « v1 » défini dans l’objet Destination Rule

Votre projet devrait maintenant être prêt. Vous pouvez vérifier qu’en faisant un appel depuis l’extérieur vers votre service, le graphique de l’application Kiali vous permet de visualiser les flux. De même via un autre pod déployé dans un namespace différent, l’appel est bien tracé.