كيفية نشر التطبيقات في Kubernetes
نشرت: 2022-11-09Kubernetes هي واحدة من أكثر أنظمة التشغيل الآلي شيوعًا لنشر حاويات التطبيقات وتوسيع نطاقها وتشغيلها على مجموعة من الأجهزة المضيفة أو العقد.
ستناقش هذه المقالة أحد الكائنات المركزية في Kubernetes: النشر. الهدف هو فهم سلوكها وكيفية إنشائها وتحديثها وحذفها.
ما هو النشر؟
يعد النشر أحد الكائنات المستخدمة لإطلاق Pods. تشجع أفضل ممارسات Kubernetes على استخدام عمليات النشر للتطبيقات عديمة الحالة. بدون النشر ، ستحتاج إلى إنشاء العديد من Pods وتحديثها وحذفها يدويًا ، الأمر الذي قد يكون مملاً وغير عملي للعديد من Pods.
يعلن النشر عن كائن واحد في YAML والذي لا يقوم فقط بإنشاء Pods ولكنه يضمن أيضًا تحديثها وتشغيلها. يمكنك أيضًا بسهولة توسيع نطاق تطبيقاتك تلقائيًا باستخدام النشر على Kubernetes. وبالتالي ، يتم استخدام النشر لتوسيع نطاق إصدارات تطبيقاتك ونشرها والتراجع عنها في Pods.
يخبر النشر أيضًا Kubernetes بعدد نسخ Pod التي نريد تشغيلها ، وسيتولى Kubernetes الباقي. ستنشئ وحدة التحكم المرتبطة ReplicaSet من التكوين الخاص بك عند إنشاء النشر. ستنشئ وحدة التحكم المرتبطة بـ ReplicaSet سلسلة من Pods من تكوين ReplicaSet.
مزايا استخدام النشر بدلاً من إنشاء ReplicaSet مباشرةً هي:
- تأريخ الكائن: سيؤدي كل تغيير في الكائن (عبر "تطبيق" أو "تعديل") إلى إنشاء نسخة احتياطية من الإصدار السابق.
- إدارة الطرح والتراجع: يمكنك الرجوع إلى التكوين فيما يتعلق بالنقطة السابقة.
إنشاء انتشار
هناك طريقتان يمكننا استخدامهما لإنشاء نشر Kubernetes:
الطريقة الحتمية
تسمح واجهات برمجة تطبيقات Kubernetes بمقاربة أكثر مباشرة وضرورية دون الحاجة إلى ملفات تكوين أو بيانات بتنسيق YAML. في هذا النهج ، كل ما نحتاج إلى القيام به هو قول ما نريد القيام به ، وسوف يتحمل Kubernetes مسؤولية تحديد ما يجب القيام به لتحقيق النتيجة المتوقعة.
لاستخدام طريقة الأمر ، ما عليك سوى استخدام الأمر أدناه:
kubectl create deployment nginx-deployment --image nginx --port=80
الطريقة التصريحية
في هذه الطريقة ، يجب عليك التصريح عن كل شيء ، وعند استخدام هذا الرمز ، يقرأ Kubernetes تعريفاتك وينشئ تمامًا كما تم تقديمه أو إعلانه.
لاستخدام النشر التعريفي ، سيتعين عليك إنشاء ملف YAML.
ملف YAML للنشر بالاسم new_deployment.yaml
:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: #Specifies the number of Pod Copies replicas: 3 #Selects the Pod to be managed by the deployment selector: #Matches the defined labels matchLabels: deploy: example template: metadata: #Specifies the labels on the Pod. labels: deploy: example spec: containers: - name: nginx image: nginx:1.20.2
في ملف YAML هذا ، بعد تحديد إصدار Kubernetes API ونوع العنصر الذي تقوم بإنشائه واسم النشر ، يوجد قسم المواصفات. في هذا القسم ، تقوم أولاً بتعريف مفتاح النسخ المتماثل ، والذي يشير إلى عدد مثيلات Pod التي يجب أن يظل النشر نشطًا.
استخدم تسمية محدد لتحديد السنفات في النشر. لهذا ، يمكنك استخدام تسمية النشر ، والتي تخبرنا أن جميع الكبسولات التي تتطابق مع هذه التسميات مجمعة في النشر.
بعد ذلك ، يكون لديك كائن القالب حيث لديك نموذج Pod داخل مواصفات النشر الخاصة بك. عندما ينشئ النشر Pods ، فإنه ينشئها باستخدام هذا القالب. يمكن العثور على مواصفات البود العادي تحت مفتاح القالب.
مع هذا النشر ، سيتم نشر صور Nginx ذات الملصقات في Pods. علاوة على ذلك ، عليك أيضًا توخي الحذر في هذه النقطة ، و Pod هي وحدة قابلية التوسع في Kubernetes ، لذلك عليك التفكير في النمط الذي تريد استخدامه إذا وضعت عدة حاويات في نفس الحجرة.
بعد ذلك ، قم بتطبيق ملف new_deployment.yaml
Yaml ، استخدم الأمر التالي:
kubectl apply -f new_deployment.yaml
بعد بضع ثوانٍ ، يمكنك الحصول على حالة النشر باستخدام ما يلي:
kubectl get all

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

