مكعب على مكعب، مجموعات ميتا، أقراص العسل، توزيع الموارد

أرز. 1. النظام البيئي Kubernetes على Alibaba Cloud

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

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

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

دخول

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

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

أرز. 2. مشاكل في إدارة عدد كبير من مجموعات Kubernetes

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

• عدم التجانس

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

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

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

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

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

• الامتثال الأمني

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

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

تصميم

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

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

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

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

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

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

تخطيط موارد ميتاكلستر

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

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

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

أرز. 3. بنية شبكة Terway

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

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

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

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

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

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

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

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

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

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

أرز. 5. مكونات مرنة وقابلة للتوصيل

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

أرز. 6. الفحص الأولي لمكونات المجموعة

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

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

أرز. 7. ينظم OpenKurise تنفيذ مهمة البث على جميع العقد

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

أرز. 8. ملفات تعريف عنقودية متقدمة ومرنة لمختلف السيناريوهات

إمكانية المراقبة العالمية عبر مراكز البيانات

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

أرز. 9. النشر العالمي لخدمة Alibaba Cloud Container في عشرين منطقة

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

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

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

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

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

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

• مستوى تتالي

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

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

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

أرز. 10. بنية مراقبة عالمية متعددة المستويات تعتمد على آلية اتحاد بروميثيوس

ملخص

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

المصدر: www.habr.com