Aller au contenu principal
Version : 2.6.7

Simuler des pannes du noyau Linux

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 →

Ce document explique comment utiliser KernelChaos pour simuler des pannes du noyau Linux. Cette fonctionnalité injecte des pannes basées sur les E/S ou la mémoire dans les chemins noyau spécifiés en utilisant BPF.

Bien que vous puissiez cibler l'injection de KernelChaos sur un ou plusieurs Pods, les performances des autres Pods sur l'hôte seront impactées, car tous les Pods partagent le même noyau.

avertissement

La simulation des pannes du noyau Linux est désactivée par défaut. N'utilisez pas cette fonctionnalité en environnement de production.

Prérequis​

Fichier de configuration​

Un exemple simple de fichier de configuration KernelChaos est le suivant :

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

Pour plus d'exemples de configuration, consultez les exemples. Vous pouvez modifier ces configurations selon vos besoins.

Description des configurations :

  • mode spécifie le mode d'exécution de l'expérience. Les options sont les suivantes :

    • one : sélectionne aléatoirement un Pod éligible.
    • all : sélectionne tous les Pods éligibles.
    • fixed : sélectionne un nombre spécifié de Pods éligibles.
    • fixed-percent : sélectionne un pourcentage spécifié de Pods éligibles.
    • random-max-percent : sélectionne le pourcentage maximal de Pods éligibles.

  • selector spécifie le Pod cible pour l'injection de panne.

  • FailedkernRequest spécifie le mode de défaut (comme kmallo et bio). Il définit également un chemin spécifique dans la chaîne d'appels et les conditions de filtrage optionnelles. Les éléments de configuration sont les suivants :

    • Failtype spécifie le type de défaut. Les options de valeur sont :

      • '0' : injecte l'erreur d'allocation slab should_failslab.
      • '1' : injecte l'erreur d'allocation de page mémoire should_fail_alloc_page.
      • '2' : injecte l'erreur bio should_fail_bio.

      Pour plus d'informations sur ces trois types de défauts, consultez fault-injection et inject_example.

    • Callchain spécifie une chaîne d'appel particulière. Par exemple :

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

      Vous pouvez également utiliser les paramètres de fonction comme règles de filtrage pour injecter des défauts plus granulaires. Voir les exemples de chaînes d'appel et prédicats pour plus de détails. Si aucune chaîne d'appel n'est spécifiée, laissez le champ callchain vide, ce qui signifie que les défauts seront injectés sur tout chemin où slab alloc est appelé (par exemple kmallo).

      Le type de chaîne d'appel est un tableau de trames, comprenant trois parties :

      • funcname, trouvable dans le code source du noyau ou dans /proc/kallsyms, par exemple ext4_mount.
      • parameters, utilisé pour le filtrage. Pour injecter une erreur slab sur le chemin d_alloc_parallel(struct dentry *parent, const struct qstr *name) avec un nom spécial bananas, définissez parameters sur struct dentry *parent, const struct qstr *name. Sinon, omettez cette configuration.
      • predicate, utilisé pour accéder aux paramètres du tableau de trames. En prenant parameters comme exemple, vous pouvez le définir sur STRNCMP(name->name, "bananas", 8) pour contrôler le chemin d'injection du défaut, ou le laisser vide pour que tous les chemins exécutant d_allo_parallel reçoivent l'injection slab.

    • headers spécifie le fichier d'en-tête du noyau requis, par exemple "linux/mmzone.h" et "linux/blkdev.h".

    • probability définit la probabilité d'occurrence des défauts. Pour une probabilité de 1%, définissez à '1'.

    • times spécifie le nombre maximal de déclenchements d'un défaut.

Créer une expérience avec kubectl​

Utilisez kubectl pour créer une expérience :

kubectl apply -f KernelChaos

La fonctionnalité KernelChaos est similaire à inject.py. Pour plus de détails, reportez-vous à input_example.txt.

Un exemple simple est présenté ci-dessous :

#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));
  }
}

Pendant l'injection de défauts, la sortie est la suivante :

> 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

Restrictions d'utilisation​

Vous pouvez utiliser container_id pour limiter la portée de l'injection de défauts, mais certains chemins déclenchent des comportements système. Par exemple :

Lorsque failtype est 1, cela signifie que l'allocation de page physique échoue. Si cet événement est fréquemment déclenché sur une courte période (par exemple while (1) {memset(malloc(1M), '1', 1M)}), l'appel système oom-killer est déclenché pour recycler la mémoire.