من السحب إلى الأرض: كيفية إنشاء Kubernetes على مستوى الإنتاج في أي بيئة

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



تحتوي هذه المقالة على توصيات حول إطلاق مجموعة Kubernetes من فئة الإنتاج في مركز بيانات داخل المؤسسة أو موقع طرفي (موقع حافة).
ماذا تعني درجة الإنتاج؟

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

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



تركز هذه المقالة على النشر المحلي لـ Kubernetes على منصة hypervisor أو منصة معدنية عارية ، نظرًا لمحدودية موارد الدعم مقارنة بالزيادة في السحب العامة الرئيسية. ومع ذلك ، قد تكون بعض هذه التوصيات مفيدة للسحابة العامة إذا كانت الميزانية تحد من الموارد المحددة.

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

توضح هذه المقالة نصائح لتحقيق نشر Kubernetes على مستوى الإنتاج ، حتى في المواقف المحدودة الموارد.

مكونات مهمة في مجموعة Kubernetes

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



بشكل عام ، توجد مكونات خادم API ومدير وحدة التحكم والجدولة في العديد من مثيلات العقد على مستوى التحكم (تسمى الرئيسية). عادةً ما تشتمل العقد الرئيسية أيضًا على etcd ، ولكن هناك نصوص كبيرة يسهل الوصول إليها وتتطلب تشغيل etcd على مضيفين مستقلين. يمكن تشغيل المكونات كحاويات ، وبشكل اختياري ، تحت إشراف Kubernetes ، أي تعمل كمداخن ثابتة.

يتم استخدام الحالات الزائدة من هذه المكونات لتوافر كبير. قد تختلف الدلالة والمستوى المطلوب للتكرار.

مكون	الأدوار	عواقب الخسارة	المثيلات الموصى بها
إلخ	يحافظ على حالة جميع كائنات Kubernetes	فقدان كارثي للتخزين. فقدان معظم = Kubernetes يفقد مستوى التحكم ، ويعتمد خادم API على etcd ، ويمكن أن تستمر مكالمات API للقراءة فقط التي لا تحتاج إلى نصاب ، مثل أعباء العمل التي تم إنشاؤها بالفعل ، في العمل.	رقم فردي ، 3+
خادم API	يوفر API للاستخدام الخارجي والداخلي	غير قادر على التوقف ، البدء ، تحديث القرون الجديدة. تعتمد أداة الجدولة ومدير وحدة التحكم على خادم API. تستمر الأحمال إذا كانت لا تعتمد على مكالمات API (المشغلين ، وحدات التحكم المخصصة ، CRD ، إلخ.)	2+
جدولة كوبي	يضع القرون على العقد	لا يمكن وضع القرون أو تحديد أولوياتها أو نقلها فيما بينها.	2+
مدير تحكم kube	يتحكم في العديد من وحدات التحكم	حلقات التحكم الرئيسية المسؤولة عن الدولة تتوقف عن العمل. فواصل التكامل داخل الشجرة لموفر السحابة.	2+
مدير تحكم السحابة (CCM)	تكامل مزود الخدمة السحابية خارج الشجرة	فواصل التكامل مزود سحابة	1
الإضافات (مثل DNS)	مختلفة	مختلفة	يعتمد على الوظيفة الإضافية (مثل 2+ لـ DNS)

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

يستخدم خادم API مثيلات موازن تحميل متعددة لتحقيق قابلية التوسع والتوافر. موازن التحميل هو مكون أساسي للتوافر العالي. يمكن أن تعمل عدة سجلات A لخادم DNS API كبديل في حالة عدم وجود موازن.

يشارك kube-Scheduler و kube-controller-manager في عملية اختيار قائد بدلاً من استخدام موازن تحميل. نظرًا لاستخدام مدير وحدة التحكم في السحاب لأنواع معينة من البنية التحتية للاستضافة ، والتي قد يختلف تنفيذها ، فلن نناقشها - فنحن نشير فقط إلى أنها مكون من مكونات مستوى الإدارة.

يتم إدارة القرون التي تعمل على Kubernetes بواسطة وكيل kubelet. كل مثيل للعامل يدير وكيل kubelet وبيئة تشغيل حاوية متوافقة مع CRI . تم تصميم Kubernetes نفسها للمراقبة والتعافي من فشل عقدة العمال. ولكن بالنسبة لوظائف الحمل الحرجة وإدارة موارد برنامج Hypervisor وعزل الحمل ، يمكن استخدامه لتحسين إمكانية الوصول وزيادة إمكانية التنبؤ بعملهم.

