Implémenter la résilience de l’infrastructure avec Kubernetes
Pour implémenter la résilience basée sur l’infrastructure, vous pouvez utiliser un maillage de service. Outre la résilience sans modifier le code, une maille de service fournit la gestion du trafic, la stratégie, la sécurité, une identité forte et l’observabilité. Votre application est découplée de ces fonctionnalités opérationnelles, qui sont déplacées vers la couche infrastructure. Architecturalement, un maillage de service se compose de deux composants : un plan de contrôle et un plan de données.
Le composant de plan de contrôle comporte de nombreux composants qui prennent en charge la gestion du maillage de service. L’inventaire des composants inclut généralement les éléments suivants :
- Interface de gestion, qui peut être une interface utilisateur ou une API.
- Règles et définitions de stratégie qui définissent la façon dont le maillage de service doit implémenter des fonctionnalités spécifiques.
- Gestion de la sécurité pour les éléments tels que l’identité forte et les certificats pour mTLS.
- Métriques ou observabilité pour collecter et agréger des métriques et des données de télémétrie à partir des applications.
Le composant de plan de données se compose de proxys qui sont injectés de manière transparente à côté de chaque service ; il s’agit du modèle Sidecar. Chaque proxy est configuré pour contrôler le trafic réseau entrant et sortant du pod qui contient votre service. Cette configuration permet à chaque proxy d’être configuré pour :
- Sécuriser le trafic via mTLS.
- Acheminer dynamiquement le trafic.
- Appliquez des stratégies au trafic.
- Collectez les métriques et les informations de suivi.
Certaines options de maillage de service populaires pour les clusters Kubernetes incluent Linkerd, Istio et Consul. Ce module se concentre sur Linkerd. Le diagramme suivant illustre les interactions entre les composants dans les plans de données et de contrôle :
Comparaison avec les approches basées sur le code
La stratégie principale de gestion des erreurs de Linkerd comprend des retries et des timeouts. Étant donné que Linkerd a une vue systémique de l’ensemble du cluster, il peut utiliser des stratégies de résilience de manière inédite. Par exemple, une nouvelle tentative consiste à ajouter un maximum de 20 % de charge supplémentaire sur le service cible. La vue basée sur les métriques de Linkerd lui permet de s’adapter dynamiquement aux conditions de cluster en temps réel. Cette approche ajoute une autre dimension à la gestion du cluster, mais n’ajoute aucun code.
Avec une approche basée sur le code, par exemple avec Polly, vous :
- Sont nécessaires pour deviner les paramètres de nouvelle tentative et de délai d’attente appropriés.
- Concentrez-vous sur une requête HTTP spécifique.
Il n’existe aucun moyen raisonnable de répondre à une défaillance d’infrastructure dans le code de votre application. Tenez compte des centaines ou des milliers de demandes en cours de traitement simultanément. Même une nouvelle tentative avec une interruption exponentielle (nombre de requêtes) peut inonder un service.
En revanche, les approches basées sur l’infrastructure comme Linkerd ne connaissent pas le fonctionnement interne de l’application. Par exemple, les transactions de base de données complexes sont invisibles pour Linkerd. Ces transactions peuvent être protégées contre l’échec avec Polly.
Dans les unités à venir, vous allez implémenter la résilience pour le service de coupon à l’aide de Polly et Linkerd.