مشاركة عبر

إرشادات لتشغيل البوابة ذاتية الاستضافة على Kubernetes في الإنتاج

  • مقالة

ينطبق على: المطور | بريميوم

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

تقدم هذه المقالة إرشادات بشأن كيفية تشغيل البوابة ذاتية الاستضافة على Kubernetes لأحمال عمل الإنتاج للتأكد من أنها ستعمل بسلاسة وموثوقية.

هام

سينتهي دعم الإصدار 0 من البوابة المستضافة ذاتيا ل Azure API Management وصور حاوية الإصدار 1 في 1 أكتوبر 2023، جنبا إلى جنب مع واجهة برمجة تطبيقات التكوين المقابلة لها الإصدار 1. استخدم دليل الترحيل الخاص بنا لاستخدام البوابة المستضافة ذاتيا v2.0.0 أو أعلى مع Configuration API v2. تعرف على المزيد في وثائق الإهمال الخاصة بنا

الرمز المميز للوصول

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

عند أتمتة تحديث الرمز المميز، استخدم عملية API الإدارية هذه لإنشاء رمز مميز جديد. للحصول على معلومات حول إدارة البيانات السرية لـ Kubernetes، راجع موقع Kubernetes.

تلميح

يمكنك أيضا نشر البوابة المستضافة ذاتيا إلى Kubernetes وتمكين المصادقة إلى مثيل APIM باستخدام معرف Microsoft Entra.

التحجيم التلقائي

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

هناك طريقتان لمقياس البوابة ذاتية الاستضافة أفقياً تلقائياً:

  • التحجيم التلقائي يعتمد على استخدام الموارد (وحدة المعالجة المركزية والذاكرة)
  • التحجيم التلقائي على أساس عدد الطلبات في الثانية

هذا ممكن من خلال وظائف Kubernetes الأصلية، أو عن طريق استخدام Kubernetes-Event--Based Autoscaling (KEDA). KEDA هو مشروع حاضنة CNCF يسعى إلى جعل التحجيم التلقائي للتطبيق بسيطاً.

إشعار

KEDA هي تقنية مفتوحة المصدر لا يدعمها دعم Azure وتحتاج إلى تشغيلها من قبل العملاء.

التحجيم التلقائي المستند إلى الموارد

يسمح لك Kubernetes بمقياس البوابة ذاتية الاستضافة تلقائياً استناداً إلى استخدام الموارد باستخدام Horizontal Pod Autoscaler. يسمح لك بتعريف حدود وحدة المعالجة المركزية والذاكرة، وعدد النسخ المطابقة لتوسيع نطاقها أو إدخالها.

البديل هو استخدام Kubernetes Event-Based Autoscaling (KEDA) ما يسمح لك بتوسيع أحمال العمل بناءً على مجموعة متنوعة من أدوات القياس، بما في ذلك وحدة المعالجة المركزية والذاكرة.

تلميح

إذا كنت تستخدم KEDA بالفعل لتوسيع نطاق أحمال العمل الأخرى، فنحن نوصي باستخدام KEDA كالتحجيم التلقائي لتطبيق موحد. إذا لم يكن الأمر كذلك، فإننا نقترح بشدة الاعتماد على وظيفة Kubernetes الأصلية من خلال Horizontal Pod Autoscaler.

قياس تلقائي مستند إلى نسبة استخدام الشبكة

لا يوفر Kubernetes آلية خارج الصندوق للتحجيم التلقائي المستند إلى حركة المرور.

يوفر Kubernetes Autoscaling-Based Autoscaling (KEDA) بعض الطرق التي يمكن أن تساعد في التحجيم التلقائي المستند إلى نسبة استخدام الشبكة:

  • يمكنك التحجيم استنادا إلى مقاييس من دخول Kubernetes إذا كانت متوفرة في Prometheus أو Azure Monitor باستخدام أداة تغيير الحجم الجاهزة
  • يمكنك تثبيت الوظيفة الإضافية HTTP، المتوفرة في الإصدار التجريبي، والقياسات بناءً على عدد الطلبات في الثانية.

