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 services. Outre la résilience sans modification du code, un maillage de services fournit la gestion du trafic, la stratégie, la sécurité, l’identité forte et l’observabilité. Votre application est dissociée de ces fonctionnalités opérationnelles, qui sont déplacées vers la couche d’infrastructure. De manière architecturale, un maillage de services est composé de deux composants : un plan de contrôle et un plan de données.
Le composant du plan de contrôle a de nombreux composants qui prennent en charge la gestion du maillage de services. L’inventaire des composants comprend généralement les éléments suivants :
- Une interface de gestion, qui peut être une interface utilisateur ou une API.
- Des règles et définitions de stratégie qui définissent la façon dont le maillage de services doit implémenter des fonctionnalités spécifiques.
- La gestion de la sécurité pour des éléments tels que l’identité forte et les certificats pour mTLS.
- Des mesures ou observabilité pour collecter et agréger des métriques et des données de télémétrie à partir des applications.
Le composant du plan de données est constitué de proxys injectés de manière transparente de concert avec chaque service ; cela s’appelle le modèle Side-car. 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 le trafic de manière dynamique
- appliquer des stratégies au trafic
- collecter les informations de métriques et de suivi.
Parmi les options de maillage de services populaires pour les clusters Kubernetes, citons Linkerd, Istio et Consul. Ce module porte sur Linkerd. Le diagramme suivant montre 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 principale stratégie de gestion des erreurs de Linkerd est les nouvelles tentatives et délais d’expiration. Étant donné que Linkerd a une vue système de l’ensemble du cluster, il peut utiliser des stratégies de résilience de façon innovante. Par exemple, utiliser une nouvelle tentative d’ajout d’une charge supplémentaire de 20 % au 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 pas de code.
Avec une approche basée sur le code, comme avec Polly, vous devez :
- deviner les paramètres de nouvelles tentatives et de délai d’attente appropriés
- vous concentrer sur une requête HTTP spécifique.
Il n’existe aucun moyen raisonnable de répondre à une défaillance de l’infrastructure dans le code de votre application. Tenez compte des centaines ou des milliers de requêtes qui sont traitées simultanément. Même une nouvelle tentative avec une interruption exponentielle (nombre de requêtes) peut inonder un service.
Par contraste, les approches basées sur l’infrastructure comme Linkerd ne sont pas conscientes du fonctionnement interne des applications. Par exemple, les transactions de base de données complexes sont invisibles pour Linkerd. Ces transactions peuvent être protégées contre les défaillances 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.