مراقبة eBPF بلا أدوات: KubeCon EU 2026 يُحدد نقطة التحول المؤسسية

ما الذي جرى في KubeCon EU 2026 ليجعله نقطة التحول

انعقد KubeCon + CloudNativeCon Europe 2026 في أمستردام في أبريل 2026، مستقطباً أكثر من 13,000 مهندس. جاء الإعلان الرئيسي للمراقبة من Splunk: الإطلاق التجريبي لـ OpenTelemetry eBPF Instrumentation (OBI)، وهو حل مراقبة بلا كود يلتقط القياس عن بُعد مباشرةً من نواة Linux — دون تغييرات في الكود، دون إعادة تشغيل الخدمات، دون وكلاء sidecar.

الفرضية التقنية لـ OBI بسيطة لكن تداعياتها بعيدة الأثر. التتبع الموزع التقليدي يستلزم من المطورين تجهيز كود تطبيقاتهم بـ SDKs من OpenTelemetry — يعمل هذا جيداً للخدمات الحديثة لكنه يفشل مع قواعد الكود القديمة، والملفات الثنائية في Go، وخدمات Rust، وتطبيقات C++. تُغيّر eBPF النموذج جذرياً: بتشغيل برامج في آلة Linux الافتراضية للنواة، تعترض OBI مكالمات النظام وحركة الشبكة على مستوى النواة، وتُعيد بناء التتبعات الموزعة ومقاييس RED (Rate, Errors, Duration) دون لمس كود التطبيق.

إعلان Splunk يُموضع OBI كمكمّل لـ SDKs OpenTelemetry القائمة — يسدّ ثغرات الرؤية في الخدمات غير المجهّزة دون تكرار البيانات من الخدمات المجهّزة فعلاً. الأثر العملي هو تغطية مراقبة كاملة عبر كلستر Kubernetes بصرف النظر عن عمر أحمال العمل أو لغتها أو حالة تجهيزها.

ما تُضيفه نسخة Cilium 1.19 mTLS

الإعلان الثاني الكبير لـ eBPF في KubeCon EU 2026 جاء من Cilium، شبكة CNI القائمة على eBPF التي باتت المكوّن الشبكي الافتراضي لـ GKE وEKS وAKS. قدّمت Cilium الإصدار 1.19 دعم TLS المتبادل الأصلي — اتصال مشفر ومصادق متبادلاً بين الخدمات — دون الحاجة إلى حاويات sidecar.

الأهمية معمارية. نهج خدمة mesh في Kubernetes السابقة (Istio مع Envoy sidecars، Linkerd) اعتمدت حقن حاوية وكيل بجانب كل pod تطبيق. هذا يُضيف 50 إلى 200 ميغابايت من النفقات الذاكرة لكل pod، ويُدخل زمن استجابة وكيل 1 إلى 5 ميلي ثانية لكل طلب، ويتطلب من المشغّلين إدارة دورة حياة الوكيل. تستخدم نسخة Cilium 1.19 eBPF مع ztunnel — مكوّن وكيل Rust من Istio — لتوفير mTLS على مستوى النواة، مع القضاء على فقد الحزم أثناء المصافحات TLS وتحسين الإنتاجية. الإعداد يتطلب ثلاث خطوات فقط.

ما يتعين على فرق هندسة المنصات فعله الآن

1. تقييم نشر OBI التجريبي لسدّ ثغرات مراقبة الخدمات القديمة

معظم كلسترات Kubernetes المؤسسية لديها مزيج من الخدمات المجهّزة جيداً والخدمات المظلمة (تطبيقات قديمة، حاويات بائع، قواعد بيانات طرف ثالث) التي تفتقر كلياً إلى تغطية المراقبة. البيتا من OBI هي الفرصة لسدّ هذه الثغرات دون أي تراكم في تغييرات الكود. مسار التقييم مباشر: نشر OBI كـ DaemonSet على كلستر غير إنتاجي، تشغيله جانباً مع جامعي OpenTelemetry القائمين، ومقارنة تغطية التتبع قبل وبعد. دليل مراقبة KubeCon EU 2026 الصادر عن OpenTelemetry يغطي دمج OBI. يكشف التقييم عادةً 15 إلى 40 بالمئة من حركة الكلستر التي كانت غير مرئية سابقاً.

