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

Retry – Parce que votre réseau peut être ponctuellement occupé

Dans cette section nous allons parler de la mise en place de mécanisme de Retry et la configuration de timeout. Istio proposant ces deux fonctions cela vous évite de devoir les implémenter sur chaque appel dans le code de vos applications.

Le retry comme son nom l’indique est un mécanisme qui va rejouer une requête en cas de retour en erreur. Cela permet de palier une indisponibilité ponctuelle du réseau et donne une deuxième chance au service de répondre correctement. Ce mécanisme ne doit pas etre activé sur toutes les erreurs. Certaines erreurs sont souhaitées et sont claires. Vous ne voulez pas que le retry se déclenche sur une erreur 404 indiquant qu’il n’y a pas de résultat ou bien sur une erreur 500 indiquant un problème technique sur le serveur distant. Cependant, sur des erreurs d’infra réseau comme une 502 Gateway ou une 504 Timeout le mécanisme peut s’avérer utile. Cette granularité est paramétrée via l’attribut retryOn.

Pour l’exemple nous allons déployer deux nouvelles applications, workload2 et workload3 avec leur service associé workload2-service et workload3-service. Nous allons réaliser une chaine d’appel et faire planter un des services pour déclencher le retry.

Le paramétrage du retry se fait au niveau du Virtual Service sur une ou plusieurs routes.

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
  - retries:
      attempts: 3
      perTryTimeout: 2s
      retryOn: 5xx #Cette directive indique au proxy Envoy sur quel type d'erreur le retry doit être effectué.
    route:
    - destination:
        host: workload1-service
        subset: v1
      weight: 70
    - destination:
        host: workload1-service
        subset: v1b
      weight: 30

Nous avons placé le retry sur la route par defaut. Après declenchement d’une erreur au niveau de workload2-service, le retour est toujours OK, car un retry a été effectué par workload1-service.

Regardons les traces d’appels avec Jaeger.

Jaeger nous montre qu’il y a eu un problème sur workload1 lors de l’appel à workload2-service. La trace montre également un rejeu qui a été effectué avec succès.

Timeout – Adaptez l’attente à vos services

Il est courant de paramétrer dans une application la durée du timeout pour un appel distant. Istio propose encore une fois de gérer ce paramètre sur la couche infrastructure réseau, permettant une modification rapide sans impact applicatif. En cas de dépassement de la durée définie, Istio renvoie une erreur 504 Gateway timeout.

Comme pour le Retry, le timeout se paramètre dans le Virtual Service. Pour le test suivant nous allons paramétrer une valeur de timeout très basse (1ms) pour déclencher l’erreur. La méthode impactée sera l’appel avec le préfixe /v1b/.

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
    timeout: 1ms
  - retries:
      attempts: 3
      perTryTimeout: 2s
      retryOn: 5xx
    route:
    - destination:
        host: workload1-service
        subset: v1
      weight: 70
    - destination:
        host: workload1-service
        subset: v1b
      weight: 30

Ce chapitre vous aura fait découvrir comment laisser la couche infrastructure se charger de la résilience de la chaine d’appel. Pour réaliser certains tests de cette section, des erreurs ont dû être générées. Elles ne l’ont pas été par les applications elles mêmes, mais par la couche infrastructure à la demande. La prochaine section traitera donc des injections d’erreurs.