Simulation von Linux-Kernel-Fehlern

Inoffizielle Beta-Übersetzung

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

Dieses Dokument beschreibt die Verwendung von KernelChaos zur Simulation von Linux-Kernel-Fehlern. Diese Funktion injiziert I/O- oder speicherbasierte Fehler in festgelegte Kernel-Pfade mithilfe von BPF.

Obwohl Sie das Injektionsziel von KernelChaos auf einen oder mehrere Pods beschränken können, wirkt sich dies auf die Leistung anderer Pods auf dem Host aus, da alle Pods denselben Kernel verwenden.

Warnung

Die Simulation von Linux-Kernel-Fehlern ist standardmäßig deaktiviert. Verwenden Sie diese Funktion nicht in Produktionsumgebungen.

Voraussetzungen

• Linux-Kernel Version >= 4.18

• Linux-Kernel-Konfiguration CONFIG_BPF_KPROBE_OVERRIDE aktiviert

• Konfigurationswert bpfki.create in values.yaml auf true gesetzt

Konfigurationsdatei

Eine einfache KernelChaos-Konfigurationsdatei sieht folgendermaßen aus:

apiVersion: chaos-mesh.org/v1alpha1
kind: KernelChaos
metadata:
  name: kernel-chaos-example
  namespace: chaos-mesh
spec:
  mode: one
  selector:
    namespaces:
      - chaos-mount
  failKernRequest:
    callchain:
      - funcname: '__x64_sys_mount'
    failtype: 0

Weitere Konfigurationsbeispiele finden Sie unter examples. Sie können diese Beispiele bei Bedarf anpassen.

Konfigurationsbeschreibung:

• mode definiert die Ausführungsart des Experiments. Optionen sind:

  • one: wählt zufällig einen passenden Pod aus
  • all: wählt alle passenden Pods aus
  • fixed: wählt eine festgelegte Anzahl passender Pods aus
  • fixed-percent: wählt einen festgelegten Prozentsatz passender Pods aus
  • random-max-percent: wählt den maximalen Prozentsatz passender Pods aus

• selector definiert den Ziel-Pod für die Fehlerinjektion

• FailedkernRequest legt den Fehlertyp fest (z.B. kmallo oder bio) sowie einen spezifischen Aufrufpfad und optionale Filterbedingungen. Die Konfigurationsoptionen sind:

  • Failtype definiert den Fehlertyp. Mögliche Werte:

    • '0': Injiziert Slab-Allokationsfehler (should_failslab).
    • '1': Injiziert Speicherseiten-Allokationsfehler (should_fail_alloc_page).
    • '2': Injiziert BIO-Fehler (should_fail_bio).

    Weitere Informationen zu diesen Fehlertypen finden Sie unter fault-injection und inject_example.

  • Callchain definiert einen spezifischen Aufrufpfad. Beispiel:

    ext4_mount
    -> mount_subtree
    -> ...
        -> should_failslab

    Funktionsparameter können als Filterregeln für granularere Fehlerinjektion genutzt werden. Beispiele finden Sie unter call chain and predicate examples. Bei leerem callchain-Feld werden Fehler in allen Pfaden injiziert, die Slab-Allokationen aufrufen (z.B. kmallo).

    Der Aufrufpfad ist ein Frame-Array mit drei Komponenten:

    • funcname: Aus Kernel-Quellcode oder /proc/kallsyms ermittelbar, z.B. ext4_mount.
    • parameters: Dient der Filterung. Beispiel für d_alloc_parallel(struct dentry *parent, const struct qstr *name) mit speziellem Namen bananas: setzen Sie die parameters auf struct dentry *parent, const struct qstr *name. Andernfalls leer lassen.
    • predicate: Ermöglicht Parameterzugriff. Beispiel: STRNCMP(name->name, "bananas", 8) für gezielte Fehlerinjektion. Leer lassen für alle Aufrufpfade von d_allo_parallel.

  • headers: Benötigte Kernel-Headerdateien, z.B. "linux/mmzone.h", "linux/blkdev.h".

  • probability: Fehlerwahrscheinlichkeit (z.B. '1' für 1%).

  • times: Maximale Anzahl der Fehlerauslösungen.

Experiment mit kubectl erstellen

Experiment mit kubectl anlegen:

kubectl apply -f KernelChaos

Die KernelChaos-Funktionalität ähnelt inject.py. Details unter input_example.txt.

Einfaches Beispiel:

#include <sys/mount.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>

int main(void) {
  int ret;
  while (1) {
    ret = mount("/dev/sdc", "/mnt", "ext4",
          MS_MGC_VAL | MS_RDONLY | MS_NOSUID, "");
    if (ret < 0)
      fprintf(stderr, "%s\n", strerror(errno));
    sleep(1);
    ret = umount("/mnt");
    if (ret < 0)
      fprintf(stderr, "%s\n", strerror(errno));
  }
}

Ausgabe während der Fehlerinjektion:

> Cannot allocate memory
> Invalid argument
> Cannot allocate memory
> Invalid argument
> Cannot allocate memory
> Invalid argument
> Cannot allocate memory
> Invalid argument
> Cannot allocate memory
> Invalid argument

Nutzungseinschränkungen

container_id kann den Injektionsumfang einschränken, aber bestimmte Pfade lösen Systemverhalten aus. Beispiel:

Bei failtype = 1 (physikalische Speicherseiten-Allokationsfehler) kann häufiges Auslösen (z.B. durch while (1) {memset(malloc(1M), '1', 1M)}) den oom-killer zur Speicherbereinigung aktivieren.