2. ترحيل خدمة mesh القائمة على Sidecar نحو وضع Cilium 1.19 Ambient قبل توسيع حجم كلستر Kubernetes

إذا كانت خدمة mesh الحالية تعتمد على وكلاء sidecar، فإن نسخة Cilium 1.19 ambient mTLS هي هدف الترحيل الذي يُلغي نفقات sidecar على النطاق. قلّصت Meta الحمل على وحدة المعالجة 20٪ على مستوى الأسطول من خلال تغييرات بنية تحتية قائمة على eBPF من هذا النوع. تُعالج Cloudflare 10 ملايين حزمة في الثانية باستخدام eBPF. خفّضت Datadog استخدام وحدة المعالجة 35٪ بالتحول إلى الجمع القائم على eBPF. هذه نتائج إنتاجية، لا أرقام قياسية.

3. التوحيد على OpenTelemetry Collector كخط أنابيب قياس موحّد — OBI وSpans الـ SDK والسجلات في جامع واحد

أكثر أنماط فشل المراقبة المؤسسية شيوعاً هو تشتّت القياس: وكلاء منفصلون للسجلات، وكلاء منفصلون للمقاييس، وكلاء منفصلون للتتبعات. أعلنت Splunk في KubeCon EU 2026 دعماً تجريبياً لاستيعاب السجلات الأصلي عبر بروتوكول OpenTelemetry — أي جامع OpenTelemetry واحد يُجمّع التتبعات (من OBI ومن أدوات SDK) والمقاييس (من Prometheus) والسجلات (من stdout التطبيق وأحداث النواة) في خط أنابيب موحّد. هذه هي البنية الواجب التوحيد عليها قبل وصول OBI إلى مرحلة GA.

إلى أين تتجه eBPF في البيئات المؤسسية

إعلانات KubeCon EU 2026 هي التأكيد العلني لتحول يتراكم منذ ثلاث سنوات. مؤسسة eBPF — المدعومة من Linux Foundation وأعضائها Meta وGoogle وMicrosoft وNetflix وIsovalent — قادت التوحيد الذي يجعل برامج eBPF قابلة للنقل عبر إصدارات نواة Linux وبيئات مزودي السحابة. Cilium الآن هو CNI الافتراضي للخدمات الثلاث الكبرى لإدارة Kubernetes (GKE, EKS, AKS). OBI في مرحلة بيتا مع خارطة طريق نحو GA 1.0.

ما يتغيّر عند GA ليس التقنية بل نموذج الدعم. OBI في بيتا يتطلب مهندسي منصات ذوي معرفة بنواة Linux. عند GA، يغطي عقد دعم Splunk المؤسسي OBI — مما يعني أن مسؤول أمن المعلومات يستطيع الموافقة عليه للإنتاج، ومسؤول الامتثال يستطيع تدقيقه، وفريق المشتريات يستطيع تضمينه في عقد بائع قياسي.

الأسئلة الشائعة

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

• Splunk تُطلق OpenTelemetry eBPF Instrumentation في KubeCon EU 2026 — Cloud Native Now
• KubeCon EU 2026: Kubernetes ينضج مع BSD وeBPF وmTLS — Heise
• ابتكارات مراقبة Splunk في KubeCon EU 2026 — Splunk Blog
• eBPF لمراقبة Kubernetes: مراقبة بلا تجهيز 2026 — Gheware DevOps
• OpenTelemetry في KubeCon + CloudNativeCon Europe 2026 — OpenTelemetry Blog