مرحبا بالجميع!
في هذه المقالة ، قررنا التكهن قليلاً حول متى ولماذا تحتاج الشركات إلى Kubernetes. ما مدى صعوبة تكنولوجيا الدخول ، ومدى السرعة وكيف ستؤتي ثمارها. هل يستحق ذلك وما يهدده كل شيء. نحن لا نضع لأنفسنا مهمة كتابة مراجعة فنية متعمقة ، يوجد العديد منها ، ولكن في المواد التالية سنشارك بالتأكيد أفضل ممارساتنا فيما يتعلق ببنية التطبيق والاستقرار تحت Kubernetes. الآن نحن نركز على ما إذا كانت اللعبة تستحق الشمعة وماذا نحصل على مخرج.
حان الوقت للسوق - سرعة تحديث التحديثات للسوق - أصبح اليوم عاملاً رئيسيًا في فعالية حلول تكنولوجيا المعلومات. يحتاج المنتج إلى التحسين كل يوم: إضافة وظائف ووحدات جديدة إليه ، والحفاظ على الوثائق والنصوص في حالة ممتازة. في الوقت نفسه ، يجب أن تعمل الأنظمة عبر الإنترنت بسلاسة وأن يتم تحديثها دون التأثير على المستخدمين.
حراس التحديث المستمر غير الواضح هو الخدمات الدقيقة والحاويات والبنية التحتية لتنسيقها - Kubernetes (أو K8S ، يطلق عليه في الدوائر الفنية).
كيف يوفر Kubernetes تحديثات مستمرة للنظام؟
المهمة الرئيسية عند تحديث حل تكنولوجيا المعلومات هو ضمان تشغيله الصحيح بعد النقل من بيئة التطوير إلى منصة المنتج. وأيضا في التشغيل السلس للنظام في وقت تحديث المنتج.
تكمن المشكلة في حقيقة أن إعدادات بيئة التطوير والخوادم الصناعية لا تتطابق في كثير من الأحيان. تقوم الحاويات بإصلاح هذه المشكلة من خلال دمج جميع مكونات البرنامج في حزمة واحدة معزولة عن البيئة الخارجية. هذا يسمح لك بنشر التطبيقات بسرعة وموثوقية على أي بنية أساسية ويسهل تحديث قاعدة التعليمات البرمجية للنظام.
دون أن يلاحظها المستخدمون ، تحدث التحديثات من خلال تكرار الحاويات وإعادة التوجيه التسلسلي للمستخدمين من واحد إلى آخر. لإدارة الحاويات (الأوركسترا) نستخدم Kuberenetes. في النهاية ، فإنه يسهل إدارة الحلول ونشرها وترقيتها ومراقبة الأداء وتصحيح الأخطاء في حالة حدوث فشل.
عندما تحتاج شركة Kubernetes
حان الوقت للشركات للتفكير في التحول إلى منصة Kubernetes عندما:
- يعد المشروع أو النظام أداة مهمة للأعمال التجارية ، وبالتالي يجب أن يتحمل الأخطاء ويستمر في العمل ، حتى إذا كان جزء ما معطلاً.
- يتم تحميل النظام بشكل كبير ، مع الحفاظ على التحديثات أو التحسينات السريعة.
- يحتاج النظام بشكل دوري إلى سعة إضافية. ويحتاجها بسرعة.
- ومع كل هذا ، يتم قياس سرعة إيصال التحديثات إلى البيئة الصناعية بالأسابيع أو الأشهر أو السنوات ، ولكن ليس أبدًا - ساعات أو أيام.
تحتاج أيضًا إلى Kubernetes كأداة لأتمتة وتوحيد العمل مع الحل ، إذا كان بالإضافة إلى ما سبق:
- لا يوجد عزل بين أنظمة تكنولوجيا المعلومات في الشركة ويمكن لكل منها التأثير على الآخر.
- إذا كنت بحاجة إلى كتابة برنامج نصي منفصل في كل مرة للتواصل مع معلمات الخادم الذي يتم نشر النظام عليه ، أي أنه يمكنك قياس هذه العملية يدويًا فقط.
- هناك أشخاص رئيسيون في فريق التطوير - حاملي "المعرفة السرية" حول المشروع أو النظام ، ويبدو أنهم فريدون ولا يمكن تعويضهم.
بشكل أساسي ، يعد التحول إلى Kubernetes أمرًا ضروريًا للشركات التي تحتاج إلى دعم أنظمة المعلومات عبر الإنترنت 24/7.
لماذا Kubernetes؟
Kubernetes ليست البديل الوحيد للتكامل والنشر المستمر (CI / CD). لكن Kubernetes هي التي أصبحت معيار الصناعة لإدارة الأنظمة التي تتطلب توفرًا كبيرًا.
بالنسبة لنا كمطور ، فإن الحجج الحاسمة لصالح Kubernetes هي التالية:
- تركز المنصة على التطبيقات ، وليس البنية التحتية.
- Kubernetes مناسب للعمل مع مركز بيانات واحد ، وكذلك مع عدة مراكز موزعة في مدن مختلفة.
- دعم حل سهل من خلال توثيق واضح ومجتمع نشط.
- تكوين مرن للتطبيقات المختلفة ، وتوزيع حركة المرور بشكل آمن.
- دعم حاوية عامل الميناء.
ما هي فوائد أعمال Kubernetes؟
- التكوين المرن وعملية التحديث الآلي
أنت بنفسك تحدد أي جزء من النظام يتم وضعه في التشغيل التجاري. يسمح لك Kubernetes بعمل دورة إطلاق قصيرة. تتم جميع العمليات تلقائيًا - من التعليمات البرمجية المصدر للنظام إلى الإصدار في بيئة المنتج - تلقائيًا. لا تحتاج إلى فريق من المهندسين لجعل النظام يعمل. لا تؤثر التحديثات الحالية على أداء النظام ويمكن تنفيذها في أي وقت مناسب للمطورين. - وضع وتوسيع نطاق النظام
يمكن وضع النظام على حد سواء على القوة الحاسوبية للعميل (أو في مركز البيانات) ، وفي أي مزود سحابة ، على سبيل المثال ، أمازون أو أزور. يمكن تحقيق أي مستوى من الأداء والتسامح مع الخطأ بسهولة عن طريق تحجيم الكتلة. - التقييس والتوثيق الذاتي
لا يتطلب الحل تعليمات. يتم التوثيق الذاتي ويتم تعبئته تلقائيًا على الفور في وحدة الاستخدام - الحاوية. نحن نصف التكوين في Kubernetes كخطة / رسم تخطيطي. نحن لا نكتب نصوصا تحضير البيئة ، كما كانت قبل Kubernetes. بدلاً من ذلك ، ننتقل إلى معلومات Kubernetes (رسم تخطيطي) حول كيفية عمل الحل. وهو نفسه ينفذ هذا المخطط.
يكتب المطورون الآن طلبًا للعمل في حاوية. يقوم مهندسو DevOps بكتابة رسم تخطيطي لكيفية عمل التطبيق في حاوية ، وتقوم Kubernetes نفسها بمهام بناء حل.
يتم توحيد تكنولوجيا Kubernetes. سيكون من السهل عليك تدريب موظف جديد في نظام الإصدار الخاص بك أو نقل النظام إلى مقاول جديد.
وصف التكوين النهائي الذي يقوم Kubernetes بإنشائه هو أيضًا وثائق النظام. من الأسماء ، يتضح على الفور ما هي المعلمات التي تم تكوينها والغرض منها.
ونتيجة لذلك ، تعمل منصة Kubernetes ككل على تعميم الإصدارات والتحديثات وإصدار التطبيق.
- اختبار حي غير مؤلم
لقد تغيرت عملية اختبار الحل. يمكن للمطورين ، عند الطلب ، إنشاء بيئات مماثلة لبيئات المنتج للاختبار الآلي. وتساعد السجلات العامة لكيفية عمل التطبيق وكيف يعمل Kubernetes مع التطبيق على استكشاف المشكلات والعثور على الأخطاء بشكل أسرع.
ما يتطلبه انتقال الأعمال إلى Kubernetes
Kubernetes نفسها لن تكون سوى جزء صغير من نظامك الجديد. يجب أن تكون على استعداد لأن Kubernetes كأداة لتوحيد دورة التطوير بأكملها وتحديث التطبيقات ونشرها سيترتب عليه تغيير في كل شيء في وقت الانتقال: هندسة البرمجيات وعملية التطوير وصيانة البنية التحتية.
- هندسة الحلول
من وجهة نظر المنتج ، لا يكون الانتقال ممكنًا إلا إذا تم تنفيذ النظام أو ترقيته إلى بنية خدمات صغيرة تستند إلى الخدمات التي يمكن تعبئتها في حاويات (خدمات عديمة الحالة). - عملية التطوير
من وجهة نظر عملية التنمية ، ينطوي التحول في المقام الأول على تغيير في التفكير. يتم استبعاد أي تحسينات ظرفية و "عكازات" تمت إضافتها في اللحظة الأخيرة تمامًا. يمكن لمطور حلول تكنولوجيا المعلومات العمل كفريق واحد فقط ، والذي يصنع في البداية منتجًا تم اختباره في البداية ودعمه وتعبئته وتحلله. يجب بناء كل شيء بشكل منطقي من السطر الأول من التعليمات البرمجية إلى العملية. - عملية التحديث
حتى في مرحلة تطوير بنية التطبيق ، تحتاج إلى التفكير في كيفية تحديث الحل دون توقف. وفهم على الفور كيف ستقوم بتحديث قاعدة البيانات ، API ، كيف يكون من المنطقي دعم العديد من إصدارات التطبيق ، مع الأخذ في الاعتبار حقيقة أن الأشخاص يعملون مع النظام أثناء التحديث ويمكن أن يقعوا في إصدارات مختلفة.
وهناك تحول آخر في التفكير مرتبط بحقيقة أنه عند التبديل إلى Kubernetes ، تبدأ البنية التحتية في العمل في وضع القراءة فقط ، ولتحديث النظام ، تحتاج إلى إنشاء إصدارات جديدة من صور التطبيق وإخبار Kubernetes باستخدام الإصدار الجديد ، وستقوم لاحقًا بإيقاف تشغيل الإصدار القديم و سيحذف نفسه.
بحيث لا يمكن تجنب تحسينات النظام والتغيرات في تكنولوجيا العمل. لن يكون الانتقال سريعًا. لكنك ستحتاج إلى تغيير النموذج مرة واحدة فقط.
الحالة. كيف قمنا بنقل نظام الخدمات الصغيرة إلى Kubernetes
نعمل في بيئة منتج حلاً عالي التحميل يعتمد على بنية الخدمات الصغيرة ، التي تنقل أكثر من 300 ألف معاملة في اليوم ، وفي أوقات الذروة - 60-80 ألف في الساعة. نقوم بتحديث المنتج بانتظام ، وهناك أيضًا إصدارات أكثر إلحاحًا كانت مطلوبة سابقًا لتعليق النظام أو جزء من وظائفه لفترة من الوقت.
ذهبنا إلى بيئة البقالة بدون K8S ، لكننا طورنا النظام في البداية بعين. استغرق الأمر 6 أسابيع لترجمة الحل إلى Kubernetes. انتقلنا في الاتجاهات التالية:
1) إنشاء خط أنابيب النشر
أ. تكوين خط الأنابيب للتجميع والاختبار وتحديث التطبيق المستمر (CI / CD) في بيئات الاختبار.
ب. قم بإعداد تحديثات مستمرة في بيئة صناعية.
ج. إعداد وتكوين البيئة في أقرب مكان ممكن من البيئة الصناعية (إعداد مسبق). نشرنا واختبرنا المجموعة بجوار الأجهزة الافتراضية الحالية.
د. وضع خطة للهجرة إلى بيئة صناعية.
لذا ، يبدو أن كل شيء بسيط ، لدينا خط أنابيب CI / CD لجميع البيئات ويمكنك التبديل ، ولكن من السابق لأوانه!
2) اختيار تكوين الكتلة
أمضينا أسبوعين في اختيار التكوين الأكثر استقرارًا لمكونات وإصدارات مجموعة Kubernetes: نظام التشغيل + Docker + Kubernetes.
اختبرنا 3 تكوينات مختلفة لأنظمة التشغيل (أحدث إصدارات Ubuntu و CentOS و Oracle Linux). في كل نظام تشغيل ، قمنا بفحص نسختين مختلفتين من Docker و Kubernetes - الإصدار الذي تم تسليمه في أحدث إصدارات حزم نظام التشغيل القياسية ، وأحدث إصدار من الشركة المصنعة. ونتيجة لذلك ، أظهرت التكوينات من التوزيع القياسي لـ Oracle Linux أكبر قدر من الاستقرار ، واستقرنا عليها.
3) تكوين إعدادات الحاوية
لقد أمضينا المزيد من الوقت في ضبط معلمات الحاوية - قمنا بإعداد متطلبات الذاكرة والقرص والعمليات.
وفقط بعد أن فعلنا كل هذا واختبرنا معلمات مختلفة لأداء النظام (الثبات ، والتسامح مع الأخطاء ، وغيرها) في الوضع الأولي تحت الأحمال القريبة من المعارك ، وعمل النظام بثبات ، انتقلنا إلى المرحلة النهائية - الهجرة.
ثم كان كل شيء بسيطًا.
يوم ج. الهجرة
بالنسبة للترحيل القتالي ، اخترنا الوقت بأقل حمل للنظام: الحد الأدنى لعدد المستخدمين وغياب الحمل الزائد وفقًا لجدول الأعمال الداخلية لخوارزميات النظام.
كان توقف النظام حوالي ساعة ولم يؤثر عمليا على المستخدمين. تتألف عملية الترحيل نفسها من تبديل المستخدمين من نظام إلى آخر وملاحظة أن كل شيء سار على ما يرام.
الحياة مع Kubernetes
الآن لا تؤثر عملية التحديث على أداء النظام ، ويمكن إجراؤها في أي وقت مناسب للمطورين وتبدو على النحو التالي:
- قام المطورون بمراجعة واختبارها وإرسال الرمز إلى المنشور.
- تم تجميع الرمز تلقائيًا ، وتعبئته في صور عامل ميناء ، ونشره في مستودع عامل ميناء خاص.
- تقوم Kubernetes تلقائيًا برفع إصدارات جديدة من الخدمات ، والتحقق من أن الخدمات تعمل بشكل صحيح ، وتبديل المستخدمين لاستخدام إصدارات جديدة من الخدمات ، وإيقاف عمل الإصدارات القديمة وإزالتها من المجموعة. تم التحديث.
تلخيص تجربتنا
أنت بحاجة إلى Kubernetes إذا:
- مطلوب توافر عالية للنظام.
- يتطور النظام ديناميكيًا ، وتحتاج إلى إدخال تغييرات على بيئة المنتج مع إغلاق عينيك.
- تريد العمل كفريق واحد من التعليمات البرمجية إلى بيئة المنتج.
- أنت تصنع نظامًا ديناميكيًا ومتطورًا ستعمل لسنوات.
Kubernetes "مكلفة" ، حيث يتطلب دخول التكنولوجيا:
- الدراسة من قبل مطوري التقنيات ذات الصلة.
- مراجعة عمليات التصميم والتطوير والنشر والاختبار والإدارة البيئية.
- خبرة في تشغيل Kubernetes نفسها: الآن تحتاج إلى مراقبة ليس فقط نظامك ، ولكن أيضًا خدمات تطبيق Kubernetes.
ادفع Kubernetes بسرعة كبيرة:
- إجراء تحديث النظام أبسط وأسرع بكثير. يتم تحرير المطورين من كتلة كاملة من العمالة.
- سيدخل كل متخصص جديد المشروع بالفعل على القضبان.
- سيكون الناقل شفافًا وآليًا.
- سيتم تكرار التجربة من قبل فريقك للأنظمة الأخرى.
- ستقوم بتحديث النظام دون إيقاف تشغيله ، مما يعني أنك لن توقف العمل.
ملاحظة عملية PS: قسم مدخل التكنولوجيا إلى مرحلتين: تطوير نظام بهندسة الخدمات الدقيقة المناسبة ونقله تحت سيطرة K8S. وبالتالي ، فإن التحول تحت Kubernetes لن يتحول إلى إعادة هيكلة عالمية.