Simuler des pannes réseau

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 simuler des pannes réseau à l'aide de NetworkChaos dans Chaos Mesh.

Introduction à NetworkChaos

NetworkChaos est un type de faute dans Chaos Mesh. En créant une expérience NetworkChaos, vous pouvez simuler un scénario de panne réseau pour un cluster. Actuellement, NetworkChaos prend en charge les types de fautes suivants :

• Partition : déconnexion et partition réseau.

• Émulation réseau : conditions réseau dégradées, comme des délais élevés, un taux de perte de paquets important, un réordonnancement des paquets, etc.

• Bande passante : limitation de la bande passante de communication entre les nœuds.

Notes importantes

Avant de créer des expériences NetworkChaos, assurez-vous des points suivants :

1. Pendant l'injection réseau, assurez-vous que la connexion entre le Controller Manager et Chaos Daemon fonctionne, sans quoi le NetworkChaos ne pourra plus être restauré.

2. Pour simuler une faute d'émulation réseau, vérifiez que le module NET_SCH_NETEM est installé dans le noyau Linux. Sur CentOS, installez-le via le paquet kernel-modules-extra. La plupart des autres distributions Linux l'incluent par défaut.

Créer des expériences avec Chaos Dashboard

1. Ouvrez Chaos Dashboard, puis cliquez sur NOUVELLE EXPÉRIENCE pour créer une nouvelle expérience :

   

   Créer une expérience

2. Dans la section Choisir une cible, sélectionnez ATTAQUE RÉSEAU et un comportement spécifique comme PERTE. Remplissez ensuite les paramètres :

   

   Expériences NetworkChaos

   Pour les détails des champs de configuration, consultez la Description des champs.

3. Saisissez les informations de l'expérience, en précisant son périmètre et sa durée planifiée :

   

   Informations de l'expérience

4. Soumettez les informations de l'expérience.

Créer des expériences via des fichiers YAML

Exemple de délai

1. Configurez l'expérience dans le fichier network-delay.yaml comme suit :

   apiVersion: chaos-mesh.org/v1alpha1
   kind: NetworkChaos
   metadata:
     name: delay
   spec:
     action: delay
     mode: one
     selector:
       namespaces:
         - default
       labelSelectors:
         'app': 'web-show'
     delay:
       latency: '10ms'
       correlation: '100'
       jitter: '0ms'

   Cette configuration induit une latence de 10 millisecondes dans les connexions réseau des Pods ciblés. Chaos Mesh prend également en charge la perte et le réordonnancement de paquets. Pour plus de détails, consultez la description des champs.

2. Une fois le fichier prêt, créez l'expérience avec kubectl :

   kubectl apply -f ./network-delay.yaml

Exemple de partition

1. Configurez l'expérience dans network-partition.yaml comme ci-dessous :

   apiVersion: chaos-mesh.org/v1alpha1
   kind: NetworkChaos
   metadata:
     name: partition
   spec:
     action: partition
     mode: all
     selector:
       namespaces:
         - default
       labelSelectors:
         'app': 'app1'
     direction: to
     target:
       mode: all
       selector:
         namespaces:
           - default
         labelSelectors:
           'app': 'app2'

   Cette configuration bloque les connexions établies de app1 vers app2. Le champ direction peut prendre les valeurs to, from ou both. Pour plus de détails, reportez-vous à la Description des champs.

2. Après configuration, lancez l'expérience avec kubectl :

   kubectl apply -f ./network-partition.yaml

Exemple de bande passante

1. Écrivez la configuration de l'expérience dans le fichier network-bandwidth.yaml, comme indiqué ci-dessous :

   apiVersion: chaos-mesh.org/v1alpha1
   kind: NetworkChaos
   metadata:
     name: bandwidth
   spec:
     action: bandwidth
     mode: all
     selector:
       namespaces:
         - default
       labelSelectors:
         'app': 'app1'
     bandwidth:
       rate: '1mbps'
       limit: 20971520
       buffer: 10000

   Cette configuration limite la bande passante de app1 à 1 mbps.

2. Une fois le fichier de configuration préparé, utilisez kubectl pour créer l'expérience :

   kubectl apply -f ./network-bandwidth.yaml

Exemple d'émulation réseau

1. Écrivez la configuration de l'expérience dans le fichier netem.yaml, comme indiqué ci-dessous :

   apiVersion: chaos-mesh.org/v1alpha1
   kind: NetworkChaos
   metadata:
     name: network-emulation
   spec:
     action: netem
     mode: all
     selector:
       namespaces:
         - default
       labelSelectors:
         'app': 'web-show'
     delay:
       latency: '10ms'
       correlation: '100'
       jitter: '0ms'
     rate:
       rate: '10mbps'

   Cette configuration introduit une latence de 10 millisecondes et limite la bande passante à 10 mbps sur les connexions réseau des Pods cibles. Outre la latence et le débit, l'action netem prend également en charge la perte, le réordonnancement et la corruption de paquets.

2. Une fois le fichier de configuration préparé, utilisez kubectl pour créer l'expérience :

   kubectl apply -f ./netem.yaml

Description des champs