إلخ

إلخ هو التخزين الدائم لجميع كائنات Kubernetes. يجب أن يكون توفر واسترداد مجموعة etcd أولوية قصوى عند نشر Kubernetes بمستوى الإنتاج.

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

الحد الأدنى من التوصيات لاستضافة عقدة نظام المجموعة هو 2 جيجا بايت رام و 8 جيجا بايت SSD. عادةً ما تكون 8 غيغابايت من ذاكرة الوصول العشوائي و 20 غيغابايت من مساحة القرص الثابت كافية. يؤثر أداء القرص على وقت استرداد العقدة بعد الفشل. تحقق من التفاصيل.

في حالات خاصة ، فكر في عدة مجموعات أخرى

بالنسبة لمجموعات Kubernetes الكبيرة جدًا ، فكر في استخدام مجموعة etcd منفصلة لأحداث Kubernetes بحيث لا يؤثر عدد كبير جدًا من الأحداث على خدمة Kubernetes API الأساسية. عند استخدام شبكة Flannel ، يتم حفظ التكوين في etcd ، وقد تختلف متطلبات الإصدار عن Kubernetes. يمكن أن يؤدي ذلك إلى تعقيد النسخ الاحتياطي لـ etcd ، لذلك نوصي باستخدام مجموعة etcd منفصلة خصيصًا للفانيلا.

نشر مضيف واحد

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

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

خيارات النشر لمضيف واحد ، من الأقل ملاءمة للإنتاج إلى معظم

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

نشر المضيف المزدوج

مع وجود مضيفين ، تتشابه مشكلات تخزين etcd مع خيار المضيف المفرد - فأنت بحاجة إلى التكرار. يفضل تشغيل ثلاث نسخ encd. قد يبدو الأمر غير بديهي ، ولكن من الأفضل تركيز جميع العقد وغيرها على مضيف واحد. لن تزيد من الموثوقية بتقسيمها على 2 + 1 بين مضيفين - سيؤدي فقدان العقدة مع معظم حالات التشفير إلى الفشل ، بغض النظر عما إذا كانت أغلبية 2 أو 3. إذا لم تكن المضيفات متشابهة ، ضع مجموعة etcd بأكملها على الأكثر موثوقية.

من المستحسن أن تقوم بتشغيل خوادم API الزائدة ، مجدولات kube ، ومديري kube-controller-manager. يجب مشاركتها بين المضيفين لتقليل مخاطر الفشل في بيئة تشغيل الحاوية ونظام التشغيل والأجهزة.

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

خيارات النشر لمضيفين ، من الأقل ملاءمة للإنتاج إلى الأكثر

اكتب	الخصائص	النتيجة
الحد الأدنى من المعدات	مضيفان ، بدون تخزين فائض. Singleton etcd والمكونات الرئيسية على نفس المضيف.	الخ - نقطة واحدة من الفشل ، لا معنى لتشغيل اثنين على الخدمات الرئيسية الأخرى. تزيد المشاركة بين مضيفين من خطر فشل الطبقة المُدارة. الفائدة المحتملة لعزل الموارد عن طريق تشغيل طبقة مُدارة على مضيف واحد وأحمال عمل التطبيق على أخرى. إذا فُقد التخزين ، فلن يكون هناك استرداد.
تحسين تكرار التخزين	Singleton etcd والمكونات الرئيسية على نفس المضيف ، وتخزين etcd زائدة عن الحاجة.	كحد أدنى ، يمكنك التعافي من فشل جهاز التخزين.
التكرار المدارة المستوى	لا يوجد برنامج hypervisor ، عدة حالات لمكونات المستوى المُدار في القرون الثابتة. كتلة etcd على مضيف واحد ، يتم فصل المكونات الأخرى المُدارة على المستوى.	إن فشل الأجهزة وتحديث البرامج الثابتة ونظام التشغيل وبيئة تشغيل الحاوية على مضيف بدون etcd أقل ضررًا.
إضافة مراقب مراقبة لكلا المضيفين	يتم تشغيل ثلاثة مكوّنات متكررة ذات مستوى مُدار في أجهزة افتراضية ، وما إلى ذلك في مجموعة واحدة على مضيف واحد ، ويتم فصل مكوّنات المستوى المُدار. يمكن أن تتواجد أحمال عمل التطبيق على كلا عقدتي الجهاز الظاهري.	تحسين عزل تحميل التطبيق. تحديثات نظام التشغيل وبيئة تشغيل الحاوية أقل تعطلًا. تصبح الصيانة المجدولة للأجهزة / البرامج الثابتة غير مدمرة إذا كان برنامج مراقبة الأجهزة الافتراضية يدعم ترحيل VM.

