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

Circuit Breaker – Fail fast and gracefuly

Plus vous allez avoir de composants dans votre chaine de liaison, plus il y aura de risque d’erreur. Il existe plusieurs patterns afin de contourner un problème dans la chaine de liaison. Ces patterns peuvent être implémentés manuellement dans du code mais modifier la matière applicative peut se révéler couteux et pas très flexible. Afin de ne pas avoir à intervenir sur chaque base de code de votre application, Istio permet de mettre en place des mécanismes de résilience au niveau infrastructure. Dans cette section, nous allons voir comment fonctionne les circuits breaker, retry et timeout.

Istio permet de configurer un Circuit breaker au niveau de l’objet Destination Rule qui concerne donc l’ensemble des pods d’un service. La configuration se fait sur deux points principaux de votre service mesh.

La protection d’une surcharge de votre service avec

• Le paramétrage d’un nombre maximum de requête en cours de traitement
• Le nombre maximum de requêtes par connexion

La surveillance en continue des réponses envoyées par vos pods

• Nombre d’erreurs consécutives
• Intervalle des erreurs remontées
• Durée d’expulsion du pool

Si un pods répond trop souvent en erreur, il est exclu pendant une durée déterminée afin de laisser uniquement les pods sains répondre.

En cas d’erreur, le circuit breaker remonte une erreur 503 indiquant une indisponibilité du service. Cette erreur va permettre au client de recevoir une réponse immédiate (au lieu d’attendre le retour en erreur) et éviter de surcharger une matière déjà en erreur.

L’ajout d’un circuit breaker permet d’adopter une stratégie de repli

• Dans le cas du fail fast, répondre rapidement qu’une erreur est survenue
• Un Fallback permettant d’appeler un service secondaire afin de retourner une information dégradée le tout dans un temps de réponse acceptable

Application sur workload 1

Reprenons l’exemple de notre workload1. Afin de déclencher l’ouverture du circuit, nous allons volontairement paramétrer des métriques très basses. La configuration suivante permet de n’autoriser qu’une seule requête en cours et une seule requête par connexion. Nous utiliserons l’outil Fortio pour simuler une montée en charge sur le service.

spec:
  host: workload1-service
  subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v1b
    name: v1b
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        http2MaxRequests: 1
        maxRequestsPerConnection: 1
        maxRetries: 1024
      tcp:
        maxConnections: 1024
    loadBalancer:
      simple: LEAST_CONN
    outlierDetection:
      baseEjectionTime: 30s
      consecutiveErrors: 5
      interval: 10s
      maxEjectionPercent: 10

Dès la configuration mise en place vous pourrez noter que l’outil Kiali ajoute un petit éclair à côté des éléments protégés par le circuit breaker.

Déclenchons l’ouvrture du circuit breaker

Si nous ouvrons l’outil Jaeger d’analyse de trace, nous voyons l’erreur 503 ainsi que le flag de réponse « UO » indiquant un Upstream Overflow