نشر آمن في Kubernetes: الجاهزية والتصريف وحدود PDB

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

ابدأ بعملية المستخدم، لا بلون حالة Pod

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

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

افصل ضوابط النشر عن ميزانية التعطيل

تشرح وثائق Deployment ضابطَي maxUnavailable وmaxSurge. لخدمة بثلاث نسخ، تمثل القيمتان maxUnavailable: 0 وmaxSurge: 1 نقطة بداية توضيحية: الحفاظ على العدد المطلوب من النسخ المتاحة مع السماح بتشغيل نسخة بديلة. يضيف minReadySeconds مدة استقرار قبل احتساب النسخة الجديدة متاحة. تضبط هذه الخيارات التوافر، ولا تثبت صحة العملية التجارية.

ترسم وثائق التعطيل حدًا مهمًا: يقيّد PodDisruptionBudget الإخلاء الطوعي عبر Eviction API، مثل تفريغ عقدة بأداة تحترم الميزانية. لكنه لا يقيّد التحديث التدريجي الذي ينفذه Deployment، مع أن النسخ غير المتاحة يمكن أن تُحتسب ضمن ميزانيته. الحذف المباشر والأعطال غير الطوعية حالتان مختلفتان أيضًا. تفيد PDB في الصيانة؛ ولا تصلح استراتيجية نشر ضعيفة.

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

أعطِ فحوص البدء والجاهزية والحياة وظائف مختلفة

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

يمكن أن يكون الاتفاق المقترح /startup لاكتمال التهيئة، و/ready لقدرة النسخة على قبول العملية المدعومة، و/live لحالة داخل العملية يُرجّح أن يعالجها إعادة التشغيل. لا تعِد تشغيل جميع النسخ لأن قاعدة بيانات مشتركة تعطلت مؤقتًا. ولا تعلن الجاهزية لمجرد فتح منفذ HTTP. في المقابل، قد يسحب فحص جميع الاعتمادات الاختيارية باستمرار نسخًا ما زالت مفيدة. حدد الاعتمادات الضرورية فعلًا للعملية، واجعل الفحوص خفيفة ومحدودة الزمن.

افهم مساري الإنهاء المتزامنين

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

في الوقت نفسه تتغير معلومات التوجيه. يميز مرجع EndpointSlice بين ready وserving وterminating. قد تختلف طريقة تعامل المستهلكين معها، بما فيها السلوك الاحتياطي عندما تكون جميع نقاط النهاية قيد الإنهاء. ولـIngress وموازن الحمل الخارجي وService Mesh سلوك إضافي. يغيّر فشل الجاهزية أهلية استقبال المرور؛ ولا ينهي طلبًا قائمًا أو يلغي كل اتصال مفتوح.

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

استخدم جزء إعدادات باتفاق إغلاق صريح

يوضع الجزء التالي داخل spec في Deployment قائم. الأرقام أمثلة تستبدلها بميزانيات مقاسة. يجب أن ينفذ التطبيق نقاط النهاية المذكورة؛ و/internal/drain عملية إدارية قابلة للتكرار بأمان، وليست API عامة. استخدم منفذ إدارة معزولًا وقيّد الوصول. يظهر GET لأن إجراء HTTP لدورة الحياة يستخدمه؛ فلا تعرض هذا المسار الذي يغيّر الحالة عبر Ingress العام.

replicas: 3
minReadySeconds: 10
progressDeadlineSeconds: 300
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1
template:
  spec:
    terminationGracePeriodSeconds: 60
    containers:
      - name: api
        # Keep the existing immutable image, resources and ports.
        startupProbe:
          httpGet: {path: /startup, port: 8080}
          periodSeconds: 2
          failureThreshold: 30
        readinessProbe:
          httpGet: {path: /ready, port: 8080}
          periodSeconds: 2
          failureThreshold: 2
        livenessProbe:
          httpGet: {path: /live, port: 8080}
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            httpGet: {path: /internal/drain, port: 9090}

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

استخدم قاعدة تخطيط بسيطة: يجب أن تغطي مهلة الإنهاء عمل preStop والوقت المتبقي للعمليات المقبولة والتنظيف وهامشًا احتياطيًا. لا تمنح الإجراء المهلة كلها ثم تتوقع مهلة كاملة أخرى بعد SIGTERM. ميزانيات بدء التشغيل والطلبات والإغلاق منفصلة. في تطبيق Node HTTP، يوقف server.close() قبول الاتصالات الجديدة ويغلق الخاملة؛ أما الإغلاق القسري لجميع الاتصالات فيقطع الاستجابات النشطة أيضًا. تحتاج WebSockets إلى تتبع وإغلاق مستقلين.

أثبت سلامة الانتقال تحت مرور مستمر

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

نفذ أربع حالات مستقلة: تحديثًا طبيعيًا؛ ونسخة بديلة لا تصل إلى الجاهزية؛ وتفريغ عقدة للصيانة يحترم PDB؛ وإغلاقًا يتجاوز مهلة الإنهاء. افحص نتائج العميل والآثار المحفوظة، لا عدد استجابات HTTP وحده. ينبغي لأتمتة النشر اكتشاف التحديث السيئ وإيقافه. يسجل progressDeadlineSeconds فشل التقدم؛ وليس آلية تراجع تلقائي للتطبيق. تحقق من معالجة خط النشر لهذه الحالة بقرار صريح.

تعامل مع إعادة ضبط الاتصالات وتكرار الكتابات والمهام المتروكة وارتفاع التأخير باعتبارها إخفاقات مختلفة. ضع معايير قبول نسبةً إلى خط الأساس لخدمتك؛ لا يقدم هذا المقال نسبة أخطاء عالمية مختلقة. تتبع نتيجة المنتج عبر SLO لمسار المستخدم، واربط السجلات بين الخدمات باستخدام قابلية مراقبة الأنظمة الخلفية.

أفضل استخدام والحدود والأنماط التي تتجنبها

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

تجنب نسخ sleep ثابت من عنقود آخر، وفحص حياة يعيد تشغيل الجميع عند تعطل اعتماد مشترك، ونقطة تصريف عامة، والخروج الفوري عبر process.exit() عند SIGTERM. ولا تعتبر maxUnavailable: 0 وعدًا بانعدام الأخطاء. يجب أن تفهم النسختان القديمة والجديدة البيانات المشتركة أيضًا: استخدم إضافات متوافقة للمخطط وعقود الرسائل قبل إزالة الحقول القديمة. يساعد اتفاق Feature Flags للمنتج على فصل تعريض الميزة عن نشر الكود، لكنه لا يستبدل سلامة الإغلاق.

خطة تنفيذ للإصدار القادم

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

إعداد: Noor Yasser