linkerd-patterns
إعداد Linkerd Service Mesh
يؤدي تنفيذ شبكة الخدمات إلى زيادة تعقيد مجموعات Kubernetes. توفر هذه المهارة قوالب وأنماط جاهزة للاستخدام لـ Linkerd، وهي شبكة خدمات CNCF خفيفة الوزن التي تمكّن من mTLS تلقائي، وتجزئة حركة المرور، وشبكات الثقة صفر مع حد أدنى من الحمل التكويني.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "linkerd-patterns". Generate a TrafficSplit for canary deployment with 90/10 split
النتيجة المتوقعة:
- ```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
- ```
استخدام "linkerd-patterns". Create ServerAuthorization for authenticated clients only
النتيجة المتوقعة:
- ```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
- ```
التدقيق الأمني
آمنAll 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.
عوامل الخطر
🌐 الوصول إلى الشبكة (7)
⚙️ الأوامر الخارجية (20)
درجة الجودة
ماذا يمكنك بناءه
إعداد Linkerd للمرة الأولى
يمكن لمهندسي DevOps الجدد في Linkerd استخدام هذه المهارة لتوليد أوامر التثبيت الكاملة، وتكوينات حقن المساحة، وخطوات التحقق لنشر شبكة خدمات جاهز للإنتاج.
تكوين إدارة حركة المرور المتقدمة
يمكن لمهندسي المواقع وموظفة حركة المرور إنشاء تكوينات ServiceProfile مع إعادة المحاولات المخصصة، والمهلات، وموارد TrafficSplit للنشر الأزرق والأخضر والإصدارات التجريبية.
تنفيذ سياسات الشبكة ذات الثقة الصفر
يمكن لفرق الأمان توليد سياسات ServerAuthorization التي تقيد التواصل بين الخدمات للعملاء المصادق عليهم فقط، متطلبات الامتثال لبنيات الثقة صفر.
جرّب هذه الموجهات
توليد الأوامر وقوالب YAML لتثبيت Linkerd على مجموعة Kubernetes الخاصة بي. يشمل التحقق المسبق، وتثبيت CRDs، وإعداد مستوى التحكم، وملحقات viz للمراقبة.
إنشاء Linkerd ServicePattern لخدمة api-service الخاصة بي مع تكوين إعادة المحاولة. يجب أن تكون طلبات GET قابلة لإعادة المحاولة بنسبة إعادة محاولة 0.2. تعيين مهلة 5 ثوانٍ على استدعاءات النقطة النهائية.
توليد تكوين TrafficSplit لتوجيه 10% من حركة المرور إلى my-service-canary مع الاحتفاظ بـ 90% على my-service-stable لنشر تجريبي مضبوط.
إنشاء سياسة ServerAuthorization تسمح فقط لحساب خدمة الواجهة الأمامية الخاصة بي بالوصول إلى خادم api على المنفذ 8080. يجب رفض جميع حركة المرور الأخرى افتراضياً.
أفضل الممارسات
- قم دائماً بتشغيل linkerd check بعد أي تغيير في التكوين للتحقق من صحة الشبكة الصحية قبل نشر التغييرات على حركة مرور الإنتاج.
- مكّن mTLS التلقائي على جميع المساحات افتراضياً لضمان تشفير وتوثيق جميع الاتصالات بين الخدمات دون إدارة شهادات يدوية.
- استخدم ServiceProfiles لتعريف المهلات وإعادة المحاولات لكل مسار التي تتطابق مع دلالات التطبيق الخاص بك، مما يمنع الفشل المتتالي أثناء مشاكل المنبع.
تجنب
- تخطي linkerd check بعد التثبيت أو تغييرات التكوين يمكن أن يؤدي إلى فشل صامت حيث لا تعمل شبكة الخدمات كما هو متوقع.
- تكوين سياسات ServerAuthorization واسعة جداً مع وصول غير مصادق عليه يهدم الغرض من شبكات الثقة صفر ويجب تقييدها على مسارات الدخول المحددة.
- تعيين ميزانيات إعادة المحاولة مرتفعة جداً يمكن أن يسبب عواصف إعادة المحاولة أثناء انهيارات الخدمة، إرهاق الخدمات المنخفضة وتدهور استقرار النظام الكلي.
الأسئلة المتكررة
هل تنفذ هذه المهارة أوامر على مجموعتي؟
ما إصدار Linkerd المدعوم؟
هل يمكنني استخدام هذا مع خدمات Kubernetes المُدارة؟
كيف يختلف Linkerd عن Istio؟
هل أحتاج إلى توليد الشهادات يدوياً؟
هل يمكن لهذه المهارة المساعدة في استكشاف الأخطاء؟
تفاصيل المطور
المؤلف
wshobsonالترخيص
MIT
المستودع
https://github.com/wshobson/agents/tree/main/plugins/cloud-infrastructure/skills/linkerd-patternsمرجع
main
بنية الملفات
📄 SKILL.md