تكوين النسخ الاحتياطي

قم بتكوين وحدة تخزين محلية لحاوية البوابة ذاتية الاستضافة، بحيث يمكنها الاحتفاظ بنسخة احتياطية من أحدث تكوين تم تنزيله. في حالة تعطل الاتصال، فيمكن لوحدة التخزين استخدام النسخة الاحتياطية عند إعادة التشغيل. يجب أن يكون مسار تحميل وحدة التخزين /apim/config ويجب أن يمتلكه معرف المجموعة 1001. انظر مثالاً على GitHub. لمعرفة المزيد حول دقة الاسم في Kubernetes، راجع موقع Kubernetes. لتغيير ملكية مسار مثبت، راجع securityContext.fsGroup الإعداد على موقع Kubernetes على الويب.

إشعار

للتعرف على سلوك البوابة ذاتية الاستضافة في ظل وجود انقطاع مؤقت في اتصال Azure، راجع نظرة عامة على البوابة ذاتية الاستضافة.

علامة صورة الحاوية

يستخدم ملف YAML المتوفر في مدخل Microsoft Azure أحدث علامة. تشير هذه العلامة دائمًا إلى أحدث إصدار من صورة حاوية البوابة ذاتية الاستضافة.

فكر في استخدام علامة إصدار معينة في الإنتاج لتجنب الترقية غير المقصودة إلى إصدار أحدث.

يمكنك تحميل قائمة كاملة من العلامات المتاحة.

تلميح

عند التثبيت باستخدام Helm، يتم تحسين وضع علامات على الصور لك. يقوم إصدار تطبيق مخطط Helm بتثبيت البوابة بإصدار معين ولا يعتمد على latest.

تعرف على المزيد بشأن كيفية تثبيت بوابة مستضافة ذاتياً APIM برمجة التطبيقات على Kubernetes مع Helm.

موارد الحاوية

بشكل افتراضي، لا يحدد ملف YAML المتوفر في مدخل Microsoft Azure طلبات موارد الحاوية.

من المستحيل التنبؤ بشكل موثوق بكمية موارد الذاكرة ووحدة المعالجة المركزية لكل حاوية والتوصية بها وعدد النسخ المتماثلة المطلوبة لدعم حمل عمل معين. هناك العديد من العوامل التي تؤدي دورًا، مثل:

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

نوصي بتعيين طلبات الموارد على مركزين و2 غيغابايت كنقطة بداية. قم بإجراء اختبار التحميل والتوسيع بطريقة أفقية أو عمودية أو تغيير الحجم بالنقصان أو الزيادة بناءً على النتائج.

أسماء المجالات المخصصة وشهادات SSL

إذا كنت تستخدم أسماء مجالات مخصصة لنقاط نهاية APIM، خاصة إذا كنت تستخدم اسم مجال مخصص لنقطة نهاية الإدارة، فقد تحتاج إلى تحديث قيمة config.service.endpoint في <ملف gateway-name.yaml> لاستبدال اسم المجال الافتراضي باسم المجال المخصص. تأكد من إمكانية الوصول إلى نقطة نهاية الإدارة من حزمة البوابة ذاتية الاستضافة في مجموعة Kubernetes.

في هذا السيناريو، إذا لم يتم توقيع شهادة SSL التي تستخدمها نقطة نهاية الإدارة بواسطة شهادة CA معروفة جيدًا، فيجب عليك التأكد من أن شهادة CA موثوقة من قِبل مجموعة البوابة ذاتية الاستضافة.

إشعار

باستخدام الإصدار الثاني من البوابة المستضافة ذاتيًا، يوفر APIM نقطة نهاية تكوين جديدة: <apim-service-name>.configuration.azure-api.net. يتم دعم أسماء المضيفين المخصصة لنقطة النهاية هذه ويمكن استخدامها بدلا من اسم المضيف الافتراضي.

سياسة DNS

