Construction d'un framework de test automatisé basé sur Chaos Mesh et Argo
Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →
Chaos Mesh est une plateforme open source d'ingénierie du chaos pour Kubernetes. Bien qu'elle offre des capacités étendues pour simuler des conditions système anormales, elle ne résout qu'une partie du puzzle de l'ingénierie du chaos. Au-delà de l'injection de fautes, une application complète d'ingénierie du chaos implique de formuler des hypothèses autour d'états stables définis, d'exécuter des expériences en production, de valider le système via des cas de test et d'automatiser les tests.
Cet article décrit comment nous utilisons TiPocket, un framework de test automatisé pour construire une boucle complète de test d'ingénierie du chaos pour TiDB, notre base de données distribuée.
Pourquoi avons-nous besoin de TiPocket ?
Avant de mettre en production un système distribué comme TiDB, nous devons nous assurer qu'il est suffisamment robuste pour un usage quotidien. C'est pourquoi, il y a plusieurs années, nous avons intégré l'ingénierie du chaos dans notre framework de test. Dans ce framework, nous :
-
Observons les métriques normales et développons nos hypothèses de test.
-
Injectons une liste de défaillances dans TiDB.
-
Exécutons divers cas de test pour vérifier TiDB dans des scénarios de faute.
-
Surveillons et collectons les résultats des tests pour analyse et diagnostic.
Ce processus semble solide et nous l'utilisons depuis des années. Cependant, avec l'évolution de TiDB, l'échelle des tests se multiplie. Nous avons plusieurs scénarios de faute, contre lesquels des dizaines de cas de test s'exécutent dans le cluster de test Kubernetes. Même avec Chaos Mesh pour injecter les défaillances, le travail restant reste exigeant, sans parler du défi d'automatiser le pipeline pour rendre les tests évolutifs et efficaces.
C'est pourquoi nous avons construit TiPocket, un framework de test entièrement automatisé basé sur Kubernetes et Chaos Mesh. Actuellement, nous l'utilisons principalement pour tester les clusters TiDB. Cependant, grâce à la conception compatible Kubernetes et à l'interface extensible de TiPocket, vous pouvez utiliser la logique de création et de suppression de Kubernetes pour prendre en charge facilement d'autres applications.
Comment fonctionne-t-il
Sur la base de ces exigences, nous avons besoin d'un flux de travail automatique qui :
Injection du chaos - Chaos Mesh
L'injection de fautes est au cœur des tests de chaos. Dans une base de données distribuée, les fautes peuvent survenir n'importe quand et n'importe où : plantages de nœuds, partitions réseau, défaillances du système de fichiers ou paniques du noyau. C'est là qu'intervient Chaos Mesh.
Actuellement, TiPocket prend en charge les types d'injection de fautes suivants :
-
Réseau : Simule des partitions réseau, des pertes de paquets aléatoires, du désordre, des duplications ou des délais de liens.
-
Décalage temporel : Simule un décalage d'horloge du conteneur à tester.
-
Kill : Tue le pod spécifié, soit aléatoirement dans un cluster, soit au sein d'un composant (TiDB, TiKV ou Placement Driver (PD)).
-
I/O : Injecte des délais d'E/S dans le moteur de stockage TiKV de TiDB pour identifier les problèmes liés aux E/S.
L'injection de fautes étant gérée, nous devons penser à la vérification. Comment nous assurer que TiDB peut survivre à ces fautes ?
Vérification des impacts du chaos : cas de test
Pour valider la résilience de TiDB face au chaos, nous avons implémenté des dizaines de cas de test dans TiPocket, combinés à divers outils d'inspection. Voici quelques cas illustrant comment TiPocket vérifie TiDB lors de défaillances, en se concentrant sur l'exécution SQL, la cohérence transactionnelle et l'isolation des transactions.
Test aléatoire : SQLsmith
SQLsmith génère des requêtes SQL aléatoires. TiPocket crée un cluster TiDB et une instance MySQL. Les requêtes SQL aléatoires sont exécutées sur TiDB et MySQL, tandis que des pannes sont injectées dans le cluster TiDB. Les résultats d'exécution sont comparés. Toute divergence révèle des problèmes potentiels du système.
Test de cohérence transactionnelle : Bank et Porcupine
Bank simule des transferts bancaires. Sous isolation par instantané, le montant total des comptes doit rester cohérent à tout moment, malgré les défaillances. Une incohérence indiquerait un problème système.
Porcupine est un vérificateur de linéarisabilité en Go pour systèmes distribués. Il compare une spécification séquentielle à une historique concurrente pour déterminer la linéarisabilité. Dans TiPocket, nous utilisons le vérificateur Porcupine pour contrôler si TiDB respecte cette contrainte.
Test d'isolation transactionnelle : Elle
Elle vérifie les niveaux d'isolation transactionnelle des bases de données. TiPocket intègre go-elle, l'implémentation Go de cet outil, pour valider le niveau d'isolation de TiDB.
Ces cas ne sont qu'un aperçu des méthodes de vérification de TiPocket. Pour plus de cas et d'outils, consultez notre code source.
Automatisation du pipeline de chaos - Argo
Avec Chaos Mesh pour l'injection de pannes, un cluster TiDB à tester et des méthodes de validation, comment automatiser le pipeline ? Deux options s'offraient à nous : implémenter l'orchestration dans TiPocket, ou utiliser des outils open source existants. Pour que TiPocket se concentre sur les tests, nous avons choisi la seconde approche. Notre design Kubernetes-native nous a naturellement dirigés vers Argo.
Argo est un moteur de workflows conçu pour Kubernetes, largement adopté par la communauté open source.
Argo définit plusieurs CRD (Custom Resource Definitions) pour les workflows. Les principaux sont Workflow Template, Workflow et Cron Workflow. Voici leur rôle dans TiPocket :
-
Workflow Template : Modèle prédéfini pour chaque tâche de test, paramétrable lors de l'exécution.
-
Workflow : Orchestre plusieurs templates dans un ordre spécifique, avec ajout de conditions, boucles ou graphes acycliques (DAG).
-
Cron Workflow : Planifie l'exécution de workflows comme des tâches cron, idéal pour les tests de longue durée.
Voici un exemple de workflow pour notre test Bank :
spec:
entrypoint: call-tipocket-bank
arguments:
parameters:
- name: ns
value: tipocket-bank
- name: nemesis
value: random_kill,kill_pd_leader_5min,partition_one,subcritical_skews,big_skews,shuffle-leader-scheduler,shuffle-region-scheduler,random-merge-scheduler
templates:
- name: call-tipocket-bank
steps:
- - name: call-wait-cluster
templateRef:
name: wait-cluster
template: wait-cluster
- - name: call-tipocket-bank
templateRef:
name: tipocket-bank
template: tipocket-bank
Dans cet exemple, nous utilisons le modèle de workflow et les paramètres nemesis pour définir la défaillance spécifique à injecter. Vous pouvez réutiliser ce modèle pour définir plusieurs workflows adaptés à différents cas de test. Cela vous permet d'ajouter des injections de défaillances personnalisées dans le flux.
En complément des workflows et modèles d'exemple de TiPocket, cette conception vous permet également d'ajouter vos propres flux d'injection de défaillances. La gestion de logiques complexes via des workflows codables rend Argo convivial pour les développeurs, ce qui en fait un choix idéal pour nos scénarios.
Notre expérience de chaos s'exécute désormais automatiquement. Mais que faire si les résultats ne répondent pas à nos attentes ? Comment localiser le problème ? TiDB enregistre une variété d'informations de surveillance, ce qui rend la collecte de journaux essentielle pour assurer l'observabilité dans TiPocket.
Visualiser les résultats : Loki
Dans les systèmes cloud-native, l'observabilité est cruciale. Généralement, vous pouvez l'atteindre via les métriques, la journalisation et le tracing. Les principaux cas de test de TiPocket évaluent des clusters TiDB, donc les métriques et journaux sont nos sources par défaut pour localiser les problèmes.
Sous Kubernetes, Prometheus est la solution de référence pour les métriques. Cependant, il n'existe pas de méthode standardisée pour la collecte de journaux. Des solutions comme Elasticsearch, Fluent Bit et Kibana fonctionnent bien, mais elles peuvent engendrer une contention des ressources système et des coûts de maintenance élevés. Nous avons opté pour Loki, le système d'agrégation de journaux inspiré de Prometheus développé par Grafana.
Prometheus traite les informations de surveillance de TiDB. Prometheus et Loki partagent un système d'étiquetage similaire, ce qui nous permet de combiner facilement les indicateurs de surveillance de Prometheus avec les journaux des pods correspondants, en utilisant un langage de requête similaire. Grafana prend également en charge le tableau de bord Loki, ce qui signifie que nous pouvons utiliser Grafana pour afficher simultanément les indicateurs de surveillance et les journaux. Grafana étant le composant de surveillance intégré à TiDB, Loki peut le réutiliser.
Assembler le tout - TiPocket
Maintenant, tout est en place. Voici un diagramme simplifié de TiPocket :
Comme vous pouvez le voir, le workflow Argo gère toutes les expériences de chaos et les cas de test. Généralement, un cycle de test complet implique les étapes suivantes :
- Argo crée un Cron Workflow qui définit le cluster à tester, les défaillances à injecter, le cas de test et la durée de la tâche. Si nécessaire, le Cron Workflow vous permet également de consulter les journaux des cas en temps réel.
-
À un moment spécifié, un thread TiPocket distinct est lancé dans le workflow et le Cron Workflow est déclenché. TiPocket envoie à TiDB-Operator la définition du cluster à tester. À son tour, TiDB-Operator crée un cluster TiDB cible. Pendant ce temps, Loki collecte les journaux associés.
-
Chaos Mesh injecte des défaillances dans le cluster.
-
En utilisant les cas de test mentionnés ci-dessus, l'utilisateur valide l'état de santé du système. Tout échec d'un cas de test entraîne un échec du workflow dans Argo, ce qui déclenche Alertmanager pour envoyer le résultat au canal Slack spécifié. Si les cas de test se terminent normalement, le cluster est nettoyé et Argo reste en attente jusqu'au prochain test.
Voici le workflow complet de TiPocket.
Rejoignez-nous
Chaos Mesh et TiPocket sont tous deux en développement actif. Nous avons fait don de Chaos Mesh à la CNCF, et nous espérons que davantage de membres de la communauté nous rejoindront pour construire un écosystème complet de Chaos Engineering. Si ce projet vous intéresse, consultez notre site web ou rejoignez le canal #project-chaos-mesh sur le Slack de la CNCF.