مكعب على المكعب ، metaclusters ، والخلايا ، وتخصيص الموارد

التين. 1. Kubernetes النظام البيئي في بابا الغيمة

منذ عام 2015 ، كانت Alibaba Cloud Container Service لـ Kubernetes (ACK) واحدة من أسرع الخدمات السحابية نمواً في Alibaba Cloud. إنه يخدم العديد من العملاء ويدعم أيضًا البنية التحتية الداخلية لـ Alibaba والخدمات السحابية الأخرى للشركة.

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

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

دخول

أصبح Kubernetes المعيار الفعلي لمختلف أعباء العمل السحابية. كما هو مبين في التين. 1 في الأعلى ، تعمل تطبيقات Alibaba Cloud أكثر وأكثر الآن في مجموعات Kubernetes: هذه تطبيقات ذات حالة / بدون جنسية ، بالإضافة إلى مديري التطبيقات. لطالما كانت إدارة Kubernetes موضوع مناقشة مثيرًا للاهتمام وجديًا للمهندسين المشاركين في بناء وصيانة البنية التحتية. عندما يتعلق الأمر بموفري الخدمات السحابية مثل Alibaba Cloud ، فإن التوسع في الصدارة. كيفية إدارة مجموعات Kubernetes بهذا الحجم؟ تحدثنا بالفعل عن أفضل الممارسات لإدارة مجموعات Kubernetes الضخمة المكونة من 10،000 عقدة. بالطبع ، هذه مشكلة تحجيم مثيرة للاهتمام. ولكن هناك مقياس آخر: عدد المجموعات نفسها .

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


التين. 2. تحديات إدارة عدد كبير من مجموعات Kubernetes

ما هي المشاكل الرئيسية لإدارة الكتلة على هذا النطاق؟ كما هو مبين في الشكل ، هناك أربع قضايا للتعامل مع:

• عدم التجانس

يجب أن تدعم ACK أنواعًا مختلفة من المجموعات ، بما في ذلك Standard و serverless و Edge و Windows وبعضها الآخر. تتطلب المجموعات المختلفة معلمات ومكونات ونماذج استضافة مختلفة. يحتاج بعض العملاء إلى المساعدة في التخصيص لحالاتهم المحددة.

• أحجام الكتلة المختلفة

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

• إصدارات مختلفة

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

• الامتثال السلامة

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

تم تصميم منصة ACK لحل معظم المشاكل المذكورة أعلاه. حاليا ، فإنه يدير بثبات وبشكل ثابت أكثر من 10 آلاف مجموعات Kubernetes في جميع أنحاء العالم. دعونا نرى كيف تمكنا من تحقيق ذلك ، بما في ذلك بسبب عدة مبادئ رئيسية للتصميم / الهندسة المعمارية.

تصميم

مكعب على المكعب وأقراص العسل

بخلاف التسلسل الهرمي المركزي ، تُستخدم البنية القائمة على الخلايا عادةً لتوسيع نطاق النظام الأساسي إلى ما بعد مركز بيانات واحد أو لتوسيع نطاق الاسترداد بعد عطل فادح.

تتكون كل منطقة في Alibaba Cloud من عدة مناطق (AZ) وعادة ما تتوافق مع مركز بيانات محدد. في منطقة كبيرة (مثل Huangzhou) ، يتم العثور على الآلاف من مجموعات عملاء Kubernetes التي تدير ACK.

تدير ACK مجموعات Kubernetes هذه باستخدام Kubernetes نفسها ، وهذا هو ، لدينا Kubernetes metacluster لإدارة مجموعات عملاء Kubernetes. وتسمى هذه البنية أيضًا "المكعب على المكعب" (kube-on-kube، KoK). تعمل بنية KoK على تبسيط إدارة مجموعات العملاء حيث يصبح نشر الكتلة أمرًا بسيطًا وحاسمًا. الأهم من ذلك ، يمكننا إعادة استخدام ميزات Kubernetes الأصلية. على سبيل المثال ، إدارة خوادم API من خلال النشر ، باستخدام عامل التشغيل etcd لإدارة عمليات أخرى متعددة. هذا العودية يجلب دائما متعة خاصة.

