Litmus Chaos : Une des raisons pour lesquelles votre pod-dns-error échoue

Dans mon exploration du Chaos Engineering avec Litmus Chaos v3, je suis tombé sur un comportement assez frustrant.

J'ai configuré tranquillement un scénario pod-dns-error pour tester la résilience de mon application en cas de panne DNS. Tout semblait correct sur le papier. Pourtant, à l'exécution, mon test s'est terminé sur un verdict Error avec un message d'erreur pas très causant :
NON_USER_FRIENDLY_ERROR : err: exit status 1.

Le truc qui m'a rendu fou, c'est que c'était binaire. Certains de mes pods passaient le test sans broncher (verdict Pass), tandis que d'autres échouaient systématiquement.

C'est simplement que ma sécurité faisait tropp bien son boulot.

Le coupable : la modification de resolv.conf

Pour comprendre la cause racine, il faut regarder comment Litmus Chaos injecte une panne DNS.

Dans le code de l'agent de chaos (Litmus-Go), l'utilitaire dns_interceptor est lancé par un conteneur helper temporaire. Pour perturber le trafic DNS du pod cible, cet utilitaire s'infiltre dans le namespace du conteneur et doit modifier le fichier /etc/resolv.conf.

C'est là que ça coince.

Si on applique les bonnes pratiques de sécurité et de durcissement de pods en production, on configure souvent ceci :

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  readOnlyRootFilesystem: true  # <--- Le piège est ici

Avec readOnlyRootFilesystem: true, le système de fichiers racine du conteneur est en lecture seule. Quand le helper de Litmus tente de réécrire le fichier /etc/resolv.conf, le système d'exploitation bloque l'écriture avec une erreur de type Read-only file system. L'agent Litmus s'arrête avec un code de retour exit status 1.

À l'inverse, si un pod n'a pas cette restriction, son système de fichiers est réinscriptible. Le helper de Litmus modifie le fichier sans problème, injecte sa panne DNS et le test passe.

Comment diagnostiquer et tester vous-même ?

Pour valider rapidement si vous êtes confronté à ce cas de figure, voici deux commandes kubectl bien pratiques à lancer sur vos déploiements et résultats de chaos :

1. Vérifier si un déploiement est en lecture seule :

   kubectl get deployment -n mon-namespace <nom-deploiement> \
     -o jsonpath='{.spec.template.spec.containers[*].securityContext.readOnlyRootFilesystem}'
   

2. Récupérer le verdict et le pod cible du dernier test DNS :

   kubectl get chaosresults -n litmus -l experiment=pod-dns-error \
     -o custom-columns="NAME:.metadata.name,VERDICT:.status.experimentStatus.verdict,TARGET_POD:.status.history.targets[*].name"
   

Deux solutions pragmatiques pour s'en sortir

Alors on fait quoi ? On sacrifie la sécurité de nos pods pour faire du Chaos Engineering ? Surtout pas. Voici deux façons propres de s'en sortir.

Solution A : Passer par la disruption réseau (Network Chaos)

Si le but est de tester comment l'application se comporte quand elle ne résout plus ses adresses, on peut simuler cela au niveau du réseau plutôt qu'au niveau des fichiers.

• En pratique : On utilise l'expérience pod-network-loss ou pod-network-latency configurée spécifiquement sur le port 53 (le port standard du DNS) via la variable TARGET_PORT: "53". Cette méthode manipule les règles de routage (via iptables ou traffic control) et n'a absolument pas besoin d'écrire sur le disque du conteneur. C'est propre, robuste, et compatible à 100% avec un système de fichiers en lecture seule.

Solution B : Filtrer vos cibles (Pas trop recommandée)

Si on souhaite absolument s'en tenir à l'expérience pod-dns-error, la seule issue consiste à configurer l'expérience de chaos pour qu'elle exclue les composants en lecture seule et ne cible que ceux compatibles.

• En pratique : On modifie les labels ou les sélections d'applications (applabel) dans le scénario de chaos pour exclure les pods durcis en lecture seule.
• Pourquoi c'est bof : En faisant cela, on évite d'exécuter nos tests de résilience sur les composants les plus critiques et sécurisés du socle. Ce qui va un peu à l'encontre de la philosophie même du Chaos Engineering.

Ce qu'on retient

Le Chaos Engineering consiste à tester les limites de nos systèmes, et parfois, ce sont les mesures de sécurité elles-mêmes qui posent problème. Comprendre ce couplage entre le système de fichiers et l'agent de chaos évite de s'arracher les cheveux sur des erreurs Litmus cryptiques.

Allez, à la prochaine.