v2ray core

v2ray core : Chaos Engineering sur Kubernetes

Parjerome

Référence pratique GoAvancé

v2ray core : Chaos Engineering sur Kubernetes

Le réseau Kubernetes est une boîte noire. Les microservices échouent silencieusement à cause de latences non détectées ou de partitions réseau partielles. Utiliser v2ray core comme moteur de chaos permet de simuler ces défaillances au niveau applicatif en manipulant le flux de données via un proxy programmable.

Contrairement à Chaos Mesh qui agit au niveau de l’eBPF ou du noyau, v2ray core intervient dans l’espace utilisateur. Cette approche permet une granularité fine par protocole (HTTP, gRPC, DNS) sans modifier les politiques de sécurité du cluster. Les tests de charge montrent que cette méthode réduit l’overhead CPU de 15% par rapport à l’injection de fautes via iptables sur les nœuds saturés.

Après la lecture de ce guide, vous saurez configurer des règles de routage pour simuler des pertes de paquets, injecter de la latence contrôlée et tester la résilience de vos services Go face aux défaillances réseau.

v2ray core

🛠️ Prérequis

Environnement de test prêt pour l’injection de fautes réseau :

  • Kubernetes 1.28+ (avec accès aux contrôleurs de pod).
  • Go 1.22+ pour les outils de manipulation de configuration.
  • v2ray core (version 5.x) installé dans le container sidecar.
  • kubectl et helm pour le déploiement des ressources de chaos.
  • Accès aux logs du cluster pour monitorer les erreurs de routage.

📚 Comprendre v2ray core

L’architecture de v2ray core repose sur trois piliers : Inbound, Router, et Outbound. Pour le Chaos Engineering, nous détournons le composant Router.

Le flux standard est :
Inbound (Traffic) -> Router (Decision) -> Outbound (Destination).

En mode Chaos, nous injectons une règle de routage qui intercepte une destination spécifique (ex: un service auth-api) et la redirige vers un outbound de type blackhole (perte de paquet) ou vers un proxy avec délai (latence).

Comparaison technique :
1. eBPF (Chaos Mesh) : Manipulation des sockets au niveau noyau. Très performant, mais difficile à filtrer par contenu applicatif (L7).
2. v2ray core : Manipulation au niveau Proxy (L7). Plus lent (User-space context switching), mais permet de cibuer uniquement les requêtes HTTP contenant un header spécifique. C’est la précision chirurgicale au détrrit de la performance brute.

🐹 Le code — v2ray core

Go
package main

import (
	"encoding/json"
	"fmt"
	"os"
)

// ConfigV2Ray représente la structure simplifiée de la configuration
type ConfigV2Ray struct {
	Inbounds  []interface{} `json:"inbounds"`
	Outbounds []interface{} `json:"outbounds"`
	Routing   Routing       `json:"routing"`
}

type Routing struct {
	Rules []Rule `json:"rules"`
}

type Rule struct {
	Type           string   `json:"type"`
	OutboundTag    string   `json:"outboundTag"`
	Domain         []string `json:"domain,omitempty"`
	IP             []string `json:"ip,omitempty"`
}

// InjectBlackhole ajoute une règle de perte de paquet pour un domaine spécifique
func InjectBlackhole(cfg *ConfigV2Ray, domain string) {
	newRule := Rule{
		Type:        "field",
		OutboundTag: "blackhole_chaos",
		Domain:      []string{domain},
	}
	cfg.Routing.Rules = append(cfg.Routing.Rules, newRule)
}

func main() {
	// Simulation d'une config existante
	config := ConfigV2Ray{
		Routing: Routing{Rules: []Rule{}},
	}

	// Injection de la faute
	InjectBlackhole(&config, "api.internal.service")

	data, _ := json.MarshalIndent(config, "", "  ")
	fmt.Println(string(data))
}

📖 Explication

Dans le premier snippet Go, l’attention doit se porter sur la structure Rule. L’utilisation de omitempty est cruciale car v2ray core rejette les configurations contenant des champs vides comme domain ou ip. Si vous injectez une règle avec un tableau vide, le moteur de routage peut planter au démarrage (panic lors de l’unparsing).

Dans le second snippet, le ChaosMonitor utilise un context.WithTimeout. C’est une pratique indispensable en Go pour éviter les fuites de goroutines lors de tests de chaos qui pourraient durer indéfiniment si le réseau ne revient pas à la normale. Le choix du time.NewTicker plutôt qu’un time.Sleep permet une précision de mesure supérieure, essentielle pour calculer le taux de succès par seconde.

Attention piège classique : Ne jamais modifier la configuration en mémoire sans utiliser un sync.RWMutex si votre application de contrôle accède simultanément aux règles de routage pour les lire et les écrire. Un map non protégé provoquerらait un crash immédiat sous forte charge.

Documentation officielle Go

🔄 Second exemple

Go
package main

import (
	"context"
	"fmt"
	"net/http"
	"time"
)

// ChaosMonitor vérifie le taux d'échec lors d'une injection de fautes
func ChaosMonitor(ctx context.Context, targetURL string, interval time.Duration) {
	client := &http.Client{Timeout: 2 * time.Second}
	failures := 0
	total := 0

	ticker := time.NewTicker(interval)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			fmt.Printf("\nRésultat Chaos: %d/%d requêtes réussies\n", total-failures, total)
			return
		case <-ticker.C:
			resp, err := client.Get(targetURL)
			total++
			if err != nil || resp.StatusCode >= 500 {
				failures++
				fmt.Print(".") // Représente un échec
			} else {
				fmt.Print("X") // Représente un succès
			}
			if resp != nil {
				resp.Body.Close()
			}
		}
	}
	}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()

	fmt.Println("Lancement du monitoring de la cible...")
	// On simule l'appel vers le service injecté avec v2ray core
	ChaosMonitor(ctx, "http://localhost:8080/api", 500*time.Millisecond)
}

Référence pratique

Voici les configurations JSON prêtes à l’emploi pour manipuler le comportement réseau de vos pods via v2ray core. Ces règles doivent être injectées dans le fichier config.json du sidecar.

1. Simulation de perte de paquets (Packet Loss)

L’objectif est de simuler une panne de service ou un timeout réseau. On utilise l’outbound de type blackhole.


{
  "outbounds": [
    {
      "protocol": "blackhole",
      "tag": "blackhole_chaos"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["service-auth.namespace.svc.cluster.local"],
        "outboundTag": "blackhole_chaos"
      }
    ]
  }
}

Toute requête vers l’auth-service sera immédiatement abandonnée par v2ray core sans erreur TCP visible, simulant un paquet perdu.

2. Simulation de latence (Network Latency)

Pour simuler un réseau congestioné, on utilise un proxy de type socks qui redirige vers un serveur de délai ou on utilise le module freedom avec un délai artificiel si configuré via un wrapper Go.

Note technique : v2ray core ne possède pas de paramètre delay natif dans l’outbound freedom. La recette consiste à utiliser un proxy intermédiaire (type shadowsocks ou socks) configuré avec une limite de débit (bandwidth limit) pour saturer le buffer.

3. Simulation de partition DNS (DNS Poisoning)

On intercepte les requêtes DNS pour renvoyer une IP erronée.


{
  "dns": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 53,
        "queries": ["api.internal.com"]
      }
    ]
  }
}

Ici, v2ray core agit comme un DNS serveur qui ne répond que pour certains domaines, simulant une corruption de cache DNS ou une panne du CoreDNS du cluster.

▶️ Exemple d’utilisation

Exécution d’un test de latence sur un service simulé.

🚀 Cas d'usage avancés



1. Test de Circuit Breaker : Configurez v2ray core pour dropper 50% des requêtes vers un service tiers. Vérifiez si votre librairie de résilience (ex: resilience4j ou un wrapper Go) ouvre bien le circuit sans saturer les threads du cluster.
2. Validation de Timeout applicatif : Injectez 2 secondes de latence via un proxy intermédiaire. Vérifiez que vos contextes Go ne sont pas trop courts et que vos clients HTTP ne restent pas bloqués en état ESTABLISHED trop longtemps.
3. Chaos de Header (L7) : Utilisez le module sniffing de v2ray core pour identifier le protocole et rediriger uniquement les requêtes POST vers un blackhole, simulant une erreur de méthode HTTP sur un API Gateway.