داخل نفس المنطقة ، يتم نشر العديد من ملفات تعريف Kubernetes ، اعتمادًا على عدد العملاء. هذه metaclusters نسميها الخلايا. للحماية من فشل منطقة بأكملها ، تدعم ACK عمليات النشر متعددة النشاطات في منطقة واحدة: توزع المجموعة التعريفية مكونات معالج نظام المجموعة العميل Kubernetes في عدة مناطق وتبدأ تشغيلها في نفس الوقت ، أي في وضع متعدد النشاطات. لضمان موثوقية المعالج وفعاليته ، تعمل ACK على تحسين موضع المكونات وتضمن أن خادم API و etcd قريبان من بعضهما البعض.

يتيح لك هذا النموذج إدارة Kubernetes بفعالية ومرونة وموثوقية.

تخطيط موارد Metacluster

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

خذ موارد الشبكة ، على سبيل المثال. في بنية KoK ، يتم نشر مكونات Kubernetes من الكتل العميلة كقرون في metacluster. نستخدم Terway (الشكل 3) ، وهو مكون إضافي عالي الأداء تم تطويره بواسطة Alibaba Cloud لإدارة شبكة الحاويات. إنه يوفر مجموعة غنية من سياسات الأمان ويسمح لك بالاتصال بعملاء السحابة الخاصة الظاهرية (VPC) من خلال Alibaba Cloud Elastic Networking Interface (ENI). لتوزيع موارد الشبكة بكفاءة بين العقد والقرون والخدمات في metacluster ، يجب علينا مراقبة استخدامها بعناية داخل metacluster من السحب الخاصة الافتراضية. عندما تنتهي موارد الشبكة ، يتم إنشاء خلية جديدة.

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


التين. 3. شبكة الهندسة المعمارية Terway

تحجيم مكونات المعالج في الكتل العميلة

مكونات المعالج لها متطلبات موارد مختلفة. يعتمدون على عدد العقد والقرون في الكتلة ، وعدد وحدات التحكم / المشغلين غير القياسية التي تتفاعل مع APIServer.

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

لإيجاد حل وسط دقيق بين الموثوقية والتكلفة ، تستخدم ACK نظام كتابة. وهي نعرّف ثلاثة أنواع من المجموعات: الصغيرة والمتوسطة والكبيرة. كل نوع لديه ملف تخصيص تخصيص منفصل. يتم تحديد النوع بناءً على تحميل مكونات المعالج وعدد العقد والعوامل الأخرى. قد يتغير نوع الكتلة مع مرور الوقت. تقوم ACK بمراقبة هذه العوامل باستمرار ، وبالتالي يمكنها زيادة / تقليل النوع. بعد تغيير نوع الكتلة ، يتم تحديث توزيع الموارد تلقائيًا مع الحد الأدنى من تدخل المستخدم.

نحن نعمل على تحسين هذا النظام من حيث التحجيم الدقيق والتحديثات النوعية الأكثر دقة ، بحيث تحدث هذه التغييرات بشكل أكثر سلاسة وأكثر منطقية من الناحية الاقتصادية.


التين. 4. ذكي التبديل متعدد المراحل

تطور مجموعات العميل على نطاق واسع

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

Kubernetes هو Linux في عالم السحابة. يتم تحديثه باستمرار ويصبح أكثر وحدات. يجب علينا تزويد عملائنا باستمرار بالإصدارات الجديدة ، وإصلاح الثغرات الأمنية وتحديث الكتل الموجودة ، بالإضافة إلى إدارة عدد كبير من المكونات ذات الصلة (CSI ، CNI ، البرنامج المساعد للجهاز ، برنامج جدولة البرنامج المساعد والعديد من المكونات الأخرى).

خذ إدارة مكونات Kubernetes كمثال. بادئ ذي بدء ، قمنا بتطوير نظام تسجيل وإدارة مركزي لجميع مكونات المكونات الإضافية هذه.


التين. 5. المكونات المرنة والمكونات

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


التين. 6. الاختيار الأولي لمكونات الكتلة

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

