Kubernetes Native Sidecar Containers: دليل

حاوية الـ sidecar الأصلية (native sidecar container) هي إدخال في قائمة initContainers الخاصة بالـ Pod مع restartPolicy: Always. أصبحت مستقرة منذ Kubernetes v1.33، وهي تبدأ قبل التطبيق الأساسي، وتستمر في العمل طوال عمر الـ Pod، ولا تتوقف إلا بعد خروج حاوية التطبيق.¹²

ملخص

لسنوات، كانت الـ "sidecar" مجرد حاوية إضافية في spec.containers — وهو نمط به خطآن مزعجان: لا يوجد ما يضمن بدء تشغيلها قبل تطبيقك، وفي الـ Job لم تكن تتوقف أبدًا، مما يجعل الـ Job يظل معلقًا للأبد. تعالج حاويات الـ sidecar الأصلية في Kubernetes كلتا المشكلتين. أنت تعلن عن الـ sidecar في initContainers مع restartPolicy: Always؛ ثم يقوم Kubernetes بتشغيلها قبل التطبيق، ويسمح لبقية الـ Pod بالاستمرار بينما تظل هي تعمل، وينهيها بعد التطبيق عند الإغلاق، و — الأهم من ذلك — يسمح للـ Jobs بالاكتمال. أصبحت الميزة مستقرة في الإصدار v1.33 (أبريل 2025)، لذا فهي متاحة بشكل عام في كل إصدار مدعوم اعتبارًا من منتصف عام 2026.¹²³

ما ستتعلمه

• ما هي حاوية الـ sidecar الأصلية والمواصفة المكونة من سطر واحد التي تنشئها
• كيف تختلف الـ sidecar الأصلية عن حاوية init العادية
• كيف تختلف الـ sidecar الأصلية عن حاوية الـ sidecar العادية (بالنمط القديم) في spec.containers
• أي إصدار من Kubernetes جعل حاويات الـ sidecar الأصلية مستقرة
• كيفية تعريف واحدة في YAML، ولماذا Always هي الـ restartPolicy القانونية الوحيدة
• قواعد ترتيب بدء التشغيل والإنهاء
• لماذا تجعل حاويات الـ sidecar الأصلية أخيرًا الـ sidecars تعمل مع الـ Jobs
• هل تدعم حاويات الـ sidecar الأصلية الـ probes وحدود الموارد (resource limits)

ما هي حاوية الـ sidecar الأصلية في Kubernetes؟

حاوية الـ sidecar الأصلية هي حاوية ثانوية تعمل جنبًا إلى جنب مع حاوية تطبيقك الأساسية في نفس الـ Pod، حيث توفر وظائف دعم مثل تسجيل السجلات (logging)، أو المقاييس (metrics)، أو وكيل (proxy)، أو مزامنة الإعدادات (config sync) دون لمس كود التطبيق.¹ ما يجعلها "أصلية" (native) هو التنفيذ: يعاملها Kubernetes كحالة خاصة من حاوية init — وتحديدًا، إدخال في spec.initContainers يضبط restartPolicy: Always.¹

هذا الحقل الواحد يغير دورة حياة الحاوية. حاوية init العادية تعمل مرة واحدة وتخرج قبل أن تبدأ الحاوية التالية. أما الـ sidecar الأصلية فتبدأ في مرحلة الـ init، ويُسمح لها بالاستمرار في العمل، وتظل حية طوال عمر الـ Pod — وهو السلوك الذي تريده فعليًا من وكيل تسجيل السجلات أو وكيل الـ service-mesh.¹

كيف تختلف الـ sidecar الأصلية عن حاوية init؟

يجب أن تعمل حاوية init العادية حتى تكتمل قبل أن تبدأ الحاوية التالية وتختفي قبل أن يعمل تطبيقك؛ أما الـ sidecar الأصلية فيكفي فقط أن تبدأ قبل أن ينتقل Kubernetes للمرحلة التالية، ثم تستمر في العمل طوال الوقت.¹⁴ كلاهما يتواجد في نفس قائمة initContainers، لكن علامة restartPolicy: Always تحول إحداهما إلى رفيق طويل الأمد.

هناك اختلافان عمليان آخران. أولاً، تدعم حاويات الـ sidecar الأصلية startupProbe، و readinessProbe، و livenessProbe؛ بينما لا تقبل حاويات init العادية حقول دورة الحياة والـ probe هذه على الإطلاق.¹ ثانياً، تعيد الـ sidecar الأصلية تشغيل نفسها إذا تعطلت، حتى في الـ Pod الذي تكون فيه الـ restartPolicy على مستوى الـ Pod هي Never أو OnFailure — حيث تتبع الـ sidecars المدمجة سياسة initContainers[].restartPolicy: Always بدلاً من سياسة مستوى الـ Pod.¹

كيف تختلف الـ sidecar الأصلية عن حاوية الـ sidecar العادية (بالنمط القديم)؟

