لثلاث سنوات متتالية، كان النقاش حول شبكات الخدمات (service mesh) شبيهاً بحرب دينية: Istio في مواجهة Linkerd في مواجهة Consul Connect. نماذج Sidecar proxy في مواجهة النماذج القائمة على العملاء. الأداء في مواجهة الثراء الوظيفي. في عام 2026، بات للنقاش فائز — ويعمل في نواة Linux.

Cilium، مشروع الشبكات الأصيل القائم على eBPF الذي تخرّج من مؤسسة Cloud Native Computing Foundation (CNCF) في أكتوبر 2023، أصبح طبقة الشبكات الافتراضية لعمليات نشر Kubernetes الجادة. لم يفز بالتسويق، بل فاز بجعل proxies sidecar تبدو كما هي: إرث مُثقَل بالتكاليف.

نموذج Sidecar: فكرة جيدة تحولت إلى مشكلة

لفهم سبب تقدم Cilium، يجب فهم تكلفة proxies sidecar.

يعتمد نموذج service mesh التقليدي على حقن حاوية proxy — عادةً Envoy — بجانب كل حاوية تطبيق في pod داخل Kubernetes. يعترض هذا الـ proxy كل حركة المرور الواردة والصادرة، ويطبّق mTLS، وينفّذ سياسات الشبكة، ويُصدر بيانات القياس عن بُعد (telemetry). إنه يعمل. لكن كل sidecar هو عملية مستقلة تستهلك الذاكرة وقدرة المعالج، وتضيف زمن استجابة على كل نداء شبكي، وتعقّد تسلسلات بدء تشغيل الـ pods.

على نطاق واسع، تصبح الأرقام مثيرة للقلق. مجموعة (cluster) تُشغّل 500 خدمة تعني أكثر من 500 sidecar من Envoy، كل منها يستهلك ما بين 50 و100 ميغابايت من الذاكرة ويُضيف ما بين 1 و3 ميلي ثانية من زمن الاستجابة لكل قفزة (hop). في تطبيق microservices مع 10 إلى 15 نداءً داخلياً لكل طلب مستخدم، تتراكم ضريبة الزمن بسرعة.

تُظهر بيانات استطلاع CNCF أن 62% من الفرق أشارت إلى “التكلفة الزائدة في الموارد” باعتبارها مصدر الإحباط الرئيسي من شبكات الخدمات. هذا الرقم يفسر سرعة اكتساب البدائل القائمة على eBPF للزخم.

eBPF: نقل شبكة الخدمات إلى النواة

eBPF (extended Berkeley Packet Filter) يتيح تشغيل البرامج بأمان داخل نواة Linux دون تعديل شفرة المصدر أو تحميل وحدات نواة. استُخدم أصلاً لتصفية الحزم الشبكية، وتطور ليصبح طبقة برمجة للأغراض العامة داخل النواة. يستخدم Cilium eBPF لتنفيذ الشبكة وسياسات الأمان والمراقبة على مستوى النواة — متجاوزاً كلياً الحاجة إلى proxies sidecar.

الفارق في الأداء قابل للقياس. تُظهر المعايير المستقلة باستمرار أن Cilium يحقق:

  • انخفاض 40 إلى 60% في زمن الاستجابة مقارنةً بـ Istio مع sidecars من Envoy على أعباء عمل مماثلة
  • انخفاض 50 إلى 70% في التكلفة الزائدة للذاكرة لكل عقدة (node)
  • بدء تشغيل أسرع للـ pods نظراً لغياب حقن sidecar أو تهيئة proxy

ليست هذه تحسينات هامشية. إنها تمثل الفارق بين ضريبة منصة تتحملها الفرق وأخرى تُجبرها على التنازلات المعمارية. يتحقق Cilium هذا لأن برامج eBPF تُنفَّذ في فضاء النواة، متجنبةً التبديل بين فضاء المستخدم والنواة الذي تتطلبه النهج التقليدية.

صعود Cilium: من CNI إلى منصة متكاملة

بدأ Cilium كإضافة Container Network Interface (CNI) — المكوّن المسؤول عن منح الـ pods عناوين IP والاتصال الأساسي. اعتمده مبكراً كل من Google Kubernetes Engine وAmazon EKS وAzure AKS باعتباره CNI الموصى به افتراضياً، مما منح Cilium انتشاراً هائلاً. ملايين المجموعات حول العالم كانت تُشغّل Cilium بالفعل قبل أن تُدرك معظم المؤسسات أن لديها service mesh مدمجاً.

وسّع المشروع نطاقه بشكل مستمر، مضيفاً تطبيق سياسات الشبكة Layer 7 (تصفية بروتوكولات HTTP وgRPC وKafka)، وmTLS بدون sidecars، وتصفية الخروج القائمة على FQDN للتحكم في حركة المرور الصادرة بحسب اسم النطاق، وHubble — طبقة مراقبة أصيلة توفر رؤية على مستوى التدفقات عبر المجموعة بأكملها.

بحلول أواخر 2025، سجّل Cilium أكثر من 5,000 نشر إنتاجي وأصبح الأساس الشبكي لمنصات بارزة تشمل Adobe وBell Canada وأنظمة داخلية متعددة لدى كبار مزودي السحابة.

إعلان

استجابة Istio: Ambient Mesh

لم يستسلم Istio. إجابة المشروع على Cilium هي ambient mesh — بنية معمارية بلا sidecar بلغت التوفر العام في 2025.

