3 نصائح لنشر APISIX في Kubernetes (الجزء 2)

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

اعتبارات حول طرق النشر
الفحوصات الصحية، التسجيل، والمراقبة
التعامل مع الإضافات المخصصة والإعدادات

في المقالة السابقة، ناقشنا النقطة الأولى. هذه المقالة ستركز على النقطة الثانية: الاعتبارات المتعلقة بالفحوصات الصحية، التسجيل، والمراقبة.

الفحوصات الصحية

عند نشر APISIX في Kubernetes، تعتبر الفحوصات الصحية مهمة بشكل خاص، حيث تمثل متطلبًا أساسيًا للتطبيقات في Kubernetes. في Kubernetes، يمكن ضمان الحالة الصحية والتوفر لنسخ APISIX من خلال تكوين Liveness وReadiness Probes.

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

من خلال التكوين الصحيح لـ Liveness وReadiness Probes، يمكن لـ Kubernetes إدارة نسخ Pod غير الصحية تلقائيًا. هذا يعني أنه عندما تواجه النسخ مشاكل، فإن Kubernetes سيعيد تشغيلها تلقائيًا أو يتوقف عن إرسال الحركة إلى النسخ غير الصحية، مما يعزز توفر واستقرار النظام.

مثال تكوين YAML:

apiVersion: v1
kind: Deployment
metadata:
  name: my-apisix-pod
spec:
  containers:
  - name: my-apisix-container
    image: my-apisix-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 9080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /readyz
        port: 9080
      initialDelaySeconds: 10
      periodSeconds: 5

يحدد هذا المثال Liveness وReadiness Probes للحاوية. يرسل Liveness Probe طلب HTTP GET إلى المسار /healthz كل 10 ثوانٍ للتحقق من الحالة الصحية للحاوية. إذا لم تستجب الحاوية أو أعادت رمز حالة غير 200، فإن Kubernetes يعتبر الحاوية غير صحية ويحاول إعادة تشغيلها. Readiness Probe مشابه ولكن يتم استخدامه للتحقق مما إذا كانت الحاوية جاهزة لاستقبال الحركة.

المراقبة

هناك طرق مختلفة لمراقبة APISIX أثناء التشغيل، مع أن دمج Prometheus يعتبر نهجًا موصى به. في الواقع، يظل Prometheus أكثر مكونات المراقبة استخدامًا حتى الآن.

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

تمكين مكون Prometheus في APISIX سهل. أولاً، قم بتعيين export_uri في config.yaml.

plugin_attr:
  prometheus:
    export_uri: /apisix/metrics

ثم قم بتمكين المكون على API أو الخدمة التي تحتاج إلى تحليل إحصائي بواسطة Prometheus.

curl http://127.0.0.1:9180/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/hello",
    "plugins": {
        "prometheus":{}
    },
    "upstream": {
        ...
    }
}'

أخيرًا، يمكن لخادم Prometheus سحب التكوينات بشكل دوري من export_uri.

scrape_configs:
  - job_name: "apisix"
    scrape_interval: 15s
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["127.0.0.1:9091"]

في الاستخدام العملي، يتطلب Prometheus أيضًا النشر بطريقة عالية التوفر، مثل استخدام حلول مفتوحة المصدر مثل Thanos. يمكن تحقيق التكامل مع APISIX باستخدام وضع Thanos sidecar.

التسجيل

في APISIX، يتم تصنيف السجلات المهمة بشكل عام إلى نوعين: سجلات الحركة وسجلات التدقيق.

تشير سجلات الحركة إلى تسجيل كل طلب عندما يعمل APISIX كوكيل عكسي. تحتوي هذه السجلات على حركة الطلبات والمعلومات المرتجعة، بالإضافة إلى سجلات العمليات الداخلية لـ APISIX، وهي مهمة للتتبع واستكشاف الأخطاء وإصلاحها. عادةً ما يتم تعيين مستويات وتنسيقات سجلات مناسبة للتسجيل. في السيناريوهات العملية، فكر في إخراج السجلات إلى نظام تسجيل مركزي، مثل ELK (Elasticsearch، Logstash، وKibana)، Fluentd، أو Splunk. يوفر APISIX إضافات تسجيل للاختيار من بينها.
تشير سجلات التدقيق بشكل أساسي إلى السجلات التي يتم إنشاؤها عند إدارة تكوينات APISIX. لا تساعد فقط في تلبية متطلبات الامتثال ولكن أيضًا تستخدم لتحليل الأمان. من خلال تحليل سجلات التدقيق، يمكن تحديد المخاطر الأمنية المحتملة والتكوينات أو السلوكيات الإدارية غير المناسبة، ويمكن اتخاذ الإجراءات المناسبة لتعزيز أمان النظام.

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

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

الخلاصة

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