الـ sidecar العادية هي مجرد حاوية أخرى في spec.containers، بدون ضمانات للترتيب أو الاكتمال؛ أما الـ sidecar الأصلية فتوجد في spec.initContainers مع restartPolicy: Always، مما يضمن بدء تشغيلها قبل التطبيق وعدم منع اكتمال الـ Pod أبدًا.¹ كان النمط القديم يعمل، لكن كان له عيبان مشهوران.

الأول هو سباقات بدء التشغيل (startup races): الحاويات العادية في spec.containers تبدأ بدون أي ترتيب للجاهزية (readiness)، لذا حتى الـ sidecar المدرجة قبل تطبيقك لا تضمن أن تكون جاهزة عند بدء التطبيق — وقد يفشل التطبيق في استدعاء قاعدة بيانات أو يبدأ في تقديم الخدمة قبل أن يعمل الـ proxy أو الـ auth sidecar. الثاني هو اكتمال الـ Job، وهو ما سنغطيه في قسم خاص أدناه. تحل حاويات الـ sidecar الأصلية كلتا المشكلتين بالاعتماد على آلية حاوية الـ init، وهو سبب أساسي وراء قيام مشروع Kubernetes ببناء هذه الميزة بدلاً من ترك الـ sidecars كمجرد عرف متبع.¹⁵

أي إصدار من Kubernetes أضاف حاويات الـ sidecar الأصلية؟

وصلت حاويات الـ sidecar الأصلية (KEP-753، بوابة ميزة SidecarContainers) كنسخة تجريبية أولية (alpha) في v1.28، وأصبحت نسخة تجريبية متقدمة (beta) ومفعلة افتراضيًا في v1.29، ووصلت إلى الاستقرار في v1.33، الذي تم إصداره في 23 أبريل 2025.²⁶ ولأنها مستقرة، فإن الميزة مفعلة افتراضيًا ولا تحتاج إلى علامة بوابة ميزة (feature-gate flag).

من الناحية العملية، يعني هذا أن كل إصدار مدعوم حاليًا من Kubernetes يوفر حاويات الـ sidecar الأصلية كميزة متاحة بشكل عام: الفروع المدعومة اعتبارًا من منتصف عام 2026 هي 1.34 و 1.35 و 1.36.³ إذا كنت تستخدم v1.33 أو أحدث، يمكنك استخدام الـ sidecars الأصلية اليوم؛ إذا كنت تستخدم الإصدارات من v1.29 إلى v1.32، فالميزة موجودة (beta، مفعلة افتراضيًا) ولكنك تقوم بتشغيل إصدار خارج الدعم ويجب عليك الترقية.

كيف يمكنك تعريف حاوية sidecar أصلية (native)؟

تقوم بإضافة الـ sidecar إلى initContainers وتعيين restartPolicy: Always عليها. هذه هي الحيلة بالكامل — تظل حاوية التطبيق في spec.containers كالمعتاد:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      initContainers:
        - name: log-shipper
          image: log-shipper:1.0
          restartPolicy: Always      # this line makes it a native sidecar
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
          startupProbe:
            httpGet:
              path: /healthz
              port: 9000
      containers:
        - name: app
          image: my-app:2.3
          ports:
            - containerPort: 8080

قاعدة واحدة يجب تذكرها: بالنسبة لـ init container، فإن Always هي القيمة المقبولة الوحيدة لـ restartPolicy. تعيينها على OnFailure أو Never سيتم رفضه، ويفشل إنشاء الـ Pod:¹

initContainers:
  - name: log-shipper
    image: log-shipper:1.0
    restartPolicy: OnFailure     # rejected — Pod creation fails validation

لذلك لا يوجد غموض — إما أن تحذف restartPolicy (حاوية init عادية تعمل لمرة واحدة) أو تضبطها على Always (حاوية sidecar أصلية).

كيف تبدأ وتتوقف حاويات الـ sidecar الأصلية؟

تبدأ حاويات الـ sidecar الأصلية قبل تطبيقك، بالترتيب الذي تظهر به في initContainers، وتتوقف بعد تطبيقك، بالترتيب العكسي.¹⁷ عند بدء التشغيل، ينتقل Kubernetes إلى حاوية الـ init التالية أو إلى الحاويات الرئيسية بمجرد بدء تشغيل الـ sidecar — وإذا كانت الـ sidecar تحدد startupProbe، فبمجرد نجاح هذا الفحص.¹ لذا فإن إضافة startupProbe هو ما يمنحك ضمان "البروكسي جاهز قبل أن يرسل التطبيق طلبه الأول"؛ بدون ذلك، ينتظر التطبيق فقط بدء عملية الـ sidecar، وليس جاهزيتها.