يلعب تحليل اسم DNS دورًا مهمًا في قدرة البوابة ذاتية الاستضافة على الاتصال بالتبعيات في Azure وإرسال استدعاءات API إلى خدمات الواجهة الخلفية.

يطبق ملف YAML المتوفر في بوابة Azure نهج ClusterFirst الافتراضي. يؤدي هذا النهج إلى إعادة توجيه طلبات تحليل الاسم التي لم يتم حلها بواسطة مجموعة DNS إلى خادم DNS الرئيسي الموروث من العقدة.

لمعرفة المزيد حول دقة الاسم في Kubernetes، راجع موقع Kubernetes. خذ بعين الاعتبار تخصيص نهج DNS أو تكوين DNS كما هو مناسب لإعدادك.

سياسة نسبة استخدام الشبكة الخارجية

يعيّن ملف YAML المتوفر في المدخل Azure externalTrafficPolicy الحقل على كائن الخدمة إلى Local . هذا يحافظ على عنوان IP المتصل (يمكن الوصول إليها في سياق الطلب)وتعطيل موازنة تحميل العقدة، والقضاء على وثبات الشبكة الناجمة عن ذلك. كن على علم، أن هذا الإعداد قد يتسبب في توزيع غير متماثل لنسبة الاستخدام في عمليات النشر مع عدد غير متساوٍ من حزم البوابة لكل عقدة.

التوافر العالي

تعد البوابة ذاتية الاستضافة مكوناً مهماً في البنية الأساسية ويجب أن تكون متاحة بشكل كبير. ومع ذلك، فإن الفشل سيحدث ويمكن أن يحدث.

ضع في اعتبارك حماية البوابة ذاتية الاستضافة من الانقطاع.

تلميح

عند التثبيت باستخدام Helm، قم بتمكين الجدولة العالية المتوفرة بسهولة عن طريق تمكين خيار التكوين highAvailability.enabled.

تعرف على المزيد بشأن كيفية تثبيت بوابة مستضافة ذاتياً APIM برمجة التطبيقات على Kubernetes مع Helm.

الحماية من فشل العقدة

لمنع التأثر بسبب فشل مركز البيانات أو العقدة، ضع في اعتبارك استخدام مجموعة Kubernetes التي تستخدم مناطق الإتاحة لتحقيق قابلية الوصول العالية على مستوى العقدة.

تسمح لك مناطق التوفر بجدولة حجرة البوابة ذاتية الاستضافة على العقد المنتشرة عبر المناطق باستخدام:

إشعار

إذا كنت تستخدم خدمة Azure Kubernetes، فتعرف على كيفية استخدام مناطق التوفر في هذه المقالة.

الحماية من اضطراب البودات

يمكن أن تتعرض البودات للانقطاع نتيجة لأسباب مختلفة مثل الحذف اليدوي للقرص وصيانة العقد وما إلى ذلك.

ضع في اعتبارك استخدام موازنات تعطيل Pod لفرض توفر حد أدنى من الكبسولات في أي وقت محدد.

وكيل HTTP (S)

توفر البوابة المستضافة ذاتيا الدعم لوكيل HTTP (S) باستخدام متغيرات البيئة التقليدية HTTP_PROXYوHTTPS_PROXY.NO_PROXY

بمجرد التكوين، ستستخدم البوابة المستضافة ذاتيا الوكيل تلقائيا لجميع طلبات HTTP(S) الصادرة إلى خدمات الواجهة الخلفية.

بدءا من الإصدار 2.1.5 أو أعلى، توفر البوابة المستضافة ذاتيا إمكانية الملاحظة المتعلقة بطلب الوكيل:

  • سيعرض API Inspector خطوات إضافية عند استخدام وكيل HTTP (S) وتفاعلاته ذات الصلة.
  • يتم توفير سجلات مطولة لتوفير إشارة إلى سلوك وكيل الطلب.

إشعار

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

تحذير

