ثمة تقنية تعمل بصمت داخل نواة Linux لدى Google وMeta وNetflix وCloudflare. لم تُصمَّم لتكون موضة عابرة، بل صُمِّمت لتكون سريعة وآمنة وغير مرئية. اسمها eBPF — اختصار لـ extended Berkeley Packet Filter — وهي تُعيد كتابة قواعد شبكات السحابة والمراقبة والأمن السيبراني بشكل صامت.
إذا كنت تدير كتلات Kubernetes في عام 2026 ولم تسمع بعد عن eBPF، فأنت على وشك أن تفهم لماذا ستتضمنها ترقيتك التالية للبنية التحتية.
من مُرشِّح الحزم إلى قوة خارقة في النواة
ظهر Berkeley Packet Filter الأصلي (BPF) عام 1992. كان هدفه محدوداً: السماح للبرامج بتصفية حزم الشبكة داخل النواة دون نسخها إلى فضاء المستخدم. كان فعّالاً، لكن نطاقه ضيق.
جاء الإصدار “الموسَّع” — eBPF — في Linux 3.18 عام 2014، وهو في تطور مستمر منذ ذلك الحين. كانت القفزة المفاهيمية هائلة: يتيح eBPF للمطورين تشغيل برامج مخصصة ومعزولة مباشرةً داخل نواة Linux، مرتبطة بأي حدث تقريباً في النواة — حزم الشبكة، ونداءات النظام، ونقاط دخول الوظائف وخروجها، وعدادات الأجهزة.
هذا أمر بالغ الأهمية لأن تجاوز الحد الفاصل بين فضاء المستخدم وفضاء النواة مكلف. كل نداء نظام، وكل تبديل سياق يستنزف دورات المعالج. يُزيل eBPF هذا الحاجز لفئة محددة بعناية من العمليات. تحصل على أداء على مستوى النواة دون الحاجة إلى كتابة وحدة نواة — ودون خطر تعطل النظام.
كيف يعمل eBPF: الشيفرة الثانوية، والمُحقِّق، وJIT
عندما يكتب مطور برنامج eBPF (عادةً بمجموعة فرعية مقيدة من C)، يُترجَم إلى شيفرة ثانوية BPF — تمثيل وسيط قابل للنقل. قبل السماح لهذه الشيفرة بالاقتراب من النواة، تمر عبر مُحقِّق eBPF.
المُحقِّق هو ضمان الأمان. يُحلل بصورة ساكنة كل مسار تنفيذ محتمل للبرنامج. يتحقق من أن البرنامج ينتهي (لا حلقات لانهائية)، وأنه لا يصل أبداً إلى ذاكرة خارج الحدود، وأنه لا يزيل الإشارة من مؤشرات فارغة، وأنه يبقى ضمن حدود التعقيد المحددة. فقط البرنامج الذي يجتاز جميع الفحوصات يُحمَّل في النواة.
بعد التحقق، يُترجم مُترجِم Just-In-Time (JIT) الشيفرة الثانوية BPF إلى تعليمات آلة أصلية لمعالج المضيف. تُنفَّذ النتيجة بسرعة شبه أصلية، كما لو كانت جزءاً من النواة ذاتها.
تتواصل البرامج مع فضاء المستخدم عبر eBPF maps — هياكل بيانات مفتاح-قيمة تعيش في ذاكرة النواة لكنها متاحة من فضاء النواة وفضاء المستخدم على حد سواء. هكذا تُستخلَص المقاييس، وتُمرَّر الإعدادات، وتُبثُّ الأحداث.
تتراوح نقاط الربط — المسماة hooks — بين واجهات الشبكة (XDP وTC) ونداءات النظام دخولاً وخروجاً، وتحقيقات وظائف النواة (kprobes وtracepoints)، وتحقيقات وظائف فضاء المستخدم (uprobes). هذا التنوع في hooks هو ما يجعل eBPF متعدد الاستخدامات.
حالة الاستخدام الأولى: الشبكات — Cilium يحل محل kube-proxy
احتاجت Kubernetes دائماً إلى طبقة شبكة. لسنوات، كانت هذه الطبقة مبنية على iptables، يديرها kube-proxy. صُمِّمت iptables لحقبة أبسط. في الكتلات التي تضم مئات الخدمات، تنتفخ جداول قواعد iptables إلى عشرات الآلاف من الإدخالات. كل اتصال جديد يُطلق مسحاً تسلسلياً. يتدهور الأداء خطياً مع حجم الكتلة.
يحل Cilium، مشروع CNCF المتخرج والمدعوم من Isovalent (التي استحوذت عليها Cisco عام 2023)، محل kube-proxy كلياً باستخدام eBPF. بدلاً من قواعد iptables، يُبرمج Cilium قرارات التوجيه على مستوى النواة مباشرةً عند مستوى حزم الشبكة. يحدث تتبع الاتصالات وموازنة الحمل وتطبيق السياسات في النواة قبل أن تصل الحزم إلى فضاء المستخدم.
النتائج من حيث الأداء مذهلة. تُظهر المقاييس المرجعية من Isovalent أن Cilium يتعامل مع توجيه طلبات HTTP بزمن استجابة أقل بنسبة 30-40% وإنتاجية أعلى بكثير مقارنةً بالإعدادات القائمة على iptables، خاصةً مع نمو حجم الكتلة. GKE Dataplane V2 من Google، الذي يُشغِّل ملايين عُقَد Kubernetes، مبني على Cilium.
يُتيح Cilium، إلى جانب الأداء، سياسات شبكة قائمة على الهوية. بدلاً من تصفية حركة المرور بعنوان IP — الذي يتغير باستمرار في بيئات السحابة الديناميكية — يُخصِّص Cilium هويات تشفيرية للأحمال العملية ويُطبِّق السياسات بناءً على تلك الهويات. هذا نموذج أكثر موثوقية جوهرياً لأمن السحابة الأصيلة.
حالة الاستخدام الثانية: المراقبة — Hubble وPixie وParca
المجال الكبير الثاني الذي تُحوِّله eBPF هو المراقبة. تتطلب مراقبة أداء التطبيقات التقليدية أدوات قياس: يجب على المطورين إضافة مكتبات تتبع وحزم SDK للمقاييس وعملاء تسجيل إلى كل خدمة. هذا يُنشئ عبئاً إضافياً، وصداعاً في التحكم بالإصدارات، وفجوات حيثما تغيب أدوات القياس.
يُغيِّر eBPF النموذج. لأن hooks الخاصة بـ eBPF تقع على مستوى النواة، فهي قادرة على مراقبة كل اتصال شبكي، وكل نداء نظام، وكل استدعاء وظيفة — دون أي تعديل على كود التطبيق. يُسمى هذا بالمراقبة بلا أدوات قياس.
يوفر Hubble، طبقة المراقبة المبنية فوق Cilium، رؤية فورية لتدفقات الشبكة عبر كتلة Kubernetes. يُظهر أي الخدمات تتحدث مع أيٍّ منها، وما هي استعلامات DNS التي تُجرى، وأين تفشل الاتصالات — كل ذلك يُستخلَص من بيانات eBPF دون أن يمس أي تطبيق.
يذهب Pixie، الذي طوَّرته New Relic وأصبح الآن مشروعاً في رمل CNCF، أبعد من ذلك. يستخدم eBPF لالتقاط حركة مرور HTTP/2 وgRPC وPostgreSQL وRedis وKafka تلقائياً — مما يمنح المهندسين تتبعات على مستوى التطبيق دون أي تغييرات في الكود. بالنسبة للفرق التي تدير عشرات الخدمات المصغرة، هذا أمر تحويلي.
يُضيف Parca التوصيف المستمر إلى نفس النموذج. باستخدام أخذ العينات القائم على eBPF، يُوصِّف استخدام المعالج على مستوى الوظيفة عبر كل عملية على مضيف، دون الحاجة إلى أي عميل توصيف على مستوى التطبيق. النتيجة: رسوم بيانية للهب على مستوى الأسطول تكشف بالضبط أين تُنفَق دورات المعالج في بيئة الإنتاج.
إعلان
حالة الاستخدام الثالثة: الأمن — Falco وTetragon
اعتمد رصد الأمان تاريخياً على سجلات التدقيق أو وحدات النواة أو حاويات sidecar — لكل نهج تكاليف في الأداء أو هشاشة. توفر eBPF أساساً أفضل.
يستخدم Falco، مشروع الأمان التابع لـ CNCF والذي طوَّرته Sysdig في الأصل، eBPF لمراقبة نداءات النظام في الوقت الفعلي. عندما تحاول حاوية الكتابة إلى مسار حساس، أو إنتاج shell غير متوقعة، أو فتح socket شبكي نحو وجهة غير معروفة، يُطلق Falco تنبيهاً — فورياً، مع السياق الكامل للعملية.
يتجاوز Tetragon، مكوِّن تطبيق الأمان الذي طوَّرته Isovalent إلى جانب Cilium، مجرد الكشف. يمكن لـ Tetragon تطبيق سياسات الأمان مباشرةً في النواة باستخدام eBPF. يمكنه حظر نداء نظام قبل تنفيذه، وإيقاف عملية تنتهك سياسة، أو تقييد الوصول إلى الشبكة — كل ذلك دون أي sidecar يُضيف زمن استجابة أو رحلة ذهاباً وإياباً إلى فضاء المستخدم. هذا هو تطبيق أمان وقت التشغيل بسرعة النواة.
لا يمكن المبالغة في أهمية هذا لأحمال العمل السحابية. غالباً ما تنجح هجمات اختراق الحاويات والارتقاء بالامتيازات وتسريب البيانات لأن أنظمة الكشف ترى النشاط فقط بعد أن يكون قد حدث بالفعل في فضاء المستخدم. يمكن لأدوات الأمان القائمة على eBPF الاعتراض والحظر عند نقطة التنفيذ.
من يستخدم eBPF على نطاق واسع
تبدو قائمة المعتمِدين كسجل لنجوم البنية التحتية. تعمل Meta (Facebook) بموازنات حمل وتخفيف DDoS قائمة على eBPF في بيئة الإنتاج منذ عام 2017. تستخدم Cloudflare hook الخاص بـ XDP (eXpress Data Path) في eBPF لإسقاط حركة المرور الخبيثة بسرعة الكابل — قبل أن تدخل حتى إلى مكدس الشبكة في النواة — مع التعامل مع تيرابايت من حركة المرور في الثانية.
تستخدم Netflix eBPF للتوصيف في بيئة الإنتاج وتحليل الأداء عبر أسطولها الهائل من خوادم البث. تُشغِّل Google مشروع Cilium كأساس لـ GKE Dataplane V2. تستخدم Microsoft eBPF في مكدس شبكة Azure. أضفت Linux Foundation الطابع الرسمي على المجتمع عام 2021 بإنشاء eBPF Foundation، بمشاركة Meta وGoogle وMicrosoft وNetflix وIsovalent وآخرين كأعضاء مؤسسين.
القيود ومتطلبات إصدار النواة
لا تخلو eBPF من قيود. الحاجز العملي الأكثر أهمية هو إصدار النواة. تتطلب العديد من ميزات eBPF نواة Linux 5.x أو أحدث؛ وتتطلب بعض القدرات المتقدمة (مثل BTF — BPF Type Format — التي تُتيح برامج eBPF قابلة للنقل) الإصدار 5.2 أو أعلى، وتتطلب بعض ميزات Cilium الإصدار 5.10 أو أحدث. قد تجد المؤسسات التي تُشغِّل توزيعات Linux قديمة نفسها محاصرة أو مقيدة.
يُفرض مُحقِّق eBPF، وإن كان ضرورياً للأمان، حدوداً للتعقيد أيضاً. ستُرفض البرامج الكبيرة جداً أو المعقدة جداً. تتطلب كتابة كود eBPF صحيح وصديق للمُحقِّق إلماماً عميقاً بآليات نواة Linux الداخلية — مهارة لا تزال نادرة.
الأمان يُثير قلقاً في البيئات متعددة المستأجرين. على الرغم من التحقق من برامج eBPF قبل التحميل، فإن فعل تحميل برنامج يتطلب امتيازات مرتفعة. في كتلات Kubernetes المشتركة، يكون السماح للأحمال العملية بتحميل برامج eBPF عشوائية خطراً. تقيِّد نماذج النشر عادةً تحميل برامج eBPF إلى daemonsets ذات امتيازات يديرها مديرو الكتلة.
أخيراً، تصحيح أخطاء برامج eBPF أصعب بكثير من تصحيح أخطاء التطبيقات التقليدية. تساعد أدوات مثل bpftool وbpftrace وحزمة BCC، لكن منحنى التعلم حاد.
الطريق إلى الأمام
يشهد نظام eBPF البيئي في 2026 نضجاً متسارعاً. تواصل مجتمع تطوير النواة توسيع مجموعة hooks المتاحة، وزيادة حدود تعقيد البرامج، وتحسين قابلية النقل عبر CO-RE (Compile Once, Run Everywhere) — آلية تتيح لثنائي eBPF مُترجَم واحد العمل عبر إصدارات نواة مختلفة دون إعادة ترجمة.
تُعاد هيكلة بنى شبكات الخدمات حول eBPF. تشير كل من Ambient Mesh في Istio، وتجارب Linkerd على dataplane القائمة على eBPF، وعرض Cilium لخدمة mesh إلى مستقبل تقع فيه طبقة التحكم في الشبكة كلياً داخل النواة، لا في حاويات sidecar.
بالنسبة لمهندسي السحابة، المسار واضح: eBPF ليست فضولاً بحثياً متخصصاً. إنها الأساس الذي تُبنى عليه الجيل التالي من أدوات شبكات السحابة والمراقبة والأمن. أصبح فهمها — حتى على المستوى المفاهيمي — متطلباً أساسياً للعمل الجاد في البنية التحتية.
الأسئلة الشائعة
ما المقصود بـ eBPF؟
يتناول هذا المقال الجوانب الأساسية لهذا الموضوع، ويستعرض الاتجاهات الحالية والجهات الفاعلة الرئيسية والتداعيات العملية على المهنيين والمؤسسات في عام 2026.
لماذا يُعد هذا الموضوع مهمًا؟
يكتسب هذا الموضوع أهمية كبيرة لأنه يؤثر بشكل مباشر على كيفية تخطيط المؤسسات لاستراتيجيتها التقنية وتخصيص مواردها وتموضعها في مشهد سريع التطور.
ما أبرز النقاط المستخلصة من هذا المقال؟
يحلل المقال الآليات الرئيسية والأطر المرجعية والأمثلة الواقعية التي تشرح كيفية عمل هذا المجال، مستندًا إلى بيانات حديثة ودراسات حالة عملية.
