linkerd-patterns
Configurer Linkerd Service Mesh
La mise en œuvre d'un service mesh ajoute de la complexité aux clusters Kubernetes. Cette compétence fournit des modèles et des schémas prêts à l'emploi pour Linkerd, le service mesh CNCF léger qui permet le mTLS automatique, le fractionnement du trafic et le réseau zero-trust avec une surcharge de configuration minimale.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "linkerd-patterns". Generate a TrafficSplit for canary deployment with 90/10 split
Résultat attendu:
- ```yaml
- apiVersion: split.smi-spec.io/v1alpha1
- kind: TrafficSplit
- metadata:
- name: my-service-canary
- namespace: my-namespace
- spec:
- service: my-service
- backends:
- - service: my-service-stable
- weight: 900m
- - service: my-service-canary
- weight: 100m
- ```
Utilisation de "linkerd-patterns". Create ServerAuthorization for authenticated clients only
Résultat attendu:
- ```yaml
- apiVersion: policy.linkerd.io/v1beta1
- kind: ServerAuthorization
- metadata:
- name: allow-frontend
- namespace: my-namespace
- spec:
- server:
- name: my-service-http
- client:
- meshTLS:
- serviceAccounts:
- - name: frontend
- namespace: my-namespace
- ```
Audit de sécurité
SûrAll static findings evaluated as false positives. The skill contains only documentation and YAML templates for Linkerd service mesh. Patterns detected (URLs, shell pipes, network CIDRs) are legitimate infrastructure documentation. No actual code execution, cryptographic operations, or malicious patterns present.
Facteurs de risque
🌐 Accès réseau (7)
⚙️ Commandes externes (20)
Score de qualité
Ce que vous pouvez construire
Configuration de Linkerd pour la première fois
Les ingénieurs DevOps débutants avec Linkerd peuvent utiliser cette compétence pour générer des commandes d'installation complètes, des configurations d'injection d'espace de noms et des étapes de vérification pour un déploiement de service mesh prêt pour la production.
Configuration de la gestion avancée du trafic
Les SRE et les ingénieurs du trafic peuvent créer des configurations ServiceProfile avec des nouvelles tentatives personnalisées, des délais d'expiration et des ressources TrafficSplit pour les déploiements blue-green et les versions canary.
Mise en œuvre des politiques réseau Zero-Trust
Les équipes de sécurité peuvent générer des politiques ServerAuthorization qui limitent la communication service-à-service aux clients authentifiés, prenant en charge les exigences de conformité pour les architectures zero-trust.
Essayez ces prompts
Générer les commandes et les modèles YAML pour installer Linkerd sur mon cluster Kubernetes. Inclure la validation de pré-vérification, l'installation des CRD, la configuration du plan de contrôle et l'extension viz pour l'observabilité.
Créer un Linkerd ServiceProfile pour mon api-service avec la configuration des nouvelles tentatives. Les requêtes GET doivent être retentables avec un ratio de nouvelle tentative de 0.2. Définir un délai d'expiration de 5 secondes sur les appels de point de terminaison.
Générer une configuration TrafficSplit pour acheminer 10% du trafic vers my-service-canary tout en gardant 90% sur my-service-stable pour un déploiement canary contrôlé.
Créer une politique ServerAuthorization qui permet uniquement à mon compte de service frontend d'accéder à l'api-server sur le port 8080. Tout autre trafic doit être refusé par défaut.
Bonnes pratiques
- Toujours exécuter linkerd check après toute modification de configuration pour valider que le mesh est sain avant de déployer les modifications sur le trafic de production.
- Activer le mTLS automatique sur tous les espaces de noms par défaut pour garantir que toute la communication service-à-service est chiffrée et authentifiée sans gestion manuelle de certificats.
- Utiliser les ServiceProfiles pour définir les délais d'expiration et les nouvelles tentatives par itinéraire qui correspondent à la sémantique de votre application, évitant les défaillances en cascade lors des problèmes en amont.
Éviter
- Sauter linkerd check après l'installation ou les modifications de configuration peut entraîner des échecs silencieux où le service mesh ne fonctionne pas comme prévu.
- Configurer des politiques ServerAuthorization trop larges avec un accès non authentifié va à l'encontre de l'objectif du réseau zero-trust et devrait être limité à des voies d'entrée spécifiques.
- Définir des budgets de nouvelles tentatives trop élevés peut provoquer des tempêtes de nouvelles tentatives pendant les pannes, submergeant les services en aval et dégradant la stabilité globale du système.
Foire aux questions
Cette compétence exécute-t-elle des commandes sur mon cluster ?
Quelle version de Linkerd est prise en charge ?
Puis-je l'utiliser avec des services Kubernetes gérés ?
Comment Linkerd diffère-t-il d'Istio ?
Dois-je générer les certificats manuellement ?
Cette compétence peut-elle aider au dépannage ?
Détails du développeur
Auteur
wshobsonLicence
MIT
Dépôt
https://github.com/wshobson/agents/tree/main/plugins/cloud-infrastructure/skills/linkerd-patternsRéf
main
Structure de fichiers
📄 SKILL.md