منذ حوالي عام حتى الآن ، يقوم قسم البنية التحتية لدينا بترحيل جميع الخدمات التي تعمل على GitLab.com إلى Kubernetes. خلال هذا الوقت ، واجهنا مشكلات ليس فقط في نقل الخدمات إلى Kubernetes ، ولكن أيضًا في إدارة النشر المختلط أثناء النقل. ستتم مناقشة الدروس القيمة التي تعلمناها في هذه المقالة.
منذ بداية موقع GitLab.com ، كانت خوادمه تعمل في السحابة على الأجهزة الافتراضية. تتم إدارة هذه الأجهزة الافتراضية بواسطة Chef وتثبيتها باستخدام حزمة Linux الرسمية الخاصة بنا . تتمثل استراتيجية النشر في حالة احتياج أحد التطبيقات إلى التحديث في تحديث أسطول الخادم بطريقة متسلسلة منسقة باستخدام خط أنابيب CI. تضمن هذه الطريقة - مهما كانت بطيئة ومملة بعض الشيء - أن GitLab.com يستخدم نفس طرق التثبيت والتكوين مثل مستخدمي تثبيتات GitLab ذاتية الإدارة باستخدام حزم Linux الخاصة بنا.
نستخدم هذه الطريقة لأنه من المهم للغاية تجربة كل الحزن والأفراح التي يشعر بها الأعضاء العاديون في المجتمع عند تثبيت وتكوين نسخهم من GitLab. نجح هذا النهج بشكل جيد لبعض الوقت ، ولكن نظرًا لأن عدد المشاريع على GitLab تجاوز 10 ملايين ، فقد أدركنا أنه لم يعد يلبي احتياجات التوسع والنشر الخاصة بنا.
الخطوات الأولى نحو Kubernetes و GitLab الأصلية السحابية
في عام 2017 ، تم إنشاء مشروع GitLab Charts لإعداد GitLab للنشر في السحابة ، وكذلك لتمكين المستخدمين من تثبيت GitLab على مجموعات Kubernetes. علمنا بعد ذلك أن نقل GitLab إلى Kubernetes سيزيد من قابلية تطوير النظام الأساسي SaaS ، ويبسط عمليات النشر ، ويحسن كفاءة الحوسبة. في الوقت نفسه ، اعتمدت العديد من ميزات تطبيقنا على أقسام NFS المركبة ، مما أدى إلى إبطاء الانتقال من الأجهزة الافتراضية.
سمح السعي وراء السحابة الأصلية و Kubernetes لمهندسينا بالتخطيط لعملية انتقال تدريجي ، تخلينا خلالها عن بعض تبعيات NAS للتطبيق مع الاستمرار في تطوير ميزات جديدة على طول الطريق. منذ أن بدأنا التخطيط للترحيل في صيف 2019 ، تمت إزالة العديد من هذه القيود ، وعملية ترحيل GitLab.com إلى Kubernetes تجري الآن على قدم وساق!
ميزات عمل GitLab.com في Kubernetes
بالنسبة إلى GitLab.com ، نستخدم مجموعة GKE إقليمية واحدة تتعامل مع كل حركة مرور التطبيقات. لتقليل تعقيد الترحيل (الصعب بالفعل) ، نركز على الخدمات التي لا تعتمد على التخزين المحلي أو NFS. يستخدم موقع GitLab.com قاعدة أكواد ريلز متجانسة في الغالب ، ونقوم بتوجيه حركة المرور بناءً على خصائص عبء العمل إلى نقاط نهاية مختلفة معزولة في مجموعات العقد الخاصة بنا.
في حالة الواجهة الأمامية ، يتم تقسيم هذه الأنواع إلى طلبات على الويب و API و Git SSH / HTTPS و Registry. في حالة الواجهة الخلفية ، نضع المهام في قائمة الانتظار وفقًا لخصائص مختلفة اعتمادًا على حدود الموارد المحددة مسبقًا التي تسمح لنا بتعيين أهداف مستوى الخدمة (SLO) لأحمال العمل المختلفة.
يتم تكوين كل خدمات GitLab.com هذه باستخدام مخطط GitLab Helm غير معدل. يتم التهيئة في مخططات فرعية ، والتي يمكن تمكينها بشكل انتقائي أثناء ترحيل الخدمات تدريجيًا إلى المجموعة. على الرغم من أنه تقرر عدم تضمين بعض خدماتنا ذات الحالة العامة مثل Redis و Postgres و GitLab Pages و Gitaly في الترحيل ، فإن Kubernetes يقلل بشكل كبير من عدد VMs Chef الذي يديره حاليًا.
الشفافية وإدارة التكوين Kubernetes
يتم التحكم في جميع الإعدادات بواسطة GitLab نفسه. لهذا الغرض ، يتم استخدام ثلاثة مشاريع تكوين تعتمد على Terraform و Helm. نحاول في كل مكان ، كلما أمكن ذلك ، استخدام GitLab نفسه لتشغيل GitLab ، ولكن بالنسبة للمهام التشغيلية لدينا تثبيت GitLab منفصل. من الضروري أن تكون مستقلاً عن توفر GitLab.com لعمليات النشر والتحديثات الخاصة بـ GitLab.com.
على الرغم من أن خطوط الأنابيب الخاصة بنا لمجموعة Kubernetes تعمل على تثبيت GitLab منفصل ، إلا أن مستودعات إعادة الشراء البرمجية لها مرايا متاحة للجمهور على العناوين التالية:
- k8s-workloads / gitlab-com - ربط تكوين GitLab.com لمخطط GitLab Helm ؛
- k8s-workloads/gitlab-helmfiles — , GitLab . , PlantUML;
- Gitlab-com-infrastructure — Terraform Kubernetes (legacy) VM-. , , , , , IP-.
عند إجراء التغييرات ، يتم عرض ملخص قصير متاح للجمهور مع ارتباط إلى فرق تفصيلي ، والذي يحلل SRE قبل إجراء تغييرات على المجموعة.
بالنسبة إلى SRE ، يشير الارتباط إلى اختلاف تفصيلي في تثبيت GitLab الذي يتم استخدامه للإنتاج والوصول إليه والذي يكون محدودًا. يسمح هذا للموظفين والمجتمع دون الوصول إلى المشروع التشغيلي (مفتوح فقط لـ SRE) لعرض تغييرات التكوين المقترحة. من خلال دمج مثيل عام من GitLab للتعليمات البرمجية مع مثيل خاص لخطوط أنابيب CI ، نحافظ على سير عمل واحد ، مع ضمان الاستقلال عن GitLab.com لتحديثات التكوين.
ما اكتشفناه أثناء الهجرة
أثناء النقل ، تراكمت الخبرة ، والتي نطبقها على عمليات الترحيل والنشر الجديدة في Kubernetes.
1. -
إحصائيات الخروج اليومية (بايت في اليوم) لمنتزه مستودع Git على GitLab.com
تقسم Google شبكتها إلى مناطق. تلك ، بدورها ، مقسمة إلى مناطق توافر (AZ). ترتبط استضافة Git بكميات كبيرة من البيانات ، لذلك من المهم بالنسبة لنا التحكم في خروج الشبكة. بالنسبة لحركة المرور الداخلية ، يكون الخروج مجانيًا فقط إذا ظل داخل نفس منطقة الألف إلى الياء. في وقت كتابة هذه السطور ، نقدم ما يقرب من 100 تيرابايت من البيانات في يوم عمل عادي (وهذا فقط لمستودعات Git). الخدمات التي ، في الهيكل القديم القائم على VM ، كانت على نفس الأجهزة الافتراضية ، تعمل الآن في مجموعات Kubernetes مختلفة. هذا يعني أن بعض حركة المرور التي كانت محلية في السابق لجهاز VM من المحتمل أن تخرج خارج مناطق توافر الخدمات.
تسمح لك مجموعات GKE الإقليمية بتوسيع مناطق توافر متعددة للتكرار. نحن ندرس تقسيم مجموعة GKE الإقليمية إلى مجموعات منطقة واحدة للخدمات التي تولد كميات كبيرة من حركة المرور. سيؤدي ذلك إلى تقليل تكاليف الخروج مع الحفاظ على التكرار العنقودي.
2. الحدود وطلبات الموارد والتوسع
عدد النسخ المتماثلة التي تعالج حركة مرور الإنتاج في Registry.gitlab.com. ذروتها عند الساعة 15:00 بالتوقيت العالمي المنسق.
بدأت قصة الترحيل في أغسطس 2019 ، عندما نقلنا خدمتنا الأولى ، GitLab Container Registry ، إلى Kubernetes. كانت هذه الخدمة عالية الحركة والمهمة مناسبة تمامًا للترحيل الأول لأنها تطبيق عديم الحالة مع بعض التبعيات الخارجية. كانت المشكلة الأولى التي واجهناها هي العدد الكبير من البودات التي تم استباقها بسبب عدم كفاية الذاكرة على العقد. لهذا السبب ، كان علينا تغيير الطلبات والحدود.
وجد أنه في حالة التطبيق الذي يزداد فيه استهلاك الذاكرة بمرور الوقت ، فإن القيم المنخفضة للطلب (لكل وحدة ذاكرة فائضة) مقترنة بحد جامد "سخي" لاستخدام وحدات التشبع (التشبع) و مستوى مرتفع من الإزاحة. للتعامل مع هذه المشكلة ، تقرر زيادة الطلبات وتقليل الحدود . أدى ذلك إلى إزالة الضغط عن العقد وضمن دورة حياة جراب لم تضع ضغطًا كبيرًا على العقدة. نبدأ الآن عمليات الترحيل بالطلب السخي (والمتطابق تقريبًا) والقيم المحددة ، مع تعديلها حسب الحاجة.
3. المقاييس والسجلات
تركز البنية التحتية على زمن الوصول ومعدلات الخطأ والتشبع بأهداف مستوى الخدمة المحددة (SLOs) المرتبطة بالتوافر الكلي لنظامنا .
على مدار العام الماضي ، كان أحد التطورات الرئيسية في قسم البنية التحتية هو التحسينات في المراقبة والعمل مع SLOs. سمحت لنا SLO بتحديد أهداف للخدمات الفردية ، والتي راقبناها عن كثب أثناء الترحيل. ولكن حتى مع إمكانية الملاحظة المحسنة هذه ، فليس من الممكن دائمًا رؤية المشكلات على الفور باستخدام المقاييس والتنبيهات. على سبيل المثال ، من خلال التركيز على معدلات زمن الانتقال والخطأ ، فإننا لا نغطي جميع حالات الاستخدام الخاصة بخدمة تخضع لعملية ترحيل.
تم اكتشاف هذه المشكلة على الفور تقريبًا بعد نقل بعض أحمال العمل إلى الكتلة. أصبح الأمر حادًا بشكل خاص عندما كان من الضروري فحص الوظائف ، وعدد الطلبات صغير ، ولكن لها تبعيات تكوين محددة للغاية. كان أحد الدروس الرئيسية من نتائج الترحيل هو الحاجة إلى أخذها في الاعتبار عند مراقبة ليس فقط المقاييس ، ولكن أيضًا السجلات و "الذيل الطويل" (نحن نتحدث عن توزيعها على الرسم البياني - تقريبًا. مترجم) . الآن ، لكل عملية ترحيل ، نقوم بتضمين قائمة مفصلة باستعلامات السجل ونخطط لإجراءات التراجع الواضحة التي يمكن تمريرها من تحول إلى آخر في حالة حدوث مشاكل.
كان تقديم نفس الطلبات بالتوازي على البنية التحتية القديمة لجهاز VM والبنية الجديدة القائمة على Kubernetes يمثل تحديًا فريدًا. على عكس ترحيل الرفع والتحويل (النقل السريع للتطبيقات "كما هي" إلى بنية تحتية جديدة ؛ يمكنك قراءة المزيد من التفاصيل ، على سبيل المثال ، هنا - ترجمة تقريبًا) ، يتطلب العمل الموازي على أجهزة VM "القديمة" و Kubernetes أدوات لـ كانت أنظمة المراقبة متوافقة مع البيئتين وتمكنت من دمج المقاييس في عرض واحد. من المهم أن نستخدم نفس لوحات المعلومات واستعلامات السجل لتحقيق إمكانية ملاحظة متسقة أثناء الانتقال.
4. تحويل حركة المرور إلى كتلة جديدة
بالنسبة إلى GitLab.com ، تم تخصيص بعض الخوادم لمرحلة الكناري . يلبي Canary Park مشاريعنا الداخلية ويمكن أيضًا تمكينه من قبل المستخدمين . ولكنه مصمم في المقام الأول للتحقق من صحة التغييرات التي تم إجراؤها على البنية التحتية والتطبيق. بدأت الخدمة الأولى التي تم ترحيلها بقبول كمية محدودة من حركة المرور الداخلية ، ونستمر في استخدام هذه الطريقة لضمان تلبية SLO قبل إعادة توجيه كل حركة المرور إلى الكتلة.
في حالة الترحيل ، هذا يعني أن الطلبات الأولى للمشاريع الداخلية يتم إرسالها إلى Kubernetes ، ثم نقوم تدريجياً بتحويل بقية حركة المرور إلى الكتلة عن طريق تغيير وزن الواجهة الخلفية من خلال HAProxy. في عملية الانتقال من VM إلى Kubernetes ، أصبح من الواضح أنه كان من المفيد جدًا وجود طريقة بسيطة لإعادة توجيه حركة المرور بين البنية التحتية القديمة والجديدة ، وبالتالي الحفاظ على البنية التحتية القديمة جاهزة للتراجع في الأيام القليلة الأولى بعد الترحيل.
5. الطاقة الاحتياطية للقرون واستخدامها
على الفور تقريبًا ، تم تحديد المشكلة التالية: بدأت كبسولات خدمة التسجيل بسرعة ، لكن إطلاق الكبسولات لـ Sidekiq استغرق ما يصل إلى دقيقتين . أصبحت الكبسولات طويلة المدى لـ Sidekiq مشكلة عندما بدأنا في ترحيل أعباء العمل إلى Kubernetes للعمال الذين يحتاجون إلى معالجة الوظائف بسرعة والتوسع بسرعة.
في هذه الحالة ، كان الدرس هو أنه في حين أن جهاز القياس التلقائي الأفقي (HPA) في Kubernetes يتعامل مع نمو حركة المرور بشكل جيد ، فمن المهم مراعاة خصائص أعباء العمل وتخصيص السعة الاحتياطية (خاصة في بيئة توزيع الطلب غير المتكافئ). في حالتنا ، كان هناك ارتفاع مفاجئ في الوظائف ، مما استلزم التوسع السريع ، مما أدى إلى تشبع موارد وحدة المعالجة المركزية قبل أن يتاح لنا الوقت لتوسيع نطاق مجموعة العقد.
هناك دائمًا إغراء للضغط على أكبر قدر ممكن من الكتلة ، ومع ذلك ، فقد واجهنا في البداية مشكلات في الأداء ، والآن نبدأ بميزانية جراب سخية وخفضها لاحقًا ، مع مراقبة SLO عن كثب. لقد تسارعت عملية إطلاق البودات لخدمة Sidekiq بشكل كبير وتستغرق الآن حوالي 40 ثانية في المتوسط.استفاد كل من GitLab.com ومستخدمينا للمنشآت المدارة ذاتيًا الذين يعملون مع مخطط GitLab Helm الرسمي من تقليل أوقات إطلاق البودات.
خاتمة
بعد ترحيل كل خدمة ، استمتعنا بمزايا استخدام Kubernetes في الإنتاج: نشر التطبيقات بشكل أسرع وأكثر أمانًا ، وتوسيع نطاق ، وتخصيص موارد أكثر كفاءة. علاوة على ذلك ، تتجاوز مزايا الترحيل خدمة GitLab.com. كل تحسين على مخطط Helm الرسمي يفيد مستخدميه أيضًا.
أتمنى أن تكون قد استمتعت بقصة مغامرات هجرة Kubernetes. نستمر في ترحيل جميع الخدمات الجديدة إلى المجموعة. يمكن الحصول على معلومات إضافية من المنشورات التالية:
- « لماذا نهاجر إلى Kubernetes <br> نحن؟ "؛
- " GitLab.com على Kubernetes " ؛
- Epic on Migrating GitLab.com to Kubernetes .
PS من المترجم
اقرأ أيضًا على مدونتنا: