🥇تحديث مجموعة Kubernetes دون توقف

عملية الترقية لمجموعة Kubernetes الخاصة بك

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

هذه التدوينة جزء من سلسلة مكونة من 4 مشاركات:

هذا المشنور.
الإغلاق الصحيح للقرون في مجموعة Kubernetes
تأخير إنهاء الكبسولة عند حذفها
كيفية تجنب توقف مجموعة Kubernetes باستخدام PodDisruptionBudgets

(تقريبًا نتوقع ترجمة بقية المقالات في السلسلة في المستقبل القريب)

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

عرف المشكل

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

لنبدأ رحلتنا، دعونا نأخذ مثالا ملموسا. لنفترض أن لدينا مجموعة Kubernetes مكونة من عقدتين، حيث يتم تشغيل التطبيق مع حجرتين موجودتين في الخلف Service:

لنبدأ بطبقتين مع Nginx وService يعملان على عقدتي مجموعة Kubernetes.

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

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

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

إعادة توزيع كافة القرون من العقدة

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

رغم أن kubectl drain سوف يقوم بعمل رائع في إخلاء القرون، هناك عاملان آخران يمكن أن يتسببا في فشل عملية التصريف:

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

تجنب التوقف عن العمل

لتقليل وقت التوقف عن العمل الناتج عن التعطيل الطوعي، مثل عملية التصريف على العقدة، يوفر Kubernetes خيارات معالجة الفشل التالية:

في بقية السلسلة، سنستخدم ميزات Kubernetes هذه للتخفيف من تأثير ترحيل البودات. لتسهيل متابعة الفكرة الرئيسية، سنستخدم مثالنا أعلاه مع تكوين الموارد التالي:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

هذا التكوين هو مثال الحد الأدنى Deployment، الذي يدير قرون nginx في المجموعة. بالإضافة إلى ذلك، يصف التكوين المورد Service، والتي يمكن استخدامها للوصول إلى nginx pods في المجموعة.

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

للحصول على إصدار تم تنفيذه واختباره بالكامل من تحديثات مجموعة Kubernetes لعدم التوقف عن العمل على AWS وما بعدها، تفضل بزيارة Gruntwork.io.

ترقية مجموعة Kubernetes بدون توقف

عرف المشكل

إعادة توزيع كافة القرون من العقدة

تجنب التوقف عن العمل

اقرأ أيضًا مقالات أخرى على مدونتنا:

إضافة تعليق إلغاء الرد