على الرغم من أن معماريات الخدمات المصغرة الحديثة تسرع تطوير التطبيقات ونشرها في البيئات السحابية، إلا أن ضمان قابلية مراقبة هذه الهياكل الموزعة يمثل تحديًا كبيرًا. وتعتبر إدارة السجلات أمرًا بالغ الأهمية بشكل خاص لفهم سلوك التطبيق وتشخيص المشكلات وتحديد اختناقات الأداء. غالبًا ما تتضمن الأساليب التقليدية تصدير السجلات مباشرة من حاوية التطبيق الرئيسية، ولكن هذا قد يزيد من مسؤوليات التطبيق ويقلل من المرونة.

في هذا الدليل، سنستكشف نمط حاوية Sidecar القوي، وهو نمط تصميم شائع الاستخدام في بيئات Kubernetes. يقوم نمط Sidecar بتفريغ مسؤولية أساسية من حاوية التطبيق الرئيسية (مثل جمع السجلات) إلى حاوية منفصلة، مما يجعل التطبيقات أنظف وأكثر نمطية وأسهل في الإدارة. وهذا يسمح لنا بتحديث وإدارة آلية جمع السجلات وإعادة توجيهها بشكل مستقل عن التطبيق.

ما هو نمط حاوية Sidecar ولماذا يستخدم في إدارة السجلات؟

يشير نمط Sidecar إلى حاوية مساعدة تعمل جنبًا إلى جنب مع حاوية التطبيق الرئيسية داخل Pod. وبما أن هذه الحاوية المساعدة تعمل في نفس Pod مثل الحاوية الرئيسية، فإنها تشارك نفس موارد الشبكة والتخزين. تسمح هذه الميزة لـ Sidecar بالتقاط مخرجات التطبيق الرئيسي أو التفاعل معها بسهولة.

بالنسبة لإدارة السجلات تحديدًا، توفر حاوية Sidecar المزايا التالية:

• فصل الاهتمامات (Separation of Concerns): تصبح المسؤولية الوحيدة للتطبيق الرئيسي هي تنفيذ منطق الأعمال، بينما يتم تفويض مهمة جمع السجلات وإعادة توجيهها إلى Sidecar.
• المرونة والتحديثات المستقلة: يمكن تحديث أو استبدال وكيل جمع السجلات (Sidecar) بشكل مستقل عن التطبيق الرئيسي. وهذا يسمح بإجراء تغييرات في استراتيجيات السجلات دون الحاجة إلى إعادة تجميع أو إعادة نشر التطبيق نفسه.
• التعميم: يمكنك توحيد عملية جمع السجلات عبر جميع التطبيقات باستخدام نفس صورة Sidecar.
• تكامل إدارة السجلات المركزية: يمكن تكوين Sidecar لإرسال السجلات المجمعة إلى نظام إدارة سجلات مركزي (مثل Elasticsearch، Loki، Splunk، إلخ).

تطبيق عملي: Sidecar لجمع السجلات باستخدام Fluent Bit في Kubernetes

الآن، دعنا ننتقل إلى مثال عملي يوضح كيفية جمع ومعالجة السجلات من تطبيق Nginx بسيط باستخدام حاوية Sidecar تعتمد على Fluent Bit. في هذا المثال، سيكتب Nginx سجلاته إلى وحدة تخزين مشتركة، وستقرأ حاوية Fluent Bit Sidecar هذه السجلات وتوجهها إلى مخرجها القياسي (stdout). في سيناريو حقيقي، سيرسل Fluent Bit السجلات إلى Kafka أو Elasticsearch أو أي وجهة سجلات أخرى.

1. إنشاء وحدة تخزين EmptyDir لمشاركة السجلات

يحتاج التطبيق الرئيسي (Nginx) إلى دليل لكتابة السجلات، وستقرأ حاوية Sidecar هذه السجلات من نفس الدليل. يمكننا استخدام وحدة تخزين emptyDir لهذا الغرض.

2. تعريف تطبيق Nginx وحاوية Fluent Bit Sidecar