تأكد من استيفاء متطلبات البنية الأساسية وأن البوابة المستضافة ذاتيا لا تزال قادرة على الاتصال بها أو أن وظائف معينة لن تعمل بشكل صحيح.

السجلات والمقاييس المحلية

ترسل البوابة ذاتية الاستضافة بيانات تتبع الاستخدام إلى Azure Monitor وAzure Application Insights وفقًا لإعدادات التكوين في خدمة API Management. عند فقدان الاتصال إلى Azure مؤقتًا، تتم مقاطعة تدفق بيانات تتبع الاستخدام إلى Azure ويتم فقدان البيانات طوال مدة الانقطاع.

ضع في اعتبارك استخدام Azure Monitor Container Insights لمراقبة الحاويات الخاصة بك أو إعداد مراقبة محلية لضمان القدرة على مراقبة حركة مرور واجهة برمجة التطبيقات ومنع فقدان بيانات تتبع الاستخدام أثناء انقطاع اتصال Azure.

مساحة الاسم

تساعد مساحات أسماء Kubernetes في تقسيم مجموعة واحدة بين فرق متعددة أو مشاريع أو تطبيقات. توفر مساحات الأسماء نطاقًا للموارد والأسماء. ويمكن أن تكون مقترنة بحصص نسبية للموارد وسياسات التحكم بالوصول.

يوفر مدخل Microsoft Azure أوامر لإنشاء موارد البوابة المستضافة ذاتيًا في مساحة الاسم الافتراضية. يتم إنشاء مساحة الاسم هذه تلقائيًا، وهي موجودة في كل مجموعة، ولا يمكن حذفها. خذ بعين الاعتبار إنشاء ونشر بوابة ذاتية الاستضافة في مساحة اسم منفصلة في الإنتاج.

عدد النسخ المتماثلة

الحد الأدنى لعدد النسخ المتماثلة المناسبة للإنتاج هو ثلاثة، ويفضل دمجها مع جدولة عالية التوفر للمثيلات.

بشكل افتراضي، يتم نشر بوابة ذاتية الاستضافة باستخدام إستراتيجيةنشر RollingUpdate . راجع القيم الافتراضية وضع في الاعتبار تعيين حقلي maxUnavailable وmaxSurge بشكل صريح، خاصة عند استخدام عدد النسخ المتماثلة الكبير.

الأداء

نوصي بتقليص سجلات الحاويات إلى تحذيرات (warn) لتحسين الأداء. تعرف على المزيد في مرجع تكوين البوابة المستضافة ذاتيا.

تقييد الطلبات

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

  • المنفذ 4290 (UDP)، لمعدل الحد من المزامنة
  • المنفذ 4291 (UDP)، لإرسال رسائل كشف أخطاء الاتصال إلى مثيلات أخرى

إشعار

يمكن تكوين عدد حدود المعدلات في بوابة مستضافة ذاتيا للمزامنة محليا (بين مثيلات البوابة عبر عقد نظام المجموعة)، على سبيل المثال، من خلال نشر مخطط Helm ل Kubernetes أو باستخدام قوالب توزيع مدخل Azure. ومع ذلك، لا تتم مزامنة عدد حدود المعدل مع موارد البوابة الأخرى التي تم تكوينها في مثيل APIM، بما في ذلك البوابة المدارة في السحابة.

الأمان

يمكن تشغيل البوابة ذاتية الاستضافة باعتبارها غير جذر في Kubernetes ما يسمح للعملاء بتشغيل البوابة بأمان.

فيما يلي مثال على سياق الأمان لحاوية البوابة المستضافة ذاتيا:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

تحذير

لا يتم دعم تشغيل البوابة ذاتية الاستضافة بنظام ملفات للقراءة فقط (readOnlyRootFilesystem: true).

تحذير

عند استخدام شهادات CA المحلية، يجب أن تعمل البوابة ذاتية الاستضافة بمعرف المستخدم (UID) 1001 من أجل إدارة شهادات CA وإلا فلن تبدأ البوابة.

الخطوات التالية