على سبيل المثال ، تم تصميم وحدة التحكم BroadcastJob لتحديث المكونات على كل جهاز يعمل أو للتحقق من العقد على كل جهاز. تعمل مهمة البث على pod على كل عقدة في الكتلة ، مثل DaemonSet. ومع ذلك ، يدعم DaemonSet دائمًا التشغيل المستمر للقرنة ، في حين يقلل BroadcastJob من ذلك. تبدأ وحدة التحكم في البث أيضًا في قرون على العقد المتصلة حديثًا وتهيئة العقد بالمكونات الضرورية. في يونيو 2019 ، فتحنا الكود المصدري لمحرك أتمتة OpenKruise ، والذي نستخدمه نحن داخل الشركة.


التين. 7. ينظم OpenKurise تخصيصات البث في جميع المواقع.

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


التين. 8. التشكيلات الجانبية المتقدمة والمرنة للسيناريوهات المختلفة

مركز البيانات العالمي الملاحظة

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


التين. 9. النشر العالمي لخدمة علي بابا للحاويات السحابية في عشرين منطقة

كما هو الحال مع العديد من أنظمة مراقبة Kubernetes ، لدينا Prometheus كأداة رئيسية لدينا. لكل metacluster ، يجمع وكلاء Prometheus المقاييس التالية:

• مقاييس نظام التشغيل ، مثل موارد المضيف (المعالج ، الذاكرة ، القرص ، إلخ) وعرض النطاق الترددي للشبكة.
  
• مقاييس نظام إدارة نظام المجموعة ونظام العميل ، مثل kube-apiserver و kube-controller-manager و kube-scheduler.
  
• مقاييس من kubernetes-state-metrics و cadvisor.
  
• مقاييس Etcd ، مثل وقت كتابة القرص ، وحجم قاعدة البيانات ، والإنتاجية بين العقد ، إلخ.

يتم جمع الإحصاءات العالمية باستخدام نموذج تجميع نموذجي متعدد الطبقات. يتم تجميع بيانات المراقبة من كل مجموعة أولية في كل منطقة ، ثم يتم إرسالها إلى خادم مركزي ، مما يوضح الصورة الكبيرة. كل شيء يعمل من خلال آلية الاتحاد. يجمع خادم بروميثيوس في كل مركز بيانات مقاييس مركز البيانات هذا ، وخادم بروميثيوس المركزي مسؤول عن تجميع بيانات المراقبة. يتصل AlertManager بالبروميثيوس المركزي ، وإذا لزم الأمر ، يرسل تنبيهات عبر DingTalk ، والبريد الإلكتروني ، والرسائل القصيرة ، وما إلى ذلك التصور - باستخدام Grafana.

في الشكل 10 ، يمكن تقسيم نظام المراقبة إلى ثلاثة مستويات:

• مستوى الحدود

أبعد طبقة من المركز. يعمل خادم Prometheus Edge على كل ملف تعريف ، حيث يجمع المقاييس من مجموعات التعريف والعميل في نفس مجال الشبكة.

• مستوى الشلال

تتمثل وظيفة طبقة Prometheus المتتالية في جمع بيانات المراقبة من عدة مناطق. تعمل هذه الخوادم على مستوى الوحدات الجغرافية الأكبر مثل الصين وآسيا وأوروبا وأمريكا. مع نمو المجموعات في منطقة ما ، يمكن تقسيمها ، ثم سيظهر خادم Prometheus على مستوى المتتالية في كل منطقة كبيرة جديدة. مع هذه الاستراتيجية ، يمكنك التوسع بسلاسة حسب الحاجة.

• المستوى المركزي

يتصل خادم Prometheus المركزي بجميع خوادم المتتالية ويقوم بتجميع البيانات النهائية. من أجل الموثوقية ، تم رفع مثلي بروميثيوس مركزيين متصلين بنفس خوادم المتتالية في مناطق مختلفة.


التين. 10. هيكل رصد عالمي متعدد المستويات يعتمد على آلية اتحاد بروميثيوس

ملخص

تستمر حلول السحابة المستندة إلى Kubernetes في تحويل صناعتنا. توفر Alibaba Cloud Container Service خدمة استضافة آمنة وموثوقة وعالية الأداء - وهي واحدة من أفضل خدمات الاستضافة السحابية من Kubernetes. يؤمن فريق Alibaba Cloud بشدة بمبادئ المصدر المفتوح ومجتمع المصادر المفتوحة. بالتأكيد سنستمر في مشاركة معرفتنا في مجال تشغيل وإدارة التقنيات السحابية.