مرحبا، اسمي ديمتري كراسنوف. منذ أكثر من خمس سنوات، كنت أدير مجموعات Kubernetes وأقوم ببناء بنيات معقدة للخدمات الصغيرة. في بداية هذا العام، أطلقنا خدمة لإدارة مجموعات Kubernetes استنادًا إلى Containerum. وأغتنم هذه الفرصة، سأخبرك ما هو Kubernetes وكيف يختلف التكامل مع البائع عن المصدر المفتوح.
بالنسبة للمبتدئين ، ما هو . هذا نظام لإدارة الحاويات على عدد كبير من المضيفين. من اليونانية، بالمناسبة، يتم ترجمتها على أنها "الطيار" أو "قائد الدفة". تم تطويره في الأصل بواسطة Google ثم تم التبرع به كمساهمة تقنية لمؤسسة Cloud Native Computing Foundation، وهي منظمة دولية غير ربحية تجمع بين المطورين الرائدين في العالم والمستخدمين النهائيين وموفري تكنولوجيا الحاويات.
إدارة عدد كبير من الحاويات
الآن دعونا نتعرف على نوع هذه الحاويات. هذا تطبيق ببيئته بأكملها - بشكل أساسي المكتبات التي يعتمد عليها البرنامج. يتم تجميع كل هذا في الأرشيف ويتم تقديمه في شكل صورة يمكن تشغيلها بغض النظر عن نظام التشغيل واختبارها والمزيد. ولكن هناك مشكلة - إدارة الحاويات على عدد كبير من المضيفين أمر صعب للغاية. ولهذا السبب تم إنشاء Kubernetes.
تمثل صورة الحاوية تطبيقًا بالإضافة إلى تبعياته. يقع التطبيق وتبعياته وصورة نظام ملفات نظام التشغيل في أجزاء مختلفة من الصورة، تسمى الطبقات. يمكن إعادة استخدام الطبقات لحاويات مختلفة. على سبيل المثال، قد تستخدم جميع التطبيقات في الشركة طبقة Ubuntu الأساسية. عند تشغيل الحاويات، ليست هناك حاجة لتخزين نسخ متعددة من طبقة أساسية واحدة على المضيف. يتيح لك ذلك تحسين تخزين الصور وتسليمها.
عندما نريد تشغيل تطبيق ما من حاوية، يتم تركيب الطبقات الضرورية على بعضها البعض ويتم تشكيل نظام ملفات متراكب. يتم وضع طبقة تسجيل في الأعلى، والتي تتم إزالتها عندما تتوقف الحاوية. وهذا يضمن أنه عند تشغيل الحاوية، سيكون للتطبيق دائمًا نفس البيئة، والتي لا يمكن تغييرها. وهذا يضمن إمكانية تكرار نتائج البيئة على أنظمة تشغيل مضيفة مختلفة. سواء كان Ubuntu أو CentOS، ستكون البيئة دائمًا هي نفسها. بالإضافة إلى ذلك، يتم عزل الحاوية عن المضيف باستخدام آليات مدمجة في نواة Linux. لا ترى التطبيقات الموجودة في الحاوية الملفات وعمليات المضيف والحاويات المجاورة. يوفر عزل التطبيقات عن نظام التشغيل المضيف طبقة إضافية من الأمان.
هناك العديد من الأدوات المتاحة لإدارة الحاويات على المضيف. الأكثر شعبية منهم هو دوكر. يسمح لك بتوفير دورة الحياة الكاملة للحاويات. ومع ذلك، فهو يعمل فقط على مضيف واحد. إذا كنت بحاجة إلى إدارة الحاويات عبر مضيفين متعددين، فيمكن لـ Docker أن يجعل حياة المهندسين جحيمًا. ولهذا السبب تم إنشاء Kubernetes.
يرجع الطلب على Kubernetes على وجه التحديد إلى القدرة على إدارة مجموعات الحاويات على مضيفين متعددين كنوع من الكيان الفردي. توفر شعبية النظام الفرصة لبناء DevOps أو عمليات التطوير، حيث يتم استخدام Kubernetes لتشغيل عمليات DevOps ذاتها.
الشكل 1. تمثيل تخطيطي لكيفية عمل Kubernetes
أتمتة كاملة
DevOps هو في الأساس أتمتة عملية التطوير. بشكل تقريبي، يكتب المطورون التعليمات البرمجية التي يتم تحميلها إلى المستودع. بعد ذلك، يمكن جمع هذا الرمز تلقائيًا على الفور في حاوية تحتوي على جميع المكتبات، واختباره و"طرحه" إلى المرحلة التالية - التدريج، ثم على الفور إلى الإنتاج.
يتيح لك DevOps، جنبًا إلى جنب مع Kubernetes، أتمتة هذه العملية بحيث تتم دون أي مشاركة تقريبًا من المطورين أنفسهم. ونتيجة لهذا، يكون البناء أسرع بشكل ملحوظ، حيث لا يتعين على المطور القيام بذلك على جهاز الكمبيوتر الخاص به - فهو ببساطة يكتب جزءًا من التعليمات البرمجية، ويدفع الكود إلى المستودع، وبعد ذلك يتم تشغيل خط الأنابيب، والذي يمكن أن يتضمن العملية من البناء والاختبار والطرح. ويحدث هذا مع كل التزام، لذلك يتم الاختبار بشكل مستمر.
في الوقت نفسه، يسمح لك استخدام الحاوية بالتأكد من أن بيئة هذا البرنامج بأكملها سيتم إطلاقها في الإنتاج تمامًا بالشكل الذي تم اختباره به. وهذا يعني أنه لن تكون هناك مشاكل مثل "كانت هناك بعض الإصدارات في الاختبار، والبعض الآخر في الإنتاج، ولكن عندما قمنا بتثبيتها، سقط كل شيء". ومنذ اليوم لدينا اتجاه نحو بنية الخدمات الصغيرة، فبدلاً من تطبيق واحد ضخم يوجد مئات من التطبيقات الصغيرة، من أجل إدارتها يدويًا، ستكون هناك حاجة إلى عدد كبير من الموظفين. لهذا السبب نستخدم Kubernetes.
الايجابيات، الايجابيات، الايجابيات
إذا تحدثنا عن مزايا Kubernetes كمنصة، فهي تتمتع بمزايا كبيرة من وجهة نظر إدارة بنية الخدمات الصغيرة.
- إدارة النسخ المتماثلة المتعددة. الشيء الأكثر أهمية هو إدارة الحاويات عبر مضيفين متعددين. والأهم من ذلك، إدارة النسخ المتماثلة المتعددة للتطبيقات في الحاويات ككيان واحد. وبفضل هذا، لا داعي للقلق بشأن كل حاوية على حدة. إذا تعطلت إحدى الحاويات، سيرى Kubernetes ذلك ويعيد تشغيله مرة أخرى.
- شبكة الكتلة. لدى Kubernetes أيضًا ما يسمى بشبكة الكتلة مع مساحة العنوان الخاصة بها. بفضل هذا، كل جراب له عنوانه الخاص. تُفهم القاعدة الفرعية على أنها الحد الأدنى من الوحدة الهيكلية للمجموعة التي يتم فيها إطلاق الحاويات مباشرة. بالإضافة إلى ذلك، يتمتع Kubernetes بوظيفة تجمع بين موازن التحميل واكتشاف الخدمة. يتيح لك ذلك التخلص من إدارة عنوان IP اليدوية وتفويض هذه المهمة إلى Kubernetes. وستساعد عمليات التحقق من الصحة التلقائية في اكتشاف المشكلات وإعادة توجيه حركة المرور إلى حجرات العمل.
- إدارة التكوين. عند إدارة عدد كبير من التطبيقات، يصبح من الصعب إدارة تكوين التطبيق. ولهذا الغرض، يمتلك Kubernetes موارد ConfigMap خاصة. إنها تسمح لك بتخزين التكوينات مركزيًا وعرضها على القرون عند تشغيل التطبيقات. تسمح لنا هذه الآلية بضمان اتساق التكوين في ما لا يقل عن عشرة أو مائة نسخة متماثلة للتطبيق.
- الكميات المستمرة. الحاويات غير قابلة للتغيير بطبيعتها، وعندما يتم إيقاف الحاوية، سيتم تدمير جميع البيانات المكتوبة في نظام الملفات. لكن بعض التطبيقات تقوم بتخزين البيانات مباشرة على القرص. لحل هذه المشكلة، يحتوي Kubernetes على وظيفة إدارة تخزين القرص - وحدات التخزين الثابتة. تستخدم هذه الآلية وحدة تخزين خارجية للبيانات ويمكنها نقل التخزين الدائم أو الكتلة أو الملف إلى حاويات. يتيح لك هذا الحل تخزين البيانات بشكل منفصل عن العمال، مما يحفظها في حالة تعطل هؤلاء العمال أنفسهم.
- موازن التحميل. على الرغم من أننا في Kubernetes ندير كيانات مجردة مثل Deployment وStatefulSet وما إلى ذلك، إلا أن الحاويات تعمل في النهاية على أجهزة افتراضية عادية أو خوادم أجهزة. فهي ليست مثالية ويمكن أن تسقط في أي وقت. سيرى Kubernetes هذا ويعيد توجيه حركة المرور الداخلية إلى النسخ المتماثلة الأخرى. ولكن ماذا تفعل مع حركة المرور القادمة من الخارج؟ إذا قمت ببساطة بتوجيه حركة المرور إلى أحد العاملين، إذا تعطلت، فستصبح الخدمة غير متاحة. لحل هذه المشكلة، لدى Kubernetes خدمات مثل Load Balancer. وهي مصممة لتكوين موازن سحابي خارجي تلقائيًا لجميع العاملين في المجموعة. يقوم هذا الموازن الخارجي بتوجيه حركة المرور الخارجية إلى العمال ومراقبة حالتهم بنفسه. في حالة عدم توفر عامل واحد أو أكثر، تتم إعادة توجيه حركة المرور إلى الآخرين. يتيح لك ذلك إنشاء خدمات متاحة للغاية باستخدام Kubernetes.
يعمل Kubernetes بشكل أفضل عند تشغيل بنيات الخدمات الصغيرة. من الممكن تطبيق النظام في العمارة الكلاسيكية، لكنه لا معنى له. إذا كان التطبيق لا يمكن تشغيله على نسخ متماثلة متعددة، فما الفرق الذي يحدثه - في Kubernetes أم لا؟
مفتوح المصدر Kubernetes
يعد Kubernetes مفتوح المصدر أمرًا رائعًا: لقد قمت بتثبيته وهو يعمل. يمكنك نشره على خوادم الأجهزة الخاصة بك، وعلى البنية التحتية الخاصة بك، وتثبيت البرامج الرئيسية والعمال التي سيتم تشغيل جميع التطبيقات عليها. والأهم من ذلك أن كل هذا مجاني. ومع ذلك، هناك الفروق الدقيقة.
- الأول هو الطلب على المعرفة والخبرة لدى الإداريين والمهندسين الذين سينشرون ويدعمون كل هذا. وبما أن العميل يحصل على حرية العمل الكاملة في المجموعة، فإنه يتحمل مسؤولية أداء المجموعة بنفسه. ومن السهل جدًا كسر كل شيء هنا.
- والثاني هو عدم وجود التكامل. إذا قمت بتشغيل Kubernetes بدون منصة افتراضية شائعة، فلن تحصل على جميع مزايا البرنامج. مثل استخدام وحدات التخزين الثابتة وخدمات موازن التحميل.
الشكل 2. بنية K8s
Kubernetes من البائع
يوفر التكامل مع موفر السحابة خيارين:
- أولاً، يمكن لأي شخص ببساطة النقر فوق الزر "إنشاء مجموعة" والحصول على مجموعة تم تكوينها بالفعل وجاهزة للاستخدام.
- ثانيًا، يقوم البائع بنفسه بتثبيت المجموعة وإعداد التكامل مع السحابة.
كيف يحدث هنا. يحدد المهندس الذي يبدأ المجموعة عدد العمال الذين يحتاجهم وبأي معلمات (على سبيل المثال، 5 عمال، كل منهم يحتوي على 10 وحدات معالجة مركزية، و16 جيجابايت من ذاكرة الوصول العشوائي، وعلى سبيل المثال، 100 جيجابايت من القرص). وبعد ذلك يتمكن من الوصول إلى المجموعة المشكلة بالفعل. في هذه الحالة، يتم نقل العمال الذين تم إطلاق الحمل عليهم بالكامل إلى العميل، ولكن يظل مستوى الإدارة بالكامل تحت مسؤولية البائع (إذا تم تقديم الخدمة وفقًا لنموذج الخدمة المُدارة).
ومع ذلك، فإن هذا المخطط له عيوبه. نظرًا لحقيقة أن مستوى الإدارة يظل مع البائع، فإن البائع لا يمنح الوصول الكامل إلى العميل، وهذا يقلل من المرونة في العمل مع Kubernetes. يحدث أحيانًا أن يرغب العميل في إضافة بعض الوظائف المحددة إلى Kubernetes، على سبيل المثال، المصادقة عبر LDAP، لكن تكوين مستوى الإدارة لا يسمح بذلك.
الشكل 3. مثال على مجموعة Kubernetes من موفر السحابة
ماذا تختار: مفتوح المصدر أو بائع
إذًا، هل Kubernetes مفتوح المصدر أم خاص بالمورد؟ إذا أخذنا Kubernetes مفتوح المصدر، فسيفعل المستخدم به ما يريده. ولكن هناك فرصة كبيرة لإطلاق النار على قدمك. يكون الأمر أكثر صعوبة مع البائع، لأنه يتم التفكير في كل شيء وتكوينه للشركة. أكبر عيب في Kubernetes مفتوح المصدر هو الحاجة إلى المتخصصين. مع خيار البائع، تتحرر الشركة من هذا الصداع، ولكن سيتعين عليها أن تقرر ما إذا كانت ستدفع للمتخصصين أو البائع.
حسنًا، الإيجابيات واضحة، والسلبيات معروفة أيضًا. هناك شيء واحد ثابت: يقوم Kubernetes بحل الكثير من المشكلات من خلال أتمتة إدارة العديد من الحاويات. وأيهما يختار، مفتوح المصدر أم البائع - الجميع يتخذ قراره الخاص.
تم إعداد المقال بواسطة ديمتري كراسنوف، المهندس الرئيسي لخدمة Containerum لموفر #CloudMTS
المصدر: www.habr.com