آخر مرة ، درسنا طريقتين للعمل مع microservices. على وجه الخصوص ، يتضمن أحدها استخدام حاويات Docker ، والتي يمكنك من خلالها تنفيذ التعليمات البرمجية للخدمات الصغيرة والبرامج المساعدة. اليوم ، باستخدام صور الحاويات الموجودة لدينا ، سنعمل مع Kubernetes.
تقديم Kubernetes
أعدك ، وأنا لا أبالغ في ذلك عندما تقرأ هذا المقال ، اسأل نفسك: "لماذا لا يطلق على Kubernetes اسم Supernetes؟"
شبكات سوبر نتإذا قرأت الجزء السابق من هذه المادة ، فأنت تعلم أن هناك نظرنا في الكثير من الأشياء المتعلقة بإعداد طلبات النقل بالحاويات والعمل مع حاويات Docker. قد يبدو لك أن أصعب شيء في انتظارك الآن ، ولكن في الحقيقة ، ما نتحدث عنه هنا أبسط بكثير مما توصلنا إليه بالفعل. السبب الوحيد الذي يجعل تعلم Kubernetes قد يبدو مهمة شاقة لشخص ما هو بسبب كمية المعلومات الإضافية التي تحتاج إلى فهم Kubernetes واستخدامها بفعالية. لقد ناقشنا بالفعل جميع "المعلومات الإضافية" اللازمة لنجاح تطوير Kubernetes.
is ما هو Kubernetes؟
في الجزء الأول من هذه المقالة ، بعد تشغيل الخدمات المصغرة في الحاويات ، طُلب منك التفكير في مسألة توسيع نطاق التطبيقات في حاويات.
أقترح التفكير في الأمر معًا في شكل أسئلة وأجوبة:
السؤال: كيف يتم قياس حجم التطبيقات في الحاوية؟
الجواب: إطلاق حاويات إضافية.
سؤال: وكيف يتم توزيع الحمل بينهما؟ ماذا لو تم استخدام خادم معين بالفعل إلى الحد الأقصى ، وتحتاج الحاوية إلى نشرها على خادم آخر؟ كيفية العثور على الطريقة الأكثر فعالية لاستخدام الأجهزة؟
الإجابة: إذن ... سأبحث على الإنترنت ...
السؤال: كيفية تحديث البرامج دون تعطيل النظام؟ وإذا كان التحديث يحتوي على خطأ ، كيف يمكنك الرجوع إلى إصدار العمل من التطبيق؟
في الواقع ، فإن تكنولوجيا Kubernetes هي التي تقدم إجابات مفيدة لهذه الأسئلة والعديد من الأسئلة الأخرى. سأحاول تضييق نطاق تعريف Kubernetes إلى جملة واحدة: "Kubernetes هو نظام لإدارة الحاويات يستخلص البنية التحتية الأساسية (البيئة التي تعمل فيها الحاويات)."
أعتقد أنك الآن غير واضح بشكل خاص حول مفهوم "إدارة الحاويات" ، على الرغم من أننا ذكرنا هذا بالفعل. أدناه سوف ننظر في هذه التكنولوجيا في الممارسة العملية. ومع ذلك ، فإن مفهوم "تجريد البنية التحتية الأساسية" يتم مواجهته أولاً. لذلك ، الآن سوف ننظر فيها.
b استخراج البنية التحتية الأساسية
يسمح Kubernetes للتطبيقات بالاستخراج من البنية التحتية ، مما يوفر لنا واجهة برمجة تطبيقات بسيطة يمكنك إرسال الطلبات إليها. تحاول Kubernetes تلبية هذه الطلبات باستخدام جميع إمكاناتها. على سبيل المثال ، بلغة عادية ، يمكن وصف طلب مماثل على النحو التالي: "Kubernetes ، قم بتوسيع 4 حاويات صور X". بعد تلقي الأمر ، سيعثر Kubernetes على عقد ليست مشغولة جدًا (يطلق عليها أيضًا "العقد" - من "العقدة الإنجليزية") ، والتي يمكنك نشر حاويات جديدة عليها.
طلب خادم APIماذا يعني هذا للمطور؟ هذا يعني أنه لا يحتاج إلى القلق بشأن عدد العقد ، أو حول مكان إطلاق الحاويات بالضبط ، أو كيفية تفاعلها. ليس عليه التعامل مع تحسين الأجهزة أو القلق بشأن العقد التي قد تتعطل (وسيحدث بالتأكيد شيء مشابه ، وفقًا لقانون مورفي) ، لأنه إذا لزم الأمر ، يمكن إضافة عقد جديدة إلى مجموعة Kubernetes. إذا حدث خطأ ما في بعض العقد الموجودة ، فستقوم Kubernetes بنشر حاويات لتلك العقد التي لا تزال في حالة صحية.
الكثير مما يظهر في الشكل السابق مألوف لك. ولكن هناك أيضًا شيء جديد:
- خادم API إن إجراء مكالمات إلى هذا الخادم هي الطريقة الوحيدة للتفاعل مع المجموعة التي لدينا ، سواء كنا نتحدث عن بدء أو إيقاف الحاويات ، أو التحقق من حالة النظام ، أو العمل مع السجلات ، أو تنفيذ إجراءات أخرى.
- Kubelet. هذا هو العامل الذي يراقب الحاويات داخل العقدة ويتفاعل مع العقدة الرئيسية.
يرجى ملاحظة أنه في جملتين سابقتين نستخدم المصطلح "حاوية" ، ولكن سيكون من الأصح هنا استخدام المصطلح "pod". غالبًا ما تسمى هذه الكيانات "قرون" في منشورات باللغة الروسية ، وأحيانًا - "قرون" ، في
الوثائق التي توضح مفهوم "القرنة" ، فهي تتحدث عن "قطيع من الحيتان" (قرنة الحيتان) أو "قرنة الحوت" ولكن لا أحد يدعوهم "قطعان" أو "قرون". التحدث عنهم ، سوف نستخدم كلمة "تحت". الآن يمكنك اعتبارها حاويات ، وسوف نتحدث أكثر عن القرون أدناه.
سنتوقف عند هذا في الوقت الحالي ، حيث يمكننا الحديث عن كل هذا أكثر ، وإلى جانب ذلك ، هناك الكثير من المواد الجيدة فيما يتعلق بنظرية Kubernetes. على سبيل المثال ، هذه وثائق رسمية ، على الرغم من أنها ليست سهلة القراءة ، أو كتب مثل
هذا .
▍ توحيد العمل مع مقدمي الخدمات السحابية
تكمن قوة Kubernetes الأخرى في حقيقة أن هذه التكنولوجيا تساهم في توحيد العمل مع مزودي الخدمات السحابية (Cloud Service Provider، CSP). هذا بيان جريء. النظر في المثال التالي. يجب على المتخصص الذي يعرف Azure أو Google Cloud Platform أن يعمل في مشروع مصمم لبيئة سحابة جديدة تمامًا له ، وهو غير مألوف لديه. في هذه الحالة ، يمكن أن يحدث الكثير. على سبيل المثال ، قد يتم تأخير المواعيد النهائية لتسليم المشروع ، وقد تحتاج الشركة العميلة للمشروع إلى استئجار موارد سحابية أكثر من المخطط لها ، وما إلى ذلك.
عند استخدام Kubernetes ، لا يمكن أن تنشأ مثل هذه المشكلة ، لأنه بغض النظر عن موفر الخدمة السحابية الذي نتحدث عنه ، فإن العمل مع Kubernetes يبدو دائمًا كما هو. يقوم المطور ، بأسلوب تعريفي ، بإعلام خادم API بما يحتاج إليه ، ويعمل Kubernetes مع موارد النظام ، مما يسمح للمطور بتجاهل تفاصيل تنفيذ هذا النظام.
استمر قليلاً في هذه الفكرة ، لأن هذه فرصة قوية جدًا في Kubernetes. بالنسبة إلى الشركات ، هذا يعني أن قراراتها ليست مرتبطة بخطة خدمة خاصة معينة. إذا وجدت شركة عرضًا أفضل في سوق الخدمات السحابية ، فيمكنها الاستفادة من هذا العرض بحرية من خلال الانتقال إلى مزود جديد. علاوة على ذلك ، فإن الخبرة التي اكتسبها متخصصو الشركة لا تضيع في أي مكان.
الآن دعونا نتحدث عن الاستخدام العملي لل Kubernetes
Kubernetes الممارسة: القرون
لقد قمنا بتكوين إطلاق خدمات microservices في حاويات ، وكانت عملية الإعداد مملة للغاية ، لكننا تمكنا من الوصول إلى نظام عمل. بالإضافة إلى ذلك ، كما ذكرنا سابقًا ، فإن حلنا لا يتطور بشكل جيد ولا يقاوم الفشل. سوف نحل هذه المشاكل مع Kubernetes. بعد ذلك ، سننقل نظامنا إلى نموذج يتوافق مع المخطط التالي. وهي الحاويات التي ستديرها Kubernetes.
تعمل Microservices في مجموعة تدار بواسطة Kubernetesهنا ، سنستخدم Minikube للنشر المحلي للكتلة ولاختبار قدرات Kubernetes ، على الرغم من أن كل ما سنفعله هنا يمكن القيام به باستخدام الأنظمة الأساسية السحابية مثل Azure أو Google Cloud Platform.
and التثبيت وبدء Minikube
لتثبيت Minikube ، اتبع الإرشادات الموجودة في
الوثائق . أثناء تثبيت Minikube ، سوف تقوم أيضًا بتثبيت Kubectl. هذا هو العميل الذي يسمح بتقديم الطلبات إلى خادم Kubernetes API.
لبدء Minikube ، قم بتشغيل الأمر
minikube start ، وبعد اكتماله ، قم بتشغيل الأمر
kubectl get nodes . نتيجة لذلك ، يجب أن ترى شيئًا مما يلي:
kubectl get nodes NAME STATUS ROLES AGE VERSION minikube Ready <none> 11m v1.9.0
تضع Minikube تحت تصرفنا مجموعة تتكون من عقدة واحدة فقط. صحيح ، هذا يناسبنا بشكل جيد. لا يحتاج الأشخاص الذين يعملون مع Kubernetes إلى القلق بشأن عدد العقد الموجودة في المجموعة بالضبط ، لأن Kubernetes يسمح لك بالاستخلاص من هذه التفاصيل.
الآن دعونا نتحدث عن القرون.
odPods
أنا حقا أحب الحاويات ، وربما كنت أيضا مثلهم الآن. لماذا تقدم Kubernetes لنا استخدام القرون ، وهي الكيانات التي تمثل الحد الأدنى لوحدات الحوسبة القابلة للنشر في هذا النظام؟ ما هي الوظائف التي يؤديها تحت؟ الحقيقة هي أن الموقد قد يتضمن حاوية واحدة أو أكثر تشترك في نفس وقت التشغيل.
لكن هل من الضروري القيام ، على سبيل المثال ، بحاويتين في موقد واحد؟ كيف أقول ... عادة ما يكون هناك حاوية واحدة فقط لكل حاوية ، وهذا ما سنفعله. ولكن في هذه الحالات ، على سبيل المثال ، تحتاج حاويتان إلى وصول مشترك إلى نفس مستودع البيانات ، أو إذا كانا متصلين باستخدام تقنية الاتصال بين العمليات ، أو إذا كانا متصلين بشكل وثيق لسبب آخر ، يمكن تحقيق ذلك كله عن طريق تشغيلها في موقد واحد. الاحتمال الآخر أن القرون تختلف في أنه ليس لديهم لاستخدام حاويات دوكر. إذا لزم الأمر ، يمكنك هنا تطبيق تقنيات أخرى لحاويات التطبيقات ، على سبيل المثال -
Rkt .
يعرض الرسم البياني التالي خصائص الموقد المرقمة.
خصائص الموقدالنظر في هذه الخصائص.
- كل جراب في كتلة Kubernetes لديه عنوان IP فريد.
- يمكن أن تحتوي الموقد على العديد من الحاويات. يشاركون أرقام المنافذ المتوفرة ، على سبيل المثال ، يمكنهم تبادل المعلومات مع بعضهم البعض عبر
localhost (وبطبيعة الحال ، لا يمكنهم استخدام نفس المنافذ). يتم تنظيم التفاعل مع الحاويات الموجودة في القرون الأخرى باستخدام عناوين IP لهذه القرون. - تشارك الحاويات في القرون أحجام تخزين البيانات ، وعنوان IP ، وأرقام المنافذ ، ومساحة اسم IPC.
تجدر الإشارة إلى أن الحاويات لها أنظمة ملفات معزولة خاصة بها ، لكن يمكنها مشاركة البيانات باستخدام مورد Kubernetes يسمى
Volume .
بالنسبة لنا ما قيل بالفعل عن الموقد يكفي لمواصلة السيطرة على Kubernetes. اقرأ المزيد عنها
هنا .
of وصف الموقد
فيما يلي ملف بيان للتطبيق
sa-frontend .
apiVersion: v1 kind: Pod # 1 metadata: name: sa-frontend # 2 spec: # 3 containers: - image: rinormaloku/sentiment-analysis-frontend # 4 name: sa-frontend # 5 ports: - containerPort: 80
دعونا شرح بعض المعلمات المحددة في ذلك.
Kind : يحدد نوع مورد Kubernetes الذي نريد إنشاءه. في حالتنا ، وهذا هو Pod .Name : اسم المورد. أطلقنا عليه sa-frontend .Spec : كائن يصف الحالة المطلوبة للمورد. الخاصية الأكثر أهمية هنا هي مجموعة من الحاويات.Image : صورة الحاوية التي نريد تشغيلها في هذا الملف.Name : Name فريد للحاوية الموجودة أسفله.ContainerPort : المنفذ الذي تستمع إليه الحاوية. يمكن اعتبار هذه المعلمة إشارة إلى من يقرأ هذا الملف (إذا حذفت هذه المعلمة ، فلن يؤدي ذلك إلى تقييد الوصول إلى المنفذ).
hear إنشاء الموقد SA-Frontend
يمكن العثور على ملف وصف pod الذي تحدثنا عنه في
resource-manifests/sa-frontend-pod.yaml . يجب عليك إما الانتقال إلى هذا المجلد باستخدام أدوات المحطة الطرفية ، أو عند استدعاء الأمر المناسب ، حدد المسار الكامل للملف. إليك هذا الأمر ومثال على رد فعل النظام عليه:
kubectl create -f sa-frontend-pod.yaml pod "sa-frontend" created
لمعرفة ما إذا كان يعمل ضمن ، قم بتشغيل الأمر التالي:
kubectl get pods NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 7s
إذا كانت حالة الموقد أثناء تنفيذ هذا الأمر هي
ContainerCreating ، فيمكنك تشغيل نفس الأمر باستخدام
--watch . نتيجة لهذا ، عندما تكون الموقد في حالة
Running ، سيتم عرض معلومات حولها تلقائيًا.
ccess الوصول إلى التطبيق من الخارج
من أجل تنظيم الوصول إلى التطبيق من الخارج ، سيكون من الصحيح إنشاء مورد Kubernetes من نوع الخدمة ، والذي سنتحدث عنه أدناه ، ولكن هنا ، من أجل الإيجاز ، سنستخدم إعادة توجيه منفذ بسيط:
kubectl port-forward sa-frontend 88:80 Forwarding from 127.0.0.1:88 -> 80
إذا انتقلت الآن إلى متصفح على
127.0.0.1:88 ، يمكنك رؤية صفحة تطبيق React.
approach نهج التحجيم الخاطئ
لقد سبق أن قلنا إن إحدى قدرات Kubernetes هي تحجيم التطبيقات. لتجربة هذه الفرصة ، سنقوم بتشغيل واحدة أخرى تحت. قم بإنشاء وصف لمورد
Pod آخر عن طريق وضع التعليمات البرمجية التالية في ملف
sa-frontend-pod2.yaml :
apiVersion: v1 kind: Pod metadata: name: sa-frontend2 # spec: containers: - image: rinormaloku/sentiment-analysis-frontend name: sa-frontend ports: - containerPort: 80
كما ترون ، إذا قارنت هذا الوصف مع ما درسناه أعلاه ، فإن التغيير الوحيد فيه هو قيمة خاصية
Name .
إنشاء واحدة جديدة تحت:
kubectl create -f sa-frontend-pod2.yaml pod "sa-frontend2" created
تأكد من تشغيله:
kubectl get pods NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 7s sa-frontend2 1/1 Running 0 7s
الآن لدينا اثنين من الموقد! صحيح ، لا يوجد شيء خاص للاستمتاع هنا. يرجى ملاحظة أن حل مشكلة توسيع نطاق التطبيق الموضح هنا يحتوي على العديد من العيوب. سنتحدث عن كيفية القيام بذلك بشكل صحيح في القسم الخاص بمورد Kubernetes آخر يسمى Deployment.
الآن فكر في ما حصلنا عليه بعد إطلاق اثنين من الموقد المتماثل. وهي ، خادم الويب Nginx يعمل الآن في اثنين من القرون المختلفة. في هذا الصدد ، يمكننا طرح سؤالين:
- كيفية منح الوصول إلى هذه الخوادم من الخارج ، عن طريق URL؟
- كيفية تنظيم موازنة الحمل بينهما؟
نهج التحجيم خاطئمن بين أدوات Kubernetes هناك موارد من خدمة النموذج. دعنا نتحدث عنهم.
Kubernetes Practice: الخدمات
تعمل خدمات Kubernetes كنقاط وصول إلى مجموعات الموقد التي توفر نفس الوظيفة مثل هذه الموقد. تقوم الخدمات بحل المهام الصعبة المتمثلة في العمل مع الموقد وموازنة العبء بينها.
خدمة Kubernetes تقدم عناوين IPفي مجموعة Kubernetes الخاصة بنا ، سيكون هناك قرون تنفذ وظائف مختلفة. هذا هو تطبيق الواجهة الأمامية ، تطبيق ويب Spring ، وتطبيق Flask مكتوب في Python. يثير هذا السؤال كيف يجب أن تفهم الخدمة نوع القرون التي تحتاج إلى العمل معها ، أي كيفية معرفة على أساس المعلومات التي يجب على النظام إنشاء قائمة بنقاط النهاية للقرون.
يتم ذلك مع تجريد Kubernetes آخر يسمى التسمية. يتكون العمل باستخدام العلامات من مرحلتين:
- سوف تعطي مهمة التسمية الخدمة للعمل معها.
- تطبيق "محدد" على الخدمة ، والذي يحدد القرون التي سيتم تعيين الملصقات ، ستعمل الخدمة.
ربما يكون هذا أسهل في التوضيح كتصور.
القرون المسمى وملفات البيان الخاصة بهمنرى هنا اثنين من المداخل ، باستخدام
app: sa-frontend إنشاء
app: sa-frontend ، يتم تعيين نفس التسميات. تهتم الخدمة بالقرون التي تحمل هذه العلامات.
علامات
توفر الملصقات للمطورين طريقة بسيطة لتنظيم موارد Kubernetes. إنها أزواج ذات قيمة رئيسية ، ويمكنك تخصيصها لأي موارد. قم بتعديل ملفات وصف تطبيق الواجهة الأمامية وإحضارها إلى العرض الموضح في الشكل السابق. بعد ذلك ، احفظ هذه الملفات وقم بتشغيل الأوامر التالية:
kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured
عندما يتم تنفيذ هذه الأوامر ، سيصدر النظام تحذيرات (لا يناسبنا أننا نستخدم
apply بدلاً من
create ، نحن نفهم هذا) ، ولكن بعد تحذير ، يُبلغ عن تكوين القرون المقابلة. يمكننا التحقق مما إذا كانت التسميات تم تعيين تسميات لها ، من خلال تصفية السجلات التي نريد عرض المعلومات لها:
kubectl get pod -l app=sa-frontend NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 2h sa-frontend2 1/1 Running 0 2h
هناك طريقة أخرى للتحقق من أن التسميات قد تم بالفعل تعيين تسميات هي إرفاق
--show-labels إلى الأمر السابق. نتيجة لهذا ، فإن المعلومات الخاصة بقرونهم سوف تتضمن أيضًا بيانات عن علاماتهم.
الآن تم تعيين العلامات ونحن مستعدون لتهيئة الخدمة للعمل معهم. لذلك ، سنتعامل مع وصف خدمة مثل
LoadBalancer .
موازنة التحميل باستخدام خدمة مثل LoadBalancer▍ وصف الخدمة
فيما يلي وصف YAML لخدمة مثل
LoadBalancer :
apiVersion: v1 kind: Service # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer # 2 ports: - port: 80 # 3 protocol: TCP # 4 targetPort: 80 # 5 selector: # 6 app: sa-frontend # 7
اشرح هذا النص:
Kind : نقوم بإنشاء خدمة ، مورد Service .Type : نوع المورد المشار إليه في مواصفاته. اخترنا نوع LoadBalancer ، لأنه مع هذه الخدمة نريد حل مشكلة موازنة التحميل بين الموقد.Port : المنفذ الذي تقبل الخدمة عليه الطلبات.Protocol : البروتوكول المستخدم من قبل الخدمة.TargetPort : منفذ يتم إعادة توجيه الطلبات الواردة إليه.Selector : كائن يحتوي على معلومات حول القرون التي يجب أن تعمل معها الخدمة.app: sa-frontend : تشير هذه الخاصية إلى القرون التي ستعمل عليها الخدمة. وهي هذه هي القرون التي تم تخصيص app: sa-frontend تم تخصيص علامة app: sa-frontend .
لإنشاء خدمة ، تحتاج إلى تشغيل الأمر التالي:
kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created
يمكنك التحقق من حالة الخدمة على النحو التالي:
kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE sa-frontend-lb LoadBalancer 10.101.244.40 <pending> 80:30708/TCP 7m
هنا يمكنك أن ترى أن خاصية
EXTERNAL-IP في حالة
<pending> ، لكن لا يمكنك الانتظار حتى تتغير. هذا يرجع إلى حقيقة أننا نستخدم Minikube. إذا أنشأنا خدمة مماثلة أثناء العمل مع موفر خدمة سحابية معين ، مثل Azure أو Google Cloud Platform ، فسيكون للخدمة عنوان IP عام يتيح الوصول إليها من الإنترنت.
على الرغم من ذلك ، لن تسمح لنا Minikube بالتلاعب ، مما يوفر لنا أمرًا مفيدًا لتصحيح الأخطاء المحلية للنظام:
minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser...
بفضل هذا الأمر ، سيتم إطلاق متصفح يمكنه الوصول إلى الخدمة. بعد تلقي الخدمة للطلب ، ستقوم بإعادة توجيهها إلى أحد الموقد (لا يهم أي منها سيكون تحت). يتيح لنا هذا التجريد إدراك مجموعة من الموقد ككيان واحد والعمل معهم ، باستخدام الخدمة كنقطة وصول واحدة لهم.
في هذا القسم ، تحدثنا عن كيفية تعيين التصنيفات إلى الموارد ، وكيفية استخدامها عند تكوين الخدمات كمحددات. هنا قمنا بوصف وإنشاء خدمة مثل
LoadBalancer . بفضل هذا ، قمنا بحل مشكلة توسيع نطاق التطبيق (يتكون النطاق من إضافة مداخل جديدة مع التسميات المقابلة إلى المجموعة) وتنظيم موازنة التحميل بين الموقد باستخدام الخدمة كنقطة دخول.
Kubernetes Practice: عمليات النشر
النشر عبارة عن مجموعة من Kubernetes التي تتيح لنا التحكم في ما هو موجود دائمًا في دورة حياة التطبيق. إنه يتعلق بإدارة تغييرات التطبيق. التطبيقات التي لا تتغير ، إذا جاز التعبير ، هي تطبيقات "ميتة". إذا كان التطبيق "حيًا" ، فقد تواجه حقيقة أن متطلباته تتغير بشكل دوري ، ويتم توسيع الرمز الخاص به ، ويتم حزم هذا الرمز ونشره. علاوة على ذلك ، قد يتم ارتكاب أخطاء في كل خطوة من العملية.
يسمح لك مورد من نوع النشر بأتمتة عملية الانتقال من إصدار تطبيق إلى آخر. يتم ذلك دون مقاطعة النظام ، وإذا حدث خطأ أثناء هذه العملية ، فستتاح لنا الفرصة للعودة بسرعة إلى الإصدار السابق والتطبيقي من التطبيق.
▍ استخدام النشرات
تحتوي المجموعة الآن على اثنين من الموقد وخدمة تتيح الوصول إليها من الخارج وتوازن الحمل عليها.
الوضع الحالي للكتلةتحدثنا عن حقيقة أن تشغيل اثنين من الموقد مختلفة مع نفس الوظيفة ليست فكرة جيدة. عند استخدام مثل هذا المخطط ، يتعين علينا العمل مع كل موقد على حدة ، وإنشاء وتحديث وحذف كل موقد معين ، ومراقبة حالته. مع هذا النهج ، ليست هناك حاجة للحديث عن التحديث السريع للنظام أو التراجع السريع عن التحديث غير الناجح. نحن لسنا راضين عن هذا الوضع ، لذلك سنلجأ إلى إمكانية نشر الموارد ، والتي تهدف إلى حل المشاكل المذكورة أعلاه.
قبل أن نواصل العمل ، دعنا نصوغ أهدافه ، والتي ستمنحنا إرشادات ستكون مفيدة عند تحليل ملف بيان النشر. لذلك هنا هو ما نحتاج إليه:
- نريد أن نكون قادرين على إنشاء اثنين من الموقد على أساس حاوية واحدة
rinormaloku/sentiment-analysis-frontend . - نحتاج إلى نظام نشر تطبيق يتيح له العمل دون مقاطعة عند تحديثه.
- نريد تعيين تسمية
app: sa-frontend ، والتي ستسمح لخدمة sa-frontend-lb باكتشاف هذه الأجزاء.
سنقوم الآن بالتعبير عن هذه المتطلبات كتوصيف لمورد النشر.
▍ وصف النشر
فيما يلي وصف YAML لمورد نوع النشر ، والذي تم إنشاؤه مع مراعاة متطلبات النظام أعلاه:
apiVersion: extensions/v1beta1 kind: Deployment # 1 metadata: name: sa-frontend spec: replicas: 2 # 2 minReadySeconds: 15 strategy: type: RollingUpdate # 3 rollingUpdate: maxUnavailable: 1 # 4 maxSurge: 1 # 5 template: # 6 metadata: labels: app: sa-frontend # 7 spec: containers: - image: rinormaloku/sentiment-analysis-frontend imagePullPolicy: Always # 8 name: sa-frontend ports: - containerPort: 80
دعنا نحلل هذا الوصف:
Kind : يقول هنا أننا Deployment مورد نوع Deployment .Replicas : خاصية لعنصر مواصفات النشر الذي يحدد عدد الحالات (النسخ المتماثلة) لموقد المراد تشغيلها.Type : يصف الاستراتيجية المستخدمة في هذا النشر عند التبديل من الإصدار الحالي إلى إصدار جديد. توفر إستراتيجية RollingUpdate تعطل نظام صفر أثناء الترقيات.MaxUnavailable : هذه خاصية لكائن RollingUpdate ، الذي يحدد الحد الأقصى لعدد الموقد غير المتاح (مقارنة بعدد الموقد المطلوب) عند إجراء تحديث نظام متسلسل. في نشرنا ، والذي يعني وجود نسختين متماثلتين ، تشير قيمة هذه الخاصية إلى أنه بعد الانتهاء من جراب واحد ، سيتم تنفيذ واحد آخر ، مما يجعل التطبيق متاحًا أثناء التحديث.MaxSurge : هذه خاصية لكائن RollingUpdate الذي يصف الحد الأقصى لعدد RollingUpdate التي يمكن إضافتها إلى نشر (مقارنة بعدد معين من الموقد). في حالتنا ، فإن قيمتها ، 1 ، تعني أنه عند التبديل إلى إصدار جديد من البرنامج ، يمكننا إضافة مجموعة فرعية أخرى إلى المجموعة ، الأمر الذي سيؤدي إلى حقيقة أنه يمكن إطلاق ما يصل إلى ثلاث قلوب في وقت واحد.Template : يحدد هذا الكائن قالب الموقد الذي سيستخدمه مورد Deployment الموضح لإنشاء مداخل جديدة. من المحتمل أن تجد هذا الإعداد مألوفًا.app: sa-frontend : تسمية لموقد خلق وفقا لنمط معين.ImagePullPolicy : يحدد ترتيب العمل مع الصور. في حالتنا ، يتم تعيين هذه الخاصية على " Always ، أي أنه أثناء كل عملية نشر ، سيتم تنزيل الصورة المقابلة من المستودع.
بعد فحص كل هذا ، دعنا ننتقل إلى الممارسة. تشغيل النشر:
kubectl apply -f sa-frontend-deployment.yaml deployment "sa-frontend" created
تحقق من حالة النظام:
kubectl get pods NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 2d sa-frontend-5d5987746c-ml6m4 1/1 Running 0 1m sa-frontend-5d5987746c-mzsgg 1/1 Running 0 1m sa-frontend2 1/1 Running 0 2d
كما ترون ، لدينا الآن 4 قرون. تم إنشاء اثنين منهم باستخدام مورد النشر ، واثنان آخران هما تلك التي أنشأناها بأنفسنا. يمكنك الآن إزالة تلك البرامج التي أنشأناها باستخدام أوامر من النوع التالي:
kubectl delete pod <pod-name>
بالمناسبة ، إليك مهمة للعمل المستقل. احذف أحد الموقد الذي تم إنشاؤه باستخدام مورد النشر ومراقبة النظام. فكر في أسباب ما يحدث قبل القراءة.
عند حذف أحد الموقد ، يتعلم مورد النشر أن الحالة الحالية للنظام (1 فرعية) تختلف عن الحالة المطلوبة (2 فرعية) ، لذلك يتم تشغيل فرع آخر.
ما هو استخدام موارد النشر ، إلى جانب حقيقة أنه عند استخدامها ، يتم الحفاظ على النظام في الحالة الصحيحة؟ النظر في نقاط القوة في هذه الموارد.
ments أداء عمليات النشر مع تعطل النظام صفر
افترض أن مدير المنتج يأتي إلينا ويبلغنا أن العميل الذي أنشأنا هذا المنتج يريد زرًا أخضر في تطبيق العميل. يقوم المطورون بتنفيذ هذا المطلب
rinormaloku/sentiment-analysis-frontend:green الشيء الوحيد الذي نحتاجه منهم - حاوية صور تسمى
rinormaloku/sentiment-analysis-frontend:green . الآن يأتي وقتنا. نحن ، فريق DevOps ، نحتاج إلى نشر النظام المحدّث وضمان عدم تعطل العمل. الآن دعونا نرى ما إذا كانت الجهود المبذولة لتطوير وتكوين مورد النشر لها ما يبررها.
قم بتحرير ملف
sa-frontend-deployment-green.yaml ،
sa-frontend-deployment-green.yaml اسم حاوية الصورة باسم جديد ، باستخدام
rinormaloku/sentiment-analysis-frontend:green ، ثم احفظ هذا الملف كـ
sa-frontend-deployment-green.yaml وقم بتنفيذ الأمر التالي:
kubectl apply -f sa-frontend-deployment-green.yaml --record deployment "sa-frontend" configured
تحقق من حالة النظام باستخدام الأمر التالي:
kubectl rollout status deployment sa-frontend Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 of 2 updated replicas are available... deployment "sa-frontend" successfully rolled out
وفقًا للبيانات المعروضة استجابة لهذا الأمر ، يمكننا أن نستنتج أن نشر التحديث كان ناجحًا. أثناء الترقية ، تم استبدال النسخ المتماثلة القديمة ، واحدة تلو الأخرى ، بنسخ جديدة. , , , . , , .
, , :
minikube service sa-frontend-lb
, .
, , — .
RollingUpdate
,
kubectl apply -f sa-frontend-deployment-green.yaml --record , Kubernetes , , . , ,
rinormaloku/sentiment-analysis-frontend:green . , , .
RollingUpdate , ,
maxUnavailable: 1 maxSurge: 1 . , Deployment , , , . , , , .
Deployment. , . .
▍
, , . «! ! !», — . . , , :
kubectl rollout history deployment sa-frontend deployments "sa-frontend" REVISION CHANGE-CAUSE 1 <none> 2 kubectl.exe apply --filename=sa-frontend-deployment-green.yaml --record=true
: «, , ?».
«. , ?», — .
, , :
kubectl rollout undo deployment sa-frontend --to-revision=1 deployment "sa-frontend" rolled back
. , .
.
.
!
, . Kubernetes , , . , !
. , .
CHANGE-CAUSE <none> , —
kubectl.exe apply –filename=sa-frontend-deployment-green.yaml –record=true ?
, --
record , .
, , , .
Kubernetes:
Kubernetes, , . , .
.
▍ sa-logic
resource-manifests :
kubectl apply -f sa-logic-deployment.yaml --record deployment "sa-logic" created
sa-logic . Python-.
app: sa-logic .
sa-logic , .
sa-logic-deployment.yaml .
-, , —
sa-logic .
▍ sa-logic
, Service. , Java-,
sa-webapp , , Python-. , , , Python-, . , , , .
, , , , . ,
sa-logic ,
sa-logic .
:
kubectl apply -f service-sa-logic.yaml service "sa-logic" created
, .
sa-logic ,
sa-webapp , , .
sa-webapp .
▍ sa-webapp
, Deployment - . ,
sa-web-app-deployment.yaml , :
- image: rinormaloku/sentiment-analysis-web-app imagePullPolicy: Always name: sa-web-app env: - name: SA_LOGIC_API_URL value: "http://sa-logic" ports: - containerPort: 8080
env ? , , ,
SA_LOGIC_API_URL http://sa-logic . , , . ?
kube-dns.
▍DNS- Kubernetes
Kubernetes ,
kube-dns . DNS-.
kube-dns , DNS- .
,
sa-logic , IP-.
kube-dns IP- .
http://sa-logic IP-.
Deployment
sa-webapp .
▍ sa-webapp
:
kubectl apply -f sa-web-app-deployment.yaml --record deployment "sa-web-app" created
sa-webapp , . React- ,
sa-webapp .
▍ sa-webapp
service-sa-web-app-lb.yaml , , , , . , , :
kubectl apply -f service-sa-web-app-lb.yaml service "sa-web-app-lb" created
. , , . ,
sa-frontend , Java-
sa-webapp ,
http://localhost:8080/sentiment . , ,
sa-webapp , React- , Java-.
, . , — , , .
, :
- IP-
sa-webapp , :
minikube service list
|-------------|----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|----------------------|-----------------------------|
| default | kubernetes | No node port |
| default | sa-frontend-lb | http://192.168.99.100:30708 |
| default | sa-logic | No node port |
| default | sa-web-app-lb | http://192.168.99.100:31691 |
| kube-system | kube-dns | No node port |
| kube-system | kubernetes-dashboard | http://192.168.99.100:30000 |
|-------------|----------------------|-----------------------------| - IP-
sa-frontend/src/App.js . , :
analyzeSentence() { fetch('http://192.168.99.100:31691/sentiment', { /* */}) .then(response => response.json()) .then(data => this.setState(data)); }
- React-,
sa-frontend npm run build . - :
docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend:minikube.
- Docker Hub:
docker push $DOCKER_USER_ID/sentiment-analysis-frontend:minikube
sa-frontend-deployment.yaml , .- :
kubectl apply -f sa-frontend-deployment.yaml
, , , ,
minikube service sa-frontend-lb . , - .
ملخص
Kubernetes , , , , . Kubernetes , , . Kubernetes Supernetes.
, :
- , , React, Java Python.
- Docker, ,
Dockerfile . - , , Docker Hub.
, Kubernetes:
, , Kubernetes.
أعزائي القراء! Kubernetes?
