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

Fault Injection, fiabilisez vos chaines d’appels

De part la nature sensible d’un déploiement d’application pour une mise en service en production les équipes doivent être préparées aux différentes pannes possibles. Ces pannes peuvent être prévus par des process afin de trouver des solutions de contournement. Afin de préparer ces process ou simplement de fiabiliser une application en cours de développement il est essentiel d’être préparé à un scéario anormal pour vérifier le comportement de l’applicatif.

Tester des cas d’erreurs sur des applications n’est jamais simple, tomber en erreur n’est pas une fonctionnalité. Tester le fonctionnement d’un service quand le suivant est inaccessible peut être réalisé en ne déployant pas le dit service ou en coupant un accès réseau. Mais tester les différents types d’erreurs HTTP ou encore le comportement en cas de réponse plus longue que d’habitude nécessite la mise en place de scenarii plus complexes. Istio et les service mesh apportent une solution qui permet d’injecter sur le réseau un certain nombre d’erreurs volontaires.

Injection de code HTTP

Le premier type d’injection de faute est le retour d’un code HTTP défini. Ce code retour est configuré sur une route, vous pourrez donc personnaliser sur quels appels il doit être fait. Istio vous demande le pourcentage de chance d’apparition de ce code. Ainsi vous pouvez par exemple tester votre politique de retry dans le cas où elle réussie à compenser une erreur (25% d’apparition) ou bien dans le cas où elle échoue (100% d’apparition).

Dans la section Retry il a été mentionné que le Retry était effectué sur certains codes HTTP. L’injection de faute par code HTTP est donc tout indiqué pour vérifier que la politique se déclenche uniquement lorsque cela est souhaité.

Pour configurer l’injection de faute, il suffit de se rendre sur le Virtual Service désiré et de modifier la route à tester ou bien de créer une route correspondant au cas à tester. Le cas du chapitre précédent consistait à faire planter le service workload2-service afin de tester la politique de retry de workload1-service.

La configuration ci dessous montre une injection de code erreur 504 (simulation d’un timeout) a hauteur de 50%.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: workload2-virtual-service
  namespace: workshop
spec:
  hosts:
  - workload2-service
  http:
  - fault:
      abort:
        httpStatus: 504
        percent: 50
    route:
    - destination:
        host: workload2-service
      weight: 100

La configuration suivante indique comment ajouter un délais de réponse sur une route. Meme fonctionnement que les codes erreurs, il suffit d’indiquer une valeur ainsi qu’un pourcentage d’apparition.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: workload2-virtual-service
  namespace: workshop
spec:
  hosts:
  - workload2-service
  http:
  - fault:
      abort:
        httpStatus: 504
        percent: 50
      delay:
        fixedDelay: 5s
        percent: 25
    route:
    - destination:
        host: workload2-service
      weight: 100

La gestion d’erreur devient ainsi plus simple à tester. Cependant, ce système ne permet pas de tester l’ensemble des cas. La gestion d’erreur applicative contrôlant des champs métier ne peut être testé ici. Istio ne permet pas de réaliser des bouchons de vos services. Cependant, rien n’empeche de créer un service bouchon et de modifier la route pour pointer vers les dits bouchons en fonction d’un header HTTP par exemple.