يتضمن تعريف Kubernetes Deployment أدناه حاوية تطبيق Nginx الرئيسية وحاوية Fluent Bit Sidecar لجمع السجلات. تم تكوين Fluent Bit لقراءة السجلات التي يكتبها Nginx إلى دليل /var/log/nginx.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-with-log-sidecar
  labels:
    app: nginx-logging
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-logging
  template:
    metadata:
      labels:
        app: nginx-logging
    spec:
      volumes:
        - name: nginx-logs
          emptyDir: {}
        - name: fluentbit-config
          configMap:
            name: fluentbit-log-sidecar-config
      containers:
        - name: nginx-app
          image: nginx:latest
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx # Nginx سيكتب السجلات هنا
          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "while true; do echo \"$(date) Nginx access log entry\" >> /var/log/nginx/access.log; sleep 5; done"]
        - name: fluentbit-sidecar
          image: fluent/fluent-bit:latest
          command: ["fluent-bit", "-c", "/fluent-bit/etc/fluent-bit.conf"]
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx
            - name: fluentbit-config
              mountPath: /fluent-bit/etc/fluent-bit.conf
              subPath: fluent-bit.conf
          resources:
            limits:
              memory: "64Mi"
              cpu: "100m"
            requests:
              memory: "32Mi"
              cpu: "50m"

3. تكوين Fluent Bit (ConfigMap)

نحتاج إلى إنشاء ConfigMap لملف تكوين Fluent Bit، والذي يحدد كيفية قراءة Fluent Bit للسجلات ومعالجتها. سيتم استخدام ConfigMap هذا بواسطة وحدة تخزين fluentbit-config في Deployment أعلاه.

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-log-sidecar-config
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        1
        Log_Level    info
        Daemon       off
        Parsers_File parsers.conf

    [INPUT]
        Name        tail
        Path        /var/log/nginx/access.log # مسار ملف سجل Nginx
        Tag         nginx_access_log
        Read_from_Head true

    [OUTPUT]
        Name   stdout
        Match  *

تكوين Fluent Bit أعلاه:

• يُراقب قسم [INPUT] ملف /var/log/nginx/access.log باستمرار (tail).
• يوجه قسم [OUTPUT] السجلات المقروءة إلى المخرج القياسي لحاوية Fluent Bit. يتيح لك ذلك عرض السجلات باستخدام الأمر kubectl logs <pod-name> -c fluentbit-sidecar.

كيف يعمل

عند تطبيق هذا التكوين على مجموعة Kubernetes الخاصة بك:

1. سيتم إنشاء Pod.
2. داخل هذا Pod، ستبدأ كل من حاوية Nginx وحاوية Fluent Bit Sidecar.
3. ستبدأ حاوية Nginx في كتابة السجلات إلى ملف /var/log/nginx/access.log.
4. ستراقب حاوية Fluent Bit Sidecar ملف /var/log/nginx/access.log في نفس وحدة التخزين المشتركة.
5. ستقرأ إدخالات السجل الجديدة وتوجهها إلى مخرجها القياسي.

للتحقق من ذلك، يمكنك تشغيل الأمر التالي مع اسم Pod:

kubectl logs <nginx-with-log-sidecar-POD_ID> -c fluentbit-sidecar

سترى إدخالات السجل التي أنشأها Nginx في المخرج. وهذا يشير إلى أن Sidecar قد جمع السجلات وعالجها بنجاح.

سيناريوهات متقدمة وأفضل الممارسات

• إدارة الموارد: يعد تحديد حدود CPU والذاكرة لحاويات Sidecar أمرًا مهمًا لتجنب التأثير على استهلاك الموارد للتطبيق الرئيسي. تستهلك الوكلاء الخفيفة مثل Fluent Bit عمومًا موارد قليلة.
• المرونة: تأكد من استمرار تشغيل التطبيق الرئيسي إذا واجه Sidecar خطأ. بشكل عام، لا ينبغي أن تتوقف مشكلات Sidecar عن تشغيل التطبيق الرئيسي.
• إعادة التحميل الساخن (Hot Reload): تدعم بعض وكلاء Sidecar إعادة التحميل "الساخن" دون الحاجة إلى إعادة تشغيل الحاوية عند تغيير التكوين.
• الضغط والتشفير: قد تحتوي السجلات على معلومات حساسة. يساعد تطبيق الضغط والتشفير قبل إرسالها إلى نظام مركزي في الحفاظ على عرض النطاق الترددي ويعزز الأمان.

الخلاصة

يوفر نمط حاوية Sidecar في Kubernetes طريقة أنيقة وفعالة لفصل الاهتمامات المتقاطعة مثل إدارة السجلات عن تطبيقك الرئيسي. يعزز هذا النهج قابلية المراقبة في معماريات الخدمات المصغرة الخاصة بك، ويحافظ على نظافة رمز تطبيقك، ويجعل بنية جمع السجلات لديك أكثر مرونة. باستخدام المثال العملي في هذا الدليل، يمكنك بسهولة تنفيذ هذا النمط في تطبيقاتك السحابية الأصلية وزيادة كفاءتك التشغيلية.