يستبدل ambient mesh الـ sidecars لكل pod بمكوّنين مشتركين:

  1. ztunnel — عميل لكل عقدة يتولى mTLS للطبقة الرابعة (Layer 4/TCP) والتوجيه البسيط، مشترك بين جميع الـ pods في العقدة
  2. waypoint proxies — نُسَخ Envoy اختيارية لكل namespace أو خدمة، تُنشر فقط عند الحاجة لمزايا Layer 7

يتيح هذا النموذج الهجين للفرق اختيار توازنها الخاص. ztunnel البحت يوفر اتصال zero-trust أساسياً بأقل تكلفة. يمكن إضافة waypoint proxies للـ namespaces التي تحتاج إلى traffic shifting وإعادة المحاولات وتعديل الترويسات وإضافات WASM.

تُظهر معايير Istio الخاصة أن ambient mesh يستهلك 70% ذاكرة أقل من نموذج sidecar. غير أن مكوّن ztunnel لا يزال يعمل في فضاء المستخدم، مما يعني أن Istio ambient ليس بخفة نهج Cilium القائم على النواة بالكامل. لكن للفرق التي استثمرت سنوات في إعدادات Istio وإضافات WASM وتخصيصات Envoy، يمثل ambient mesh ترقية عملية لا استبدالاً للمنصة.

Linkerd: بطل البساطة تحت الضغط

Linkerd، الذي ريادة فئة “service mesh خفيف الوزن”، يمر بمرحلة صعبة. Proxy Rust الخاص به أخف فعلاً من Envoy، وبساطته التشغيلية جعلته شعبياً في المؤسسات الهندسية متوسطة الحجم. لكن Linkerd لا يزال mesh قائماً على sidecars. في مواجهة خطاب Cilium الخالي من الـ sidecars، يصبح الترويج لـ”sidecar أخف وزناً” أصعب دفاعاً.

جدل الحوكمة في 2024 — عندما حاول Buoyant، الداعم التجاري، تغيير ترخيص Linkerd — أوجد حالة من الغموض في المجتمع وأبطأ اعتماد النسخة مفتوحة المصدر. انتقلت عدة مؤسسات كانت تقيّم Linkerd إلى تقييم Cilium أو Istio ambient بدلاً من ذلك.

ما يعنيه هذا لفرق المنصات

للفرق التي تدير مجموعات Kubernetes في 2026، أصبح إطار القرار أوضح بكثير:

المجموعات الجديدة: اعتمد Cilium CNI افتراضياً. فعّل Hubble فوراً للمراقبة. قيّم ما إذا كانت قدرات service mesh الأصيلة في Cilium تُلبي متطلباتك قبل تبني طبقة service mesh منفصلة. تجد معظم الفرق أنها لا تحتاج إلى التعقيد الإضافي.

نشرات Istio الموجودة: قيّم الانتقال إلى ambient mesh. مسار الانتقال من وضع sidecar موثق جيداً، وتوافق Gateway API يعني انتقال معظم السياسات بسلاسة. تشغيل Cilium كـ CNI تحت Istio هو أيضاً نمط قابل للتطبيق.

تعزيز الأمان: سياسات الخروج القائمة على FQDN في Cilium تحل ثغرة قائمة منذ فترة في Kubernetes. التحكم في الـ endpoints الخارجية التي يمكن للـ pods الوصول إليها — بحسب اسم النطاق بدلاً من عنوان IP المتغير — يوفر تحسيناً ملموساً في الوضع الأمني.

المراقبة بدون إضافة أدوات: يلتقط Hubble تلقائياً تدفقات الشبكة عبر المجموعة بأكملها دون الحاجة إلى إضافة أدوات قياس على مستوى التطبيق. الفرق التي تكافح لجعل التتبع الموزع يعمل باتساق في بيئة microservices متعددة اللغات تجد أحياناً أن Hubble يوفر 80% من القيمة بجزء بسيط من التكلفة التشغيلية.

مقالات ذات صلة

إعلان

رادار القرار (المنظور الجزائري)

البُعد التقييم
الأهمية للجزائر متوسطة — مهم للفرق التي تُشغّل Kubernetes لأعباء عمل الذكاء الاصطناعي ومنصات fintech والخدمات الرقمية الحكومية
هل البنية التحتية جاهزة؟ جزئياً — Cilium يعمل على نواة Linux 4.9+؛ خدمات Kubernetes المُدارة على كبرى السحابات تُشحَن به افتراضياً؛ مجموعات on-premise تحتاج للتحقق من إصدار النواة
هل المهارات متوفرة؟ لا — الخبرة في eBPF نادرة عالمياً؛ الفرق الجزائرية ستحتاج إلى تطوير مهاراتها؛ موارد التدريب من CNCF ووثائق Cilium متوفرة باللغة الإنجليزية
الجدول الزمني للعمل 6 إلى 12 شهراً — الفرق التي تستخدم Kubernetes يجب أن تقيّم الانتقال إلى Cilium CNI؛ جميع المشاريع الجديدة يجب أن تعتمد Cilium افتراضياً
أصحاب المصلحة الرئيسيون مهندسو المنصات، قادة DevOps، مدراء مجموعات Kubernetes، مدراء أمن المعلومات ذوو متطلبات شبكات zero-trust
نوع القرار تكتيكي

خلاصة سريعة: يجب على الفرق الجزائرية التي تبني على Kubernetes — سواء لبنية fintech أو منصات الذكاء الاصطناعي أو الخدمات الرقمية الحكومية — اعتماد Cilium كطبقة شبكة افتراضية لعمليات النشر الجديدة. مكاسب الأداء والأمان ملموسة وموثقة ببيانات. مهارات eBPF نادرة عالمياً، لذا فالاستثمار المبكر في التدريب يُنشئ ميزة تنافسية دائمة لفرق المنصات.

المصادر والقراءات الإضافية