شبكة الخدمات: Istio وLinkerd

Linkerd: شبكة الخدمات الخفيفة

18 دقيقة الدرس 8 من 27

Linkerd: شبكة الخدمات الخفيفة

يهيمن Istio على النقاشات المتعلقة بشبكات الخدمات، لكنه ليس الخيار الوحيد للبيئات الإنتاجية — وفي كثير من حالات العمل، ليس الخيار الأنسب. Linkerd، مشروع CNCF المتخرج الذي تصونه شركة Buoyant، ينتهج فلسفة مختلفة جذريًا: أن تتقن شيئًا واحدًا، وتبقي البنية خفيفة، وتجعل العمليات شفافة تمامًا لفرق التطبيقات. في الشركات التي تُشغّل عشرات الخدمات على مجموعات متوسطة الحجم — أو في المؤسسات التي جرّبت Istio ووجدت تكلفته التشغيلية مرتفعة — يكون Linkerd في الغالب الخيار الأوفق.

يتناول هذا الدرس بنية Linkerd والمقايضات التي تحكمها، والحالات العملية التي يُجدي فيها اختيار الشبكة الأخف ثمنه في بيئات الإنتاج.

فلسفة Linkerd

بُنِي Linkerd حول ثلاثة قيود تصميمية صريحة تميّزه عن Istio:

وكيل Rust المصغّر بدلًا من Envoy. يُشحن Linkerd بوكيله الخاص — linkerd2-proxy — المكتوب بالكامل بلغة Rust، وينفّذ فقط المزايا التي تحتاجها الشبكة: توجيه TCP/HTTP2/gRPC، ومTLS، وإعادة المحاولات، والمهل، والمقاييس. يبلغ حجم الملف التنفيذي نحو 7 ميجابايت ويستهلك حوالي 10 ميجابايت من ذاكرة الوصول العشوائي في وضع الخمول، مقارنةً بـ 50–100 ميجابايت لـ Envoy. عند تشغيل 200 حاوية على عقدة واحدة، يظهر هذا الفارق بوضوح في التكاليف الفعلية.
صفر تكوين لنسبة الـ 80%. يمنحك حقن الوكيل الجانبي بأمر linkerd inject (أو الحقن التلقائي عبر التعليق التوضيحي) على الفور mTLS ومقاييس الذهب (معدل النجاح، زمن الاستجابة P50/P95/P99، الطلبات/الثانية) وإعادة المحاولات — دون الحاجة إلى تأليف VirtualService أو DestinationRule أو EnvoyFilter.
Kubernetes-native لا Kubernetes-adjacent. تتكوّن مستوى التحكم في Linkerd من ثلاثة نشرات فقط (linkerd-destination وlinkerd-identity وlinkerd-proxy-injector) بالإضافة إلى امتداد linkerd-viz الاختياري. يعتمد على RBAC وSecrets وwebhooks الخاصة بـ Kubernetes القياسية.

حالة CNCF: تخرّج Linkerd عام 2021 — وهو أحد المشاريع النادرة التي بلغت هذا المستوى. تُتيح Buoyant الكود المصدري مفتوحًا، وتبيع توزيعة مؤسسية (BEL) تضم multi-cluster وشهادات FIPS-140 ودعمًا مضمون الخدمة.

بنية Linkerd

تنقسم مسؤوليات مستوى التحكم على ثلاثة مكوّنات مستقلة:

linkerd-identity — يعمل بوصفه سلطة شهادات الشبكة، ويُصدر شهادات x.509 متوافقة مع SPIFFE قصيرة الأمد (24 ساعة افتراضيًا) لكل وكيل جانبي.
linkerd-destination — محرك اكتشاف الخدمات والسياسات. تتدفق الوكلاء عبر gRPC لاستقبال تحديثات النقاط النهائية، وتُترجم هذا المكوّن CRDs الخاصة بـ Linkerd إلى توجيهات للوكيل.
linkerd-proxy-injector — webhook قبول طافر يحقن حاوية linkerd2-proxy في الحاويات (pods) التي تحمل التعليق التوضيحي linkerd.io/inject: enabled.

مستوى التحكم في Linkerd (3 مكوّنات) يُصدر الشهادات ويوجّه وكلاء linkerd2-proxy المكتوبة بـ Rust التي تعالج كل حركة المرور بين الحاويات.

تثبيت Linkerd وحقن الشبكة

يتبع التثبيت نهج CLI أولًا. تتحقق واجهة أوامر linkerd من متطلبات ما قبل التثبيت، وتُنشئ قيم Helm، وتوفّر لوحة تحكم حية — وهي مكافئة لـ istioctl لكن أكثر تقييدًا في خياراتها.

# 1. تثبيت واجهة أوامر Linkerd (اختر إصدارًا مستقرًا مثل stable-2.14.x)
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin

# 2. فحص ما قبل التثبيت — التحقق من توافق المجموعة
linkerd check --pre

# 3. تثبيت CRDs (مخطط منفصل منذ Linkerd 2.12+)
linkerd install --crds | kubectl apply -f -

# 4. تثبيت مستوى التحكم
linkerd install \
  --set controllerReplicas=2 \
  --set identityTrustAnchorsPEM="$(cat ca.crt)" \
  --set identity.issuer.tls.crtPEM="$(cat issuer.crt)" \
  --set identity.issuer.tls.keyPEM="$(cat issuer.key)" \
  | kubectl apply -f -

# 5. الانتظار حتى اكتمال الطرح وتشغيل فحوصات الصحة
linkerd check

# 6. حقن الشبكة في namespace (عبر التعليق التوضيحي، دون تعديل YAML لكل حاوية)
kubectl annotate namespace production linkerd.io/inject=enabled

# 7. إعادة التشغيل الدوار لاستقبال الوكيل الجانبي في الحاويات القائمة
kubectl rollout restart deployment -n production

# 8. التحقق من نجاح الحقن
linkerd -n production check --proxy

تكامل cert-manager: في بيئات الإنتاج، استخدم linkerd install --identity-external-issuer وأصدر مرساة الثقة عبر cert-manager بمورد Certificate مدعوم بـ Vault أو AWS ACM PCA. يتيح ذلك تدوير CA الجذر دون إعادة تثبيت الشبكة.

سياسة حركة المرور: ServiceProfile و HTTPRoute

إدارة حركة المرور في Linkerd أقل تعقيدًا من Istio عن قصد، لكنها تغطي 90% من احتياجات الخدمات المصغّرة. الكائنان الرئيسيان هما:

ServiceProfile — ميزانيات إعادة المحاولة، والمهل، وتصنيف الاستجابات لكل مسار. يُنشأ في namespace الخادم ويُستهلك من جميع العملاء.
HTTPRoute (Gateway API) — اعتمد Linkerd 2.12+ على Gateway API للتوجيه بالترويسات وتقسيم حركة المرور، ليحل محل كائن TrafficSplit القديم.

# ServiceProfile — تحديد ميزانية إعادة المحاولة والمهلة لكل مسار
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: orders.production.svc.cluster.local
  namespace: production
spec:
  routes:
  - name: POST /orders
    condition:
      method: POST
      pathRegex: /orders
    responseClasses:
    - condition:
        status:
          min: 500
          max: 599
      isFailure: true
    timeout: 500ms
    retryBudget:
      retryRatio: 0.2        # حتى 20% طلبات إضافية تكون إعادة محاولات
      minRetriesPerSecond: 10
      ttl: 10s
  - name: GET /orders/{id}
    condition:
      method: GET
      pathRegex: /orders/[^/]+
    timeout: 200ms
    isRetryable: true        # آمن لإعادة المحاولة تلقائيًا
---
# HTTPRoute — تقسيم canary (Gateway API v1beta1)
apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
  name: orders-canary
  namespace: production
spec:
  parentRefs:
  - name: orders
    kind: Service
    group: core
    port: 8080
  rules:
  - backendRefs:
    - name: orders-stable
      port: 8080
      weight: 90
    - name: orders-canary
      port: 8080
      weight: 10

سياسة التفويض

نموذج السياسة في Linkerd أبسط من AuthorizationPolicy في Istio، لكنه ذو حبيبية كافية في الممارسة. يُعلن كائن Server عن المنفذ المحمي في حاوية معينة، بينما تُحدد كائنات ServerAuthorization حسابات الخدمة المسموح لها بالاتصال.

# رفض كل الاتصالات الواردة افتراضيًا، ثم السماح للمتصلين المحددين
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: orders-grpc
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: orders
  port: 9090
  proxyProtocol: gRPC
---
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: orders-grpc-allow-checkout
  namespace: production
spec:
  server:
    name: orders-grpc
  client:
    meshTLS:
      serviceAccounts:
      - name: checkout
        namespace: production

المراقبة: امتداد Viz

ثبّت linkerd viz للحصول على كشط Prometheus ولوحات Grafana ولوحة التحكم الويب مع مقاييس الذهب لكل مسار. الامتداد اختياري عن قصد — يمكنك تخطيّه وكشط المقاييس مباشرةً من نقاط نهاية /metrics للوكيل إذا كان لديك Prometheus مسبقًا.

# تثبيت امتداد viz
linkerd viz install | kubectl apply -f -
linkerd viz check

# فتح لوحة التحكم الحية (إعادة توجيه المنفذ تلقائيًا)
linkerd viz dashboard &

# مقاييس الذهب عبر CLI لنشر معين
linkerd viz stat deploy -n production

# تنصت حي لحركة المرور (مشابه لسجلات Envoy لكن منظمة)
linkerd viz tap deploy/orders -n production \
  --to deploy/payments \
  --path /charge

# أعلى المسارات بحسب زمن الاستجابة
linkerd viz routes deploy/orders -n production --to deploy/payments

Viz يُشحن مع Prometheus خاص به. يقتصر على احتفاظ قصير الأمد (6 ساعات افتراضيًا) للوحة التحكم. لا تعتمد عليه كمخزن مقاييس طويل المدى — بدلًا من ذلك استخدم --set prometheusUrl=http://prometheus.monitoring:9090 لتوجيه Viz إلى نسخة Prometheus خارجية.

متى يتفوق Linkerd على Istio

جدول المقايضة واضح وعملي. اختر Linkerd عندما:

حجم المجموعة أقل من 500 حاوية وفريقك أقل من 10 مهندسين — تكلفة Istio التشغيلية (انتشار CRDs، وتعقيد xDS، وضبط Istiod) تتجاوز قيمة مزاياه.
تحتاج فقط mTLS ومقاييس الذهب — يوفرهما Linkerd فور التثبيت دون أي تأليف YAML.
عقد محدودة الموارد — عقد الحافة، أو أنواع الحالات القابلة للتفجير، أو المواقع التي لا تُقبل فيها ميزانية RAM لـ Envoy.
إعداد سريع — أمر check ولوحة الويب في Linkerd يُقلّصان وقت الحصول على أول رؤية بشكل ملحوظ للفرق الجديدة على مفهوم الشبكة.

اختر Istio (الدروس 3–6) عندما تحتاج إلى توجيه L7 متقدم (مستند إلى JWT، أو عكس الترويسات، أو حقن الأعطال على نطاق واسع)، أو بوابات east-west متعددة المجموعات، أو كنت تستثمر أصلًا في منظومة Envoy للحافة وتريد لغة تحكم موحّدة عبر كامل البنية.

مقارنة مع وضع Ambient: تناول الدرس الثاني وضع Ambient في Istio الذي يُزيل الوكيل الجانبي تمامًا عبر ztunnel لكل عقدة. ردّ Linkerd هو وضعه الخاص بدون وكيل جانبي — لا يزال في مرحلة alpha حتى 2025. لا تعتمد على أي منهما في بيئات خاضعة للتنظيم حتى تصدر إشارات تخرّج واضحة من CNCF.

أنماط الفشل في الإنتاج الخاصة بـ Linkerd

انتهاء صلاحية مرساة الثقة. لمرساة الثقة الافتراضية الموقّعة ذاتيًا صلاحية 10 سنوات، لكن إن أصدرت واحدة قصيرة الأمد (شائع مع cert-manager)، فإن انتهاء صلاحيتها يُعطّل mTLS عبر الشبكة بأكملها بصمت. راقب مقياس linkerd_identity_cert_expiration_timestamp_seconds وأنشئ تنبيهًا عند اقتراب 30 يومًا.
ServiceProfile في namespace خاطئ. يجب إنشاء ServiceProfile في namespace الخادم. وضعه في namespace العميل لا يُنتج أي خطأ لكنه لا يُطبَّق — تمرّ إعادة المحاولات والمهل دون تأثير.
عدم ترقية linkerd2-proxy. بعد ترقية مستوى التحكم، تحتفظ الحاويات القائمة بالإصدار القديم من الوكيل. شغّل linkerd viz stat --proxy-version-mismatch للعثور على المتخلّفين ثم أعد تشغيلها دوريًا.
حاوية init في Jobs. لا يتلقى الوكيل في Jobs إشارة إيقاف عند اكتمال المهمة، مما يُبقي الحاوية معلّقة. الحل هو ضبط config.linkerd.io/proxy-wait-before-exit-seconds: "0" واستدعاء إيقاف تشغيل الوكيل عبر خطاف postStop.

الخلاصة

يُثبت Linkerd أن الأداة الصحيحة ليست دائمًا الأكثر قوةً. يوفّر وكيل Rust المصغّر وسطح CRD المحدود والإعدادات الافتراضية المتضمّنة (mTLS، مقاييس الذهب، ميزانيات إعادة المحاولة) حلًا للمشكلات الفعلية لمعظم الفرق، بجزء من ثقل Istio التشغيلي. في الإنتاج، يجب أن تستند مقايضة اختيار الشبكة إلى متطلبات ملموسة — لا إلى مؤتمرات أو عروض البائعين. للغالبية العظمى من حمولات Kubernetes اليوم، البدء بـ Linkerd والانتقال إلى Istio فقط عندما يصبح فجوة الميزات حقيقية هو الخيار الافتراضي للمهندس الأول.