Parameter	Type	Description	Default value	Required	Example
action	string	Indicates the specific fault type. Available types include: netem, delay (network delay), loss (packet loss), duplicate (packet duplicating), corrupt (packet corrupt), partition (network partition), and bandwidth (network bandwidth limit). After you specify action field, refer to Description for action-related fields for other necessary field configuration.	None	Yes	Partition
target	Selector	Used in combination with direction, making Chaos only effective for some packets.	None	No
direction	enum	Indicates the direction of target packets. Available values include from (the packets from target), to (the packets to target), and both ( the packets from or to target). This parameter makes Chaos only take effect for a specific direction of packets.	to	No	both
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 a parameter 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
externalTargets	[]string	Indicates the network targets except for Kubernetes, which can be IPv4 addresses or domains. This parameter only works with direction: to.	None	No	1.1.1.1, google.com
device	string	Specifies the affected network interface	None	No	"eth0"

Description des champs liés à action

Pour les types de fautes d'émulation réseau et de bande passante, vous pouvez configurer davantage les paramètres liés à action selon la description suivante.

• Type d'émulation réseau : delay, loss, duplicated, corrupt, rate

• Type de bande passante : bandwidth

delay

Définir action sur delay simule une latence réseau. Vous pouvez également configurer les paramètres suivants.

Parameter	Type	Description	Required	Required	Example
latency	string	Indicates the network latency	No	No	2ms
correlation	string	Indicates the correlation between the current latency and the previous one. Range of value: [0, 100]	No	No	50
jitter	string	Indicates the range of the network latency	No	No	1ms
reorder	Reorder(#Reorder)	Indicates the status of network packet reordering		No

Le modèle de calcul pour correlation est le suivant :

1. Générez un nombre aléatoire dont la distribution est liée à la valeur précédente :

   rnd = value * (1-corr) + last_rnd * corr

   rnd est le nombre aléatoire. corr correspond à la correlation que vous avez spécifiée.

2. Utilisez ce nombre aléatoire pour déterminer le délai du paquet actuel :

   ((rnd % (2 * sigma)) + mu) - sigma

   Dans la commande ci-dessus, sigma correspond à jitter et mu à latency.

reorder

Définir action sur reorder simule un réordonnancement de paquets réseau. Vous pouvez également configurer les paramètres suivants.

Parameter	Type	Description	Default value	Required	Example
reorder	string	Indicates the probability to reorder	0	No	0.5
correlation	string	Indicates the correlation between this time's length of delay time and the previous time's length of delay time. Range of value: [0, 100]	0	No	50
gap	int	Indicates the gap before and after packet reordering	0	No	5

loss

Définir action sur loss simule une perte de paquets. Vous pouvez également configurer les paramètres suivants.

Parameter	Type	Description	Default value	Required	Example
loss	string	Indicates the probability of packet loss. Range of value: [0, 100]	0	No	50
correlation	string	Indicates the correlation between the probability of current packet loss and the previous time's packet loss. Range of value: [0, 100]	0	No	50

duplicate

Définir action sur duplicate simule une duplication de paquets. À ce stade, vous pouvez également définir les paramètres suivants.

Parameter	Type	Description	Default value	Required	Example
duplicate	string	Indicates the probability of packet duplicating. Range of value: [0, 100]	0	No	50
correlation	string	Indicates the correlation between the probability of current packet duplicating and the previous time's packet duplicating. Range of value: [0, 100]	0	No	50

corrupt

Définir action sur corrupt simule une corruption de paquets. Vous pouvez également configurer les paramètres suivants.

Parameter	Type	Description	Default value	Required	Example
corrupt	string	Indicates the probability of packet corruption. Range of value: [0, 100]	0	No	50
correlation	string	Indicates the correlation between the probability of current packet corruption and the previous time's packet corruption. Range of value: [0, 100]	0	No	50

Pour les événements occasionnels comme reorder, loss, duplicate et corrupt, la correlation est plus complexe. Pour la description détaillée du modèle, consultez NetemCLG.

rate

Définir action sur rate signifie simuler une défaillance de débit réseau. Cette action est similaire à bandwidth/rate ci-dessous, mais la distinction clé est qu'elle peut être combinée avec d'autres actions netem mentionnées précédemment. Toutefois, si vous avez besoin d'un contrôle plus précis sur la simulation de bande passante, comme la limitation de la taille du tampon, consultez l'action bandwidth.

Parameter	Type	Description	Default value	Required	Example
rate	string	Indicates the rate of bandwidth limit. Allows bit, kbit, mbit, gbit, tbit, bps, kbps, mbps, gbps, tbps unit. bps means bytes per second		Yes	1mbps

bandwidth

Définir action sur bandwidth signifie simuler une limitation de bande passante. Vous devez également configurer les paramètres suivants.

info

Cette action est mutuellement exclusive avec toute action netem définie précédemment. Si vous devez injecter une limitation de débit avec d'autres défaillances réseau comme la corruption, utilisez plutôt l'action rate.

Parameter	Type	Description	Default value	Required	Example
rate	string	Indicates the rate of bandwidth limit. Allows bit, kbit, mbit, gbit, tbit, bps, kbps, mbps, gbps, tbps unit. bps means bytes per second		Yes	1mbps
limit	uint32	Indicates the number of bytes waiting in queue		Yes	1
buffer	uint32	Indicates the maximum number of bytes that can be sent instantaneously		Yes	1
peakrate	uint64	Indicates the maximum consumption of bucket (usually not set)		No	1
minburst	uint32	Indicates the size of peakrate bucket (usually not set)		No	1

Pour plus de détails sur ces champs, vous pouvez consulter la documentation tc-tbf. Il est recommandé de définir la limite à au moins 2 * rate * latency, où latency est la latence estimée entre la source et la cible, qui peut être mesurée via la commande ping. Une limit trop faible peut entraîner un taux de perte élevé et affecter le débit des connexions TCP.