kubectl describe deployment nginx-deployment

الآن لديك وصف كامل لعملية النشر. يسلط الضوء على الإستراتيجية المستخدمة لإنشاء / إعادة بناء البودات عندما يتم تعريف التحديث على أنه RollingUpdate.
تسمح إستراتيجية RollingUpdate بالترحيل المنظم لإصدار واحد من التطبيق إلى إصدار أحدث. إنها الإستراتيجية الافتراضية المستخدمة في Kubernetes.
بالإضافة إلى ذلك ، لدينا أيضًا الاستراتيجيات التالية:
- إعادة إنشاء: إنهاء مثيلات Pod قيد التشغيل حاليًا و "إعادة إنشائها" بالإصدار الجديد ؛
- أزرق / أخضر: تنشئ هذه الإستراتيجية بيئتين منفصلتين لكن متطابقتين. في البيئة الزرقاء ، يعمل التطبيق كما هو ، بينما في البيئة الخضراء ، يعمل التطبيق كما سيكون في المستقبل ؛
- Canary: إستراتيجية نشر حيث تشارك مجموعة فرعية من المستخدمين في الإصدار التزايدي لتطبيق أو خدمة.
إذا اخترت "التحديث المتداول" ، فيمكنك تكوين سلوكه حول عدد النسخ المتماثلة المطلوبة.
- يسمح لك
maxSurge
(بالنسبة المئوية أو الشروط المطلقة) إلى عدد Pods التي يمكنه إنشاؤها بالإضافة إلى عدد النسخ المتماثلة التي تم تكوينها حاليًا. - يسمح لك
maxUnavailable
(بالنسبة المئوية أو بالقيمة المطلقة) إلى عدد Pods التي يمكن أن تكون "غير متوفرة" أثناء التحديث ، اعتمادًا على عدد النسخ المتماثلة التي تم تكوينها.
اعتمادًا على التطبيق الخاص بك وجهاز القياس التلقائي الخاص بك ، ستسمح لك هذه التكوينات بضمان جودة الخدمة أو تسريع عمليات النشر الخاصة بك.
بعد ذلك ، عليك تغيير حجم Pods إلى 10 وتغيير علامة صورة Nginx إلى الأحدث.
kubectl scale deployment nginx-deployment --replicas=10

لاحظ أن لدينا 5 حاويات قيد الإنشاء ، ومن بين 10 حاويات ، لدينا 5 حاويات متاحة.
بعد بضع ثوانٍ ، استخدم الأمر التالي:
kubectl get all
هنا يمكنك أن ترى أنه تم إنشاء جميع الكبسولات ، وأن الحاويات تعمل.

حذف النشر الخاص بك
لحذف نشر Kubernetes ، يمكنك استخدام الأوامر التالية:
kubectl delete deploy nginx-deployment kubectl delete deploy new_deployment.yaml
Helm: تبسيط عمليات النشر
عندما تريد نشر تطبيق معقد يستخدم عشرات أو حتى مئات من موارد Kubernetes ، تصبح أداة kubectl غير مناسبة ، وهذا هو سبب تطوير أداة Helm. Helm هو مدير الحزم لـ Kubernetes الذي يبني على kubectl ويبسط عمليات نشر التطبيق.
في مفردات هيلم ، يُطلق على التطبيق اسم إصدار. يرتبط بمخطط ، أي مجموعة من ملفات التكوين بتنسيق YAML تحتوي على متغيرات وقوالب عامة تصف موارد Kubernetes.
استنتاج
النشر هو كائن Kubernetes أساسي. نظرًا لأن القوة العظمى تعني مسؤولية كبيرة ، يجب أن تكون حذرًا عند تكوينها أو المخاطرة بسلوكيات غير متوقعة. للمضي قدمًا في تكوينات النشر ، يمكنك الرجوع إلى وثائق Kubernetes.
يمكنك أيضًا استكشاف بعض من أفضل دروس Kubernetes للتعلم من البداية وتصبح خبيرًا.