Simulieren von Blockgeräte-Störungen

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Einführung in BlockChaos

Chaos Mesh bietet den Experimenttyp BlockChaos. Mit diesem Experimenttyp können Sie Latenzen oder Einfrier-Szenarien bei Blockgeräten simulieren. Dieses Dokument beschreibt, wie Sie die Abhängigkeiten für ein BlockChaos-Experiment installieren und ein BlockChaos erstellen.

Hinweis

BlockChaos befindet sich in einem frühen Entwicklungsstadium. Die Installation und Konfiguration wird kontinuierlich verbessert. Wenn Sie Probleme feststellen, öffnen Sie bitte ein Issue in chaos-mesh/chaos-mesh.

Hinweis

Die freeze-Aktion von BlockChaos betrifft alle Prozesse, die das Blockgerät verwenden, nicht nur den Ziel-Container.

Kernelmodul installieren

Die delay-Aktion von BlockChaos erfordert das chaos-driver-Kernelmodul. Sie kann nur auf Maschinen mit installiertem Modul injiziert werden. Derzeit müssen Sie das Modul manuell kompilieren und installieren.

1. Laden Sie den Quellcode des Moduls mit folgendem Befehl herunter:

   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. Entpacken Sie die Datei chaos-driver-v0.2.1.tar.gz:

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

3. Bereiten Sie die Header Ihres aktuellen Kernels vor. Bei CentOS/Fedora installieren Sie die Kernel-Header mit yum:

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

   Bei Ubuntu/Debian installieren Sie die Kernel-Header mit apt:

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

4. Kompilieren Sie das Modul:

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

5. Installieren Sie das Kernelmodul:

   insmod ./driver/chaos_driver.ko

Das chaos_driver-Modul muss nach jedem Neustart erneut installiert werden. Für automatisches Laden kopieren Sie das Modul in ein Unterverzeichnis von /lib/modules/$(uname -r)/kernel/drivers, führen depmod -a aus und tragen chaos_driver in /etc/modules ein.

Bei Kernel-Updates muss das Modul neu kompiliert werden.

Hinweis

Wir empfehlen DKMS oder akmod für automatische Kompilierung oder Laden von Kernelmodulen. Wenn Sie die Installation verbessern möchten, sind Beiträge wie DKMS/akmod-Pakete für Distributions-Repositories sehr willkommen.

Experimente mit YAML-Dateien erstellen

1. Speichern Sie die Experimentkonfiguration in einer YAML-Datei. Beispielhaft verwenden wir 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

   Hinweis

   Nur hostpath oder localvolume werden unterstützt.

2. Erstellen Sie das Experiment mit kubectl:

   kubectl apply -f block-latency.yaml

Sie werden folgende Änderung feststellen:

1. Der I/O-Scheduler des Volumes wird auf ioem oder ioem-mq geändert. Prüfen Sie dies mit cat /sys/block/<device>/queue/scheduler.

2. Der ioem- oder ioem-mq-Scheduler empfängt die Latenzanforderung und verzögert die Anfrage für die angegebene Zeit.

Die Felder der YAML-Konfigurationsdatei werden in folgender Tabelle erläutert:

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