عند الإغلاق، يتأخر kubelet في إيقاف الـ sidecars حتى تتوقف حاوية التطبيق الرئيسية تمامًا، ثم ينهي الـ sidecars بالترتيب العكسي لظهورها في المواصفات.¹⁷ تتلقى كل sidecar إشارة SIGTERM ولديها مهلة حتى terminationGracePeriodSeconds للخروج بشكل نظيف؛ إذا لم تفعل، فإنها تتلقى SIGKILL (كود الخروج 137).⁷ هذا الترتيب يعني أن sidecar تسجيل البيانات (logging) لا تزال حية لإرسال آخر سطور سجلات التطبيق، وأن البروكسي الخاص بك لا يزال يعمل لتصريف آخر الاتصالات الجارية للتطبيق.

لماذا تجعل حاويات الـ sidecar الأصلية الـ sidecars تعمل أخيرًا مع الـ Jobs؟

لأن حاويات الـ sidecar الأصلية لا تمنع اكتمال الـ Pod: بمجرد انتهاء جميع الحاويات العادية في Pod الخاص بـ Job، يرسل Kubernetes للـ sidecars إشارة SIGTERM وتكتمل الـ Job بشكل طبيعي.⁵ هذا أحد الأسباب الرئيسية لوجود هذه الميزة. مع الـ sidecar ذات النمط القديم في spec.containers، كانت الـ Job التي تحتوي على sidecar لتسجيل البيانات أو بروكسي تقوم بتشغيل المهمة الرئيسية بنجاح، لكن الـ sidecar التي تعمل باستمرار كانت تبقي الـ Pod حيًا، لذا كانت الـ Job تظل في حالة "1 running" للأبد، واضطرت الفرق إلى اللجوء لحلول غير مستقرة — مثل أعلام الخروج في emptyDir المشترك، أو استدعاء kubectl لقتل الـ sidecar، أو أدوات إنهاء خارجية.

حاويات الـ sidecar الأصلية تلغي كل ذلك. في الـ Job، حيث تكون restartPolicy هي OnFailure أو Never، يتم التعامل مع الـ sidecar كبنية تحتية داعمة: استمرار تشغيلها لم يعد يُحسب ضمن شروط الاكتمال.⁵ يبدو المانيفست مثل أي Job أخرى — الـ sidecar تعيش ببساطة في initContainers:

apiVersion: batch/v1
kind: Job
metadata:
  name: nightly-export
spec:
  template:
    spec:
      restartPolicy: Never
      initContainers:
        - name: db-proxy
          image: db-proxy:1.0
          restartPolicy: Always    # native sidecar — won't block completion
      containers:
        - name: export
          image: export-job:1.0     # when this finishes, the Job completes

تحصل على راحة الـ sidecar (تسجيل بيانات مركزي، بروكسي لقاعدة البيانات، وكيل للأسرار) مع دلالات إنهاء نظيفة تحتاجها أعباء العمل المجمعة (batch workloads).

هل يمكن لحاويات الـ sidecar الأصلية استخدام الفحوصات (probes) وحدود الموارد؟

نعم — تدعم حاويات الـ sidecar الأصلية startupProbe، و readinessProbe، و livenessProbe، وهي تأخذ طلبات وحدود resources تمامًا مثل أي حاوية عادية.¹ هذه ترقية حقيقية مقارنة بحاويات الـ init العادية، التي لا تقبل حقول الفحص أو دورة الحياة. استخدم startupProbe عندما تحتاج إلى انتظار التطبيق حتى تصبح الـ sidecar جاهزة حقًا (وليس مجرد بدأت)، و livenessProbe لإعادة تشغيل الـ sidecar إذا تعطلت من تلقاء نفسها.

تحصل حاويات الـ sidecar الأصلية أيضًا على تعديل في درجة الخروج بسبب نقص الذاكرة (OOM) بما يتماشى مع الحاويات الأساسية، لذا فمن غير المرجح أن يقوم kubelet بطرد الـ sidecar أولاً تحت ضغط الذاكرة.¹ كما هو الحال مع أي حاوية، قم بتعيين resources.requests حتى يأخذ المجدول (scheduler) الـ sidecar في الاعتبار، و resources.limits حتى لا يتمكن وكيل جامح من تجويع تطبيقك.

الخلاصة

إذا كنت تستخدم Kubernetes إصدار v1.33 أو أحدث، فإن الـ sidecars الأصلية هي الخيار الافتراضي الصحيح لأي حاوية مساعدة: قم بالإعلان عنها في initContainers مع restartPolicy: Always وستحصل على ترتيب تشغيل مضمون قبل التطبيق، وإيقاف تشغيل نظيف بترتيب عكسي، و Jobs تكتمل بالفعل. نمط الـ sidecar القديم في spec.containers أصبح الآن من الماضي — قم بترحيله. للحصول على نظرة أوسع على نموذج Pod وأحمال العمل، راجع دليل نيرد ليفل تك العملي لـ Kubernetes لعام 2026؛ وللحفاظ على نظافة عمليات النشر أثناء تفريغ الـ sidecars، ادمجها مع عمليات نشر Kubernetes بدون وقت توقف؛ وعندما تكون الـ sidecar الخاصة بك وكيلًا للمراقبة (observability agent)، قم بتوصيلها بـ مسار تتبع OpenTelemetry Collector.