Simuler des incidents sur les périphériques de blocs

Traduction Bêta Non Officielle

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 →

Introduction à BlockChaos

Chaos Mesh propose le type d'expérience BlockChaos. Vous pouvez utiliser cette expérience pour simuler des scénarios de latence ou de blocage sur des périphériques de blocs. Ce document explique comment installer les dépendances nécessaires pour une expérience BlockChaos et en créer une.

note

BlockChaos est actuellement en phase précoce. L'expérience d'installation et de configuration continuera d'être améliorée. Si vous rencontrez des problèmes, merci d'ouvrir un ticket sur chaos-mesh/chaos-mesh.

note

L'action freeze de BlockChaos affectera tous les processus utilisant le périphérique de blocs, pas uniquement le conteneur ciblé.

Installer le module noyau

L'action delay de BlockChaos dépend du module noyau chaos-driver. Elle ne peut être injectée que sur une machine où ce module est installé. Actuellement, vous devez compiler et installer le module manuellement.

1. Téléchargez le code source du module avec la commande suivante :

   curl -fsSL -o chaos-driver-v0.2.1.tar.gz https://github.com/chaos-mesh/chaos-driver/archive/refs/tags/v0.2.1.tar.gz

2. Décompressez le fichier chaos-driver-v0.2.1.tar.gz :

   tar xvf chaos-driver-v0.2.1.tar.gz

3. Préparez les en-têtes de votre noyau actuel. Sous CentOS/Fedora, installez les en-têtes avec yum :

   yum install kernel-devel-$(uname -r)

   Sous Ubuntu/Debian, installez les en-têtes avec apt :

   apt install linux-headers-$(uname -r)

4. Compilez le module :

   cd chaos-driver-v0.2.1
   make driver/chaos_driver.ko

5. Installez le module noyau :

   insmod ./driver/chaos_driver.ko

Le module chaos_driver doit être réinstallé après chaque redémarrage. Pour le charger automatiquement, copiez-le dans un sous-répertoire de /lib/modules/$(uname -r)/kernel/drivers, exécutez depmod -a, puis ajoutez chaos_driver dans /etc/modules.

Si vous mettez à jour le noyau, le module doit être recompilé.

note

Nous recommandons d'utiliser DKMS ou akmod pour la compilation et le chargement automatiques des modules noyau. Si vous souhaitez contribuer à améliorer l'expérience d'installation, créer un package DKMS ou akmod et le soumettre aux dépôts des différentes distributions serait très apprécié.

Créer des expériences avec un fichier YAML

1. Configurez l'expérience dans un fichier YAML. L'exemple suivant utilise block-latency.yaml :

   apiVersion: chaos-mesh.org/v1alpha1
   kind: BlockChaos
   metadata:
     name: hostpath-example-delay
   spec:
     selector:
       labelSelectors:
         app: hostpath-example
     mode: all
     volumeName: hostpath-example
     action: delay
     delay:
       latency: 1s

   note

   Seuls hostpath et localvolume sont pris en charge.

2. Créez l'expérience avec kubectl :

   kubectl apply -f block-latency.yaml

Vous observerez les effets suivants :

1. L'ordonnanceur (elevator) du volume passe à ioem ou ioem-mq. Vous pouvez le vérifier via cat /sys/block/<device>/queue/scheduler.

2. L'ordonnanceur ioem ou ioem-mq reçoit la requête de latence et retarde la requête pendant la durée spécifiée.

Les champs du fichier de configuration YAML sont décrits dans le tableau suivant :

Parameter	Type	Note	Default value	Required	Example
mode	string	Specifies the mode of the experiment. The mode options include one (selecting a random Pod), all (selecting all eligible Pods), fixed (selecting a specified number of eligible Pods), fixed-percent (selecting a specified percentage of Pods from the eligible Pods), and random-max-percent (selecting the maximum percentage of Pods from the eligible Pods).	None	Yes	one
value	string	Provides parameters for the mode configuration, depending on mode. For example, when mode is set to fixed-percent, value specifies the percentage of Pods.	None	No	1
selector	struct	Specifies the target Pod. For details, refer to Define the experiment scope.	None	Yes
volumeName	string	Specifies the volume to inject in the target pods. There should be a corresponding entry in the pods' .spec.volumes.	None	Yes	hostpath-example
action	string	Indicates the specific type of faults. The available fault types include delay and freeze. delay will simulate the latency of block devices, and freeze will simulate that the block device cannot handle any requests	None	Yes	delay
delay.latency	string	Specifies the latency of the block device.	None	Yes (if action is delay)	500ms