Compétences istio-traffic-management
🔀

istio-traffic-management

Sûr

Maîtriser le trafic Istio comme un pro

Également disponible depuis: wshobson

Simplifiez la configuration du service mesh Istio avec des modèles prêts pour la production : routage, déploiements canary, disjoncteurs et migration de trafic. Éliminez les essais et erreurs grâce à des schémas éprouvés.

Prend en charge: Claude Codex Code(CC)
🥉 75 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "istio-traffic-management". Create a canary deployment with 10% traffic

Résultat attendu:

Génère un VirtualService avec routage pondéré (90% stable, 10% canary) et DestinationRule définissant les deux subsets avec les labels de version

Utilisation de "istio-traffic-management". Add retries and timeout to orders service

Résultat attendu:

Crée un VirtualService avec 3 tentatives de retry, 3s de timeout par tentative et 10s de timeout global pour l'hôte orders

Utilisation de "istio-traffic-management". Set up circuit breaker for checkout service

Résultat attendu:

Génère une DestinationRule avec des limites de pool de connexions et détection des outliers incluant consecutive5xxErrors et baseEjectionTime

Audit de sécurité

Sûr
v1 • 2/25/2026

All static analysis findings are false positives. The skill contains only YAML configuration templates and documentation for Istio traffic management. The 'external commands' flagged are bash commands in markdown documentation blocks (istioctl commands). The 'weak cryptographic algorithm' warnings are triggered by Istio API version strings (v1beta1) in YAML headers, not actual crypto. The 'hardcoded URLs' are legitimate links to official Istio documentation. No executable code, no security risks, no prompt injection attempts detected.

1
Fichiers analysés
340
Lignes analysées
1
résultats
1
Total des audits
Problèmes à risque faible (1)
SKILL.md:22SKILL.md:46-49SKILL.md:337-339
Static Analysis False Positives
All 44 detected patterns are false positives from documentation and YAML templates. The 'external_commands' patterns are bash commands in markdown code blocks (istioctl). The 'weak cryptographic algorithm' patterns are Istio API version strings (v1beta1). The 'hardcoded URLs' are official documentation links.
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
100
Conformité aux spécifications

Ce que vous pouvez construire

Ingénieur plateforme configurant des déploiements canary

Configurez un déploiement progressif du trafic de la version stable vers la version canary avec un routage pondéré et un rollback automatique en cas d'échec.

Ingénieur DevOps implémentant des modèles de résilience

Ajoutez des disjoncteurs, des retries et des timeouts pour éviter les défaillances en cascade et améliorer la fiabilité du service.

SRE déboguant les problèmes de routage traffic

Utilisez les commandes istioctl pour analyser et valider les configurations VirtualService et DestinationRule dans les clusters de production.

Essayez ces prompts

Créer un routage de service de base 
Create a VirtualService for my-service that routes traffic based on the x-user header. Send users with header value 'beta' to v2 subset, all others to v1.
Configurer un déploiement canary 
Set up a canary deployment for payment-service. Route 95% of traffic to stable version, 5% to canary. Include DestinationRule with both subsets.
Ajouter une protection par disjoncteur 
Create a DestinationRule for api-service with circuit breaker settings: max 100 connections, 1000 HTTP requests, eject pods after 5 consecutive errors, 30s base ejection time.
Configurer la mise en miroir du trafic 
Set up traffic mirroring from production to staging. Mirror 100% of requests to v2 subset for testing without affecting live traffic.

Bonnes pratiques

  • Testez toujours les configurations Istio avec istioctl analyze avant de les appliquer en production
  • Commencez par des règles VirtualService simples et ajoutez de la complexité de manière progressive
  • Surveillez les modèles de trafic avec les tableaux de bord Kiali après le déploiement de nouvelles règles de routage
  • Utilisez des noms de subsets significatifs (stable, canary, v1, v2) et étiquetez les services de manière cohérente

Éviter

  • Ne configurez pas de retries sans limites - cela peut provoquer des défaillances en cascade
  • Évitez de mettre en miroir le trafic vers des bases de données de production - mirroisez uniquement vers les environnements de test
  • Ne skippez jamais la validation des subsets dans les DestinationRules - les subsets non définis provoquent des échecs de routage
  • N'utilisez pas immédiatement 100% de poids canary - commencez toujours par de petits pourcentages

Foire aux questions

Quelle est la différence entre VirtualService et DestinationRule ?
VirtualService contrôle comment le trafic est routé vers les destinations (règles de routage). DestinationRule définit les politiques appliquées après le routage (équilibrage de charge, disjoncteurs, subsets).
Comment augmenter progressivement le trafic canary ?
Mettez à jour les valeurs de poids dans VirtualService de manière progressive (5%, 10%, 25%, 50%, 100%). Surveillez les métriques à chaque étape avant de continuer.
Pourquoi mon trafic n'atteint-il pas le subset canary ?
Vérifiez que les pods ont les bons labels de version correspondant aux subsets DestinationRule. Vérifiez istioctl proxy-config endpoints pour voir quels endpoints sont enregistrés.
Puis-je utiliser cette skill sans Istio installé ?
Non. Cette skill fournit des modèles de configuration Istio. Vous devez avoir Istio installé dans votre cluster Kubernetes avant d'appliquer ces ressources.
Comment déboguer les problèmes de routage ?
Utilisez istioctl analyze pour valider la configuration, istioctl proxy-config routes pour voir les routes effectives, et istioctl proxy-config log pour activer le logging de débogage.
À quoi sert la mise en miroir du trafic ?
La mise en miroir du trafic envoie des copies des requêtes actives vers un service miroir (typiquement v2 ou staging) pour les tests sans affecter les vrais utilisateurs. Les réponses miroirs sont ignorées.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/istio-traffic-management

Réf

main

Structure de fichiers

📄 SKILL.md