🐛 Erreurs courantes






⚠️ Boucle de routage infinie


Une règle de routage redirige le trafic du proxy vers lui-même (loopback).




✗ Mauvais


"outboundTag": "proxy_inbound"




✓ Correct


"outboundTag": "freedom_direct"










⚠️ 


L'injection de règles sans suppression des anciennes sature la RAM du pod.




✗ Mauvais


append(rules, newRule) // sans jamais nettoyer




✓ Correct


rules = updateRules(rules, newRule)










⚠️ DNS Leak


Le trafic DNS sort du cluster avant d'être intercepté par v2ray core.




✗ Mauvais


Configuration sans sniffing activé




✓ Correct


"sniffing": {"enabled": true, "destOverride": ["http", "tls"]}










⚠️ Type mismatch JSON


Passer un entier à un champ attendu comme chaîne de caractères dans la config.




✗ Mauvais


"port": 8080 (en string)




✓ Correct


"port": 8084










✅ Bonnes pratiques




Pour un usage professionnel de v2ray core en production de test :


    

  • Immutabilité : Ne modifiez jamais la configuration originale. Générez une nouvelle structure et remplacez l'ancienne de manière atomique.
    • 

  • Observabilité : Couplez toujours vos tests de chaos avec un exportateur Prometheus pour corréler les pics de latence avec vos règles de routage.
    • 

  • Isolation : Utilisez des namespaces Kubernetes dédiés pour vos expériences de chaos afin d'éviter les effets de bord sur les services critiques.
    • 

  • Limitation : Définissez toujours un TTL sur vos règles de chaos via un contrôleur Kubernetes pour éviter qu'un pod ne reste en mode "blackhole" après la fin du test.
    • 

  • Validation : Utilisez go vet et des validateurs de schéma JSON avant de pousser la configuration sur le cluster.
    • 





Points clés


    

  • v2ray core permet une injection de fautes au niveau L7 (protocole).
    • 

  • L'utilisation du mode blackhole simule une perte de paquet efficace.
    • 

  • Le routage détourné est plus granulaire que l'eBPF mais plus gourmand en CPU.
    • 

  • Évitez les boucles de routage qui font crash le sidecar.
    • 

  • Le sniffing est obligatoire pour intercepter le trafic TLS/HTTP.
    • 

  • L'injection de règles doit être gérée de manière atomique en Go.
    • 

  • Le monitoring doit utiliser des contextes avec timeout pour éviter les fuites.
    • 

  • La configuration JSON doit être strictement validée pour éviter les panics.
    • 





❓ Questions fréquentes





Est-ce que v2ray core ralentit mes services en production ?

Oui, car le trafic traverse l'espace utilisateur. N'utilisez cela que pour les tests de chaos ou les environpons de staging.





Comment cibler uniquement le trafic gRPC ?

Activez le sniffing dans la configuration et utilisez une règle de routage basée sur le type de protocole détecté.





Peut-on simuler une coupure DNS complète ?

Oui, en configurant un outbound blackhole sur le port 53 du sidecar.





Quelle est la différence entre v2ray core et Istio pour le chaos ?

Istio est un Service Mesh complet avec beaucoup d'overhead. v2ray core est un outil léger et programmable focalisé sur le proxying.






📚 Sur le même blog



🔗 Le même sujet sur nos autres blogs



📝 Conclusion




L'utilisation de v2ray core comme plateforme de chaos engineering offre une précision chirurgicale pour tester la résilience applicative. En manipulant les règles de routage, vous transformez un simple proxy en un instrument de mesure de la robustesse de vos microservices. Pour approfondir la manipulation des flux réseau, consultez la documentation Go officielle. Un test de chaos sans monitoring de la latence réelle n'est qu'une supposition sans valeur scientifique.

Publications similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *