أعلن مجتمع Linkerd عن إطلاق Linkerd 2.20، الذي يقدم سلسلة من تحسينات الأداء وإمكانية المراقبة وإدارة حركة المرور التي تزيد من تعزيز مكانة شبكة الخدمة المتدرجة CNCF كبديل خفيف الوزن لشبكات Kubernetes. يضيف الإصدار موازنة تحميل مع مراعاة الحد الأقصى للمعدل، ويقلل بشكل كبير من استهلاك ذاكرة مستوى التحكم، ويحسن مقاييس حركة المرور الواردة، ويواصل تركيز Linkerd على البساطة التشغيلية دون التضحية بالموثوقية أو الأمان على مستوى المؤسسة.
ومن بين التحسينات الرئيسية، مستوى التحكم المُعاد تصميمه والذي يقلل من استخدام الذاكرة بما يصل إلى 85% في ظل ارتفاع عدد الكبسولات، مما يمكّن المشغلين من تشغيل Linkerd بكفاءة على كل من المجموعات المحدودة الموارد وبيئات الإنتاج واسعة النطاق. إلى جانب توجيه حركة المرور الأكثر ذكاءً وإمكانية المراقبة المحسنة، يعكس الإصدار تركيز المشروع المستمر على حل التحديات التشغيلية في العالم الحقيقي بدلاً من توسيع تعقيد الميزات.
تتمثل الإمكانية الرئيسية في Linkerd 2.20 في موازنة التحميل مع مراعاة الحد الأقصى للمعدل. تقوم شبكات الخدمة التقليدية بتوزيع حركة المرور استنادًا بشكل أساسي إلى زمن الوصول وتوافر نقطة النهاية، لكن واجهات برمجة التطبيقات الحديثة تقوم بشكل متزايد بتوصيل حالات التحميل الزائد باستخدام استجابات حد معدل HTTP بدلاً من الفشل التام.
يتعرف Linkerd الآن على هذه الإشارات ويقوم تلقائيًا بضبط قرارات التوجيه، وتوجيه الطلبات مؤقتًا بعيدًا عن الخدمات التي تقيد حركة المرور بشكل نشط. بدلاً من إرسال الطلبات بشكل متكرر إلى نقاط النهاية المثقلة بالأعباء، يمكن للوكيل توجيه أعباء العمل نحو مثيلات أكثر صحة، مما يساعد في الحفاظ على الإنتاجية مع تقليل حالات الفشل المتتالية عبر الأنظمة الموزعة. يعد هذا التحسين ذا قيمة خاصة بالنسبة لبنيات الخدمات الصغيرة التي تعتمد بشكل كبير على واجهات برمجة التطبيقات التابعة لجهات خارجية أو الخدمات التي تفرض حدود المعدل الديناميكي.
يظل الأداء هو الموضوع الرئيسي للإصدار. قام مشرفو Linkerd بتحسين وحدة التحكم الوجهة بشكل كبير، مما أدى إلى تقليل أثر الذاكرة خلال فترات نشاط جدولة Kubernetes السريع. وفقًا للمشروع، تسمح تحسينات استخدام الذاكرة للمشغلين بتخصيص المزيد من موارد المجموعة لأحمال عمل التطبيقات بدلاً من مكونات البنية التحتية.
لقد ميز المشروع نفسه منذ فترة طويلة من خلال هندسته المعمارية خفيفة الوزن، وهذه التحسينات تعزز هذه الفلسفة. تم تصميم Linkerd في Rust بواسطة Buoyant وتم تصميمه بأقل قدر من النفقات التشغيلية، ويواصل وضع نفسه كشبكة خدمة توفر TLS المتبادلة وإدارة حركة المرور وإمكانية المراقبة دون الحاجة إلى استثمار مكثف في الموارد المرتبط تقليديًا بعمليات نشر شبكات الخدمة الكبيرة.
يقدم الإصدار 2.20 أيضًا تحسينات على مقاييس الطلبات الواردة، مما يمنح فرق النظام الأساسي رؤية أكثر دقة حول كيفية تلقي الخدمات ومعالجة حركة المرور. يساعد القياس عن بعد الأفضل المشغلين على تحديد اختناقات حركة المرور، واستكشاف مشكلات زمن الوصول وإصلاحها، وفهم سلوك الخدمة أثناء الحوادث.
تواصل التحسينات استثمار Linkerd الأوسع في إمكانية المراقبة، وتكمل عمليات التكامل السابقة مع OpenTelemetry وتعزز الاتجاه المتزايد نحو القياس عن بعد الموحد عبر الأنظمة الأساسية السحابية الأصلية. نظرًا لأن بيئات Kubernetes أصبحت ديناميكية بشكل متزايد، أصبحت الرؤى التشغيلية الأكثر ثراءً لا تقل أهمية عن قدرات إدارة حركة المرور نفسها.
بدلاً من إدخال تغييرات معمارية شاملة، يعتمد Linkerd 2.20 على فلسفة التصميم المتسقة التي وجهت المشروع منذ بدايته: توفير إمكانات شبكة الخدمة الأساسية مع تقليل التعقيد التشغيلي.
يصل الإصدار مع استمرار تطور مشهد شبكة الخدمة. في حين توسعت منصات مثل Istio لتشمل أنظمة بيئية شاملة لإدارة حركة المرور مع إمكانات واسعة النطاق في مجال السياسة والأمن والشبكات، فقد اتبعت Linkerd باستمرار استراتيجية مختلفة تركز على البساطة والكفاءة التشغيلية وسهولة التبني.
وفي الوقت نفسه، تستمر أساليب الشبكات الأحدث مثل Kubernetes Gateway API والتقنيات المستندة إلى eBPF في إعادة تشكيل كيفية تفكير المؤسسات في الشبكات من خدمة إلى خدمة، مما يدفع شبكات الخدمة إلى التركيز على القيمة التشغيلية على مدى اتساع الميزات.
يعكس Linkerd 2.20 تحولًا أوسع في الشبكات السحابية الأصلية. ركز ابتكار شبكة الخدمة المبكرة على تقديم إمكانات مثل توجيه حركة المرور، وإعادة المحاولة، وقطع الدائرة، وTLS المتبادل. واليوم، أصبحت العديد من هذه الميزات مكونات متوقعة لمنصات Kubernetes الحديثة.