النشر إلى ثلاثة مضيفين (أو أكثر)

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

ستتطلب المجموعات الكبيرة جدًا المزيد من الحالات.

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

خيارات النشر لثلاثة مضيفين (أو أكثر) من الأقل ملاءمة للإنتاج إلى أقصى حد

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

تكوين Kubernetes

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

يرتبط استهلاك الموارد على مستوى التحكم بعدد المداخن ومعدل تدفق المداخن. ستستفيد المجموعات الكبيرة جدًا والصغيرة جدًا من طلب kube-apiserver المعدل وإعدادات إبطاء الذاكرة.

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

الأمان

لكل مجموعة Kubernetes مرجع مصدق (CA) جذري. يجب إنشاء وتثبيت شهادات مدير وحدة التحكم ، وخادم API ، والجدولة ، وعميل kubelet ، و kube-proxy ، والمسؤول. إذا كنت تستخدم أداة التثبيت أو التوزيع ، فقد لا تضطر إلى التعامل معها بنفسك. يتم وصف العملية اليدوية هنا . يجب أن تكون مستعدًا لإعادة تثبيت الشهادات إذا قمت بتوسيع أو استبدال العقد.

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

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

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

التوصيات:

• تعزيز إعدادات الأمان الافتراضية لمكونات المستوى المُدار (على سبيل المثال ، حظر عقد العامل ) ؛
• استخدام سياسة سلامة الموقد ؛
• فكر في تكامل NetworkPolicy المتاح لحل شبكتك ، بما في ذلك التتبع والمراقبة واستكشاف الأخطاء وإصلاحها ؛
• استخدام RBAC لاتخاذ قرارات الترخيص ؛
• فكر في الأمان المادي ، خاصة عند النشر إلى المواقع الطرفية أو البعيدة التي قد يتم تجاهلها. إضافة تشفير التخزين للحد من نتائج سرقة الجهاز ، والحماية من توصيل الأجهزة الضارة ، مثل مفاتيح USB ؛
• حماية بيانات اعتماد النص لموفر السحابة (مفاتيح الوصول والرموز المميزة وكلمات المرور وما إلى ذلك).

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

التعافي من الكوارث والنسخ الاحتياطي



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

جزء هام من نشر الإنتاج هو توقع حدوث انتعاش في المستقبل.

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

من بين عناصر التعافي من الكوارث ، والنسخ الاحتياطية (وربما النسخ المتماثلة) ، وعمليات الاستبدال ، والعملية المخططة ، والأشخاص الذين سيقومون بهذه العملية ، والتدريب المنتظم ، من الجدير بالذكر. يمكن استخدام تدريبات ومبادئ الاختبار المتكرر في Chaos Engineering لاختبار جاهزيتك.

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

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

etcd etcd . Kubernetes . , Kubernetes.

, Kubernetes etcd , - . , .

etcd. , , , , /. , . :

• : CA, API Server, Apiserver-kubelet-client, ServiceAccount, “Front proxy”, Front proxy;
• DNS;
• IP/;
• ;
• kubeconfig;
• LDAP ;
• .

Anti-affinity . , . , Kubernetes , . , , - . , .

stateful-, — Kubernetes (, SQL ). , , Kubernetes, roadmap feature request , , , Container Storage Interface (CSI). , - , , . , Kubernetes , , , Kubernetes .

stateful- (, Cassandra) , , . - Kubernetes ( -) .



( ) , , . , , .

, (, Ansible , BOSH , Chef , Juju , kubeadm , Puppet .). , . , , , , , , . , Git, .



, , — . 2 , — . — , .





— . - , Airbus A320 — . , . , .

, . , , , . Kubernetes , - , , (, FedEx, Amazon).

production-grade Kubernetes . . , , , , . , (, Kubernetes self-hosting، وليس المواقد الثابتة). ربما يجب مناقشتها في المقالات التالية ، إذا كان هناك اهتمام كاف. بالإضافة إلى ذلك ، نظرًا للسرعة العالية لتحسين Kubernetes ، إذا وجد محرك البحث الخاص بك هذه المقالة بعد عام 2019 ، فقد تكون بعض مواده قديمة جدًا بالفعل.

النهاية

كما هو الحال دائمًا ، نحن في انتظار أسئلتك وتعليقاتك هنا ، ويمكنك الذهاب إلى اليوم المفتوح لـ Alexander Titov .