ملحوظة. ترجمة.يعتبر اعتماد GitLab لنظام Kubernetes أحد عاملين رئيسيين يساهمان في نمو الشركة. ومع ذلك ، حتى وقت قريب ، كانت البنية التحتية لخدمة GitLab.com عبر الإنترنت مبنية على أجهزة افتراضية ، ومنذ عام واحد فقط بدأت عملية الترحيل إلى K8s ، والتي لم تكتمل بعد. يسعدنا تقديم ترجمة لمقال حديث لمهندس GitLab SRE حول كيفية حدوث ذلك وما هي الاستنتاجات التي توصل إليها المهندسون المشاركون في المشروع.
منذ حوالي عام حتى الآن ، يقوم قسم البنية التحتية لدينا بترحيل جميع الخدمات التي تعمل على GitLab.com إلى Kubernetes. خلال هذا الوقت ، واجهنا تحديات ليس فقط مع نقل الخدمات إلى Kubernetes ، ولكن أيضًا في إدارة عمليات النشر المختلطة أثناء النقل. ستتم مناقشة الدروس القيمة التي تعلمناها في هذه المقالة.
منذ بداية موقع GitLab.com ، كانت خوادمه تعمل في السحابة في الأجهزة الافتراضية. تتم إدارة هذه الأجهزة الافتراضية بواسطة Chef ويتم تثبيتها باستخدام . في حالة احتياج التطبيق إلى التحديث ، يجب ببساطة تحديث أسطول الخادم بطريقة متسلسلة منسقة باستخدام خط أنابيب CI. هذه الطريقة وإن كانت بطيئة وقليلة - يضمن أن GitLab.com يستخدم نفس طرق التثبيت والتكوين مثل المستخدمين المستقلين (مدار ذاتيًا) يتم تثبيت GitLab باستخدام حزم Linux الخاصة بنا لهذا الغرض.
نحن نستخدم هذه الطريقة لأنه من الأهمية بمكان تجربة الألم والفرح اللذين يمر بهما متوسط أفراد المجتمع عند قيامهم بتثبيت وتهيئة نسخهم من GitLab. نجح هذا النهج بشكل جيد لبعض الوقت ، ولكن عندما تجاوز عدد المشاريع على GitLab 10 ملايين ، أدركنا أنه لم يعد يلبي احتياجات التوسع والنشر الخاصة بنا.
الخطوات الأولى نحو Kubernetes و GitLab الأصلية السحابية
تم إنشاء المشروع في عام 2017 لإعداد 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 تقليل عدد الأجهزة الافتراضية التي يديرها الشيف بشكل كبير.
الشفافية وإدارة التكوين لـ Kubernetes
تتم إدارة جميع الإعدادات بواسطة GitLab نفسها. يتم استخدام ثلاثة مشاريع تكوين تستند إلى Terraform و Helm لهذا الغرض. نحاول استخدام GitLab نفسه كلما أمكن ذلك لتشغيل GitLab ، ولكن بالنسبة للمهام التشغيلية ، لدينا تثبيت GitLab منفصل. من الضروري عدم الاعتماد على توفر GitLab.com عند إجراء عمليات النشر والتحديثات على GitLab.com.
على الرغم من أن خطوط الأنابيب الخاصة بنا لمجموعة Kubernetes تعمل على تثبيت GitLab منفصل ، فإن مستودعات الأكواد بها مرايا متاحة للجمهور على العناوين التالية:
- - ربط تكوين GitLab.com لمخطط GitLab Helm ؛
- - يحتوي على تكوينات للخدمات التي لا ترتبط مباشرة بتطبيق GitLab. وتشمل هذه تكوينات للتسجيل ومراقبة الكتلة ، وكذلك أدوات متكاملة مثل PlantUML ؛
- - تهيئة Terraform لـ Kubernetes والبنية التحتية للجهاز الظاهري القديمة. هنا تقوم بتكوين جميع الموارد اللازمة لتشغيل الكتلة ، بما في ذلك الكتلة نفسها ، وتجمعات العقد ، وحسابات الخدمة ، وحجز عنوان IP.
عند إجراء التغييرات ، يتم عرض العرض العام. مع ارتباط إلى فرق تفصيلي يقوم SRE بتحليله قبل إجراء تغييرات على الكتلة.
بالنسبة إلى SRE ، يؤدي الارتباط إلى اختلاف تفصيلي في تثبيت GitLab ، والذي يتم تقييده للإنتاج والوصول إليه. يتيح ذلك للموظفين والمجتمع دون الوصول إلى التصميم التشغيلي (وهو مفتوح فقط لمجموعات SREs) لعرض تغييرات التكوين المقترحة. من خلال دمج مثيل عام من GitLab للتعليمات البرمجية مع مثيل خاص لخطوط أنابيب CI ، نحافظ على سير عمل واحد مع ضمان الاستقلال عن GitLab.com لتحديثات التكوين.
ما تعلمناه خلال الهجرة
أثناء النقل ، تم اكتساب الخبرة التي نطبقها على عمليات الترحيل وعمليات النشر الجديدة في Kubernetes.
1. زيادة التكاليف بسبب حركة المرور بين مناطق توافر الخدمات
إحصائيات الخروج اليومية (بايت في اليوم) لأسطول تخزين Git على GitLab.com
جوجل يقسم شبكتها إلى مناطق. وهذه بدورها مقسمة إلى مناطق توافر (AZ). ترتبط استضافة Git بكميات كبيرة من البيانات ، لذلك من المهم بالنسبة لنا التحكم في خروج الشبكة. في حالة النقل الداخلي ، يكون الخروج مجانيًا فقط إذا ظل داخل حدود منطقة توافر واحدة. في وقت كتابة هذه السطور ، نمنح ما يقرب من 100 تيرابايت من البيانات في يوم عمل عادي (وهذا فقط لمستودعات Git). الخدمات التي كانت في نفس الأجهزة الافتراضية في الهيكل القديم القائم على VM تعمل الآن في مجموعات Kubernetes مختلفة. هذا يعني أن بعض حركة المرور التي اعتادت أن تكون محلية على الجهاز الظاهري يمكن أن تذهب خارج مناطق التوفر.
تسمح لك مجموعات GKE الإقليمية بتوسيع مناطق توافر متعددة للتكرار. نحن ندرس الاحتمال للخدمات التي تولد قدرًا كبيرًا من حركة المرور. سيؤدي ذلك إلى تقليل تكلفة الخروج مع الحفاظ على التكرار على مستوى الكتلة.
2. الحدود وطلبات الموارد والتوسع
عدد النسخ المتماثلة التي تتعامل مع حركة مرور الإنتاج إلى Registry.gitlab.com. ذروة حركة المرور عند الساعة 15:00 بالتوقيت العالمي المنسق تقريبًا.
بدأت قصة الترحيل في أغسطس 2019 ، عندما قمنا بترحيل الخدمة الأولى ، GitLab Container Registry ، إلى Kubernetes. كانت هذه الخدمة الحرجة للمهام عالية الحركة مناسبة جدًا لأول عملية ترحيل لأنها تطبيق عديم الحالة مع القليل من التبعيات الخارجية. كانت المشكلة الأولى التي واجهناها هي إخراج عدد كبير من البودات بسبب نقص الذاكرة على العقد. لهذا السبب ، كان علينا تغيير الطلبات والحدود.
لقد وجد أنه في حالة التطبيق الذي ينمو فيه استهلاك الذاكرة بمرور الوقت ، أدت القيم المنخفضة للطلبات (الاحتفاظ بالذاكرة لكل جراب) ، إلى جانب الحد الثابت "السخي" للاستخدام ، إلى التشبع (التشبع) العقد ومستوى عالٍ من عمليات الإزاحة. للتعامل مع هذه المشكلة ، كان . أدى ذلك إلى إزالة الضغط عن العقد وتوفير دورة حياة للجراب لم تضع ضغطًا كبيرًا على العقدة. نبدأ الآن عمليات الترحيل بالطلب السخي (والمتطابق تقريبًا) والقيم المحددة ، مع تعديلها حسب الحاجة.
3. المقاييس والسجلات
يركز قسم البنية التحتية على الكمون ومعدل الخطأ والتشبع مع المنشأة (SLO) مرتبط بـ .
على مدار العام الماضي ، كان أحد التطورات الرئيسية في قسم البنية التحتية هو التحسينات في المراقبة والعمل مع SLO. سمحت لنا SLO بتحديد أهداف للخدمات الفردية ، والتي راقبناها عن كثب أثناء الترحيل. ولكن حتى مع إمكانية الملاحظة المحسنة هذه ، فليس من الممكن دائمًا رؤية المشكلات على الفور باستخدام المقاييس والتنبيهات. على سبيل المثال ، من خلال التركيز على معدلات زمن الانتقال والخطأ ، فإننا لا نغطي جميع حالات الاستخدام للخدمة التي يتم ترحيلها.
تم اكتشاف هذه المشكلة على الفور تقريبًا بعد نقل بعض أحمال العمل إلى الكتلة. لقد جعلت نفسها حادة بشكل خاص عندما اضطررنا إلى التحقق من الوظائف ، وعدد الطلبات صغير ، ولكن لها تبعيات تكوين محددة للغاية. كان أحد الدروس الرئيسية من الترحيل هو الحاجة إلى أخذها في الاعتبار عند مراقبة ليس فقط المقاييس ، ولكن أيضًا السجلات و "الذيل الطويل" (هذا هو حول على الرسم البياني - تقريبًا. ترجمة.) أخطاء. الآن لكل عملية ترحيل ، نقوم بتضمين قائمة مفصلة بالطلبات إلى السجلات (استعلامات السجل) ونخطط لإجراءات تراجع واضحة يمكن نقلها من وردية إلى أخرى في حالة حدوث مشاكل.
كانت خدمة نفس الطلبات بالتوازي على البنية التحتية القديمة لجهاز VM والبنية الجديدة القائمة على Kubernetes تمثل تحديًا فريدًا. على عكس ترحيل الرفع والتحويل (نقل سريع للتطبيقات "كما هي" إلى بنية تحتية جديدة ؛ لمزيد من التفاصيل ، انظر على سبيل المثال - تقريبا. ترجمة.)، يتطلب العمل الموازي على الأجهزة الافتراضية "القديمة" و Kubernetes أن تكون أدوات المراقبة متوافقة مع البيئتين وأن تكون قادرة على دمج المقاييس في عرض واحد. من المهم أن نستخدم نفس لوحات المعلومات واستعلامات السجل لتحقيق إمكانية ملاحظة متسقة خلال الفترة الانتقالية.
4. تحويل حركة المرور إلى الكتلة الجديدة
بالنسبة إلى GitLab.com ، يتم تخصيص بعض الخوادم ضمن . يخدم Canary Park مشاريعنا الداخلية ويمكنه أيضًا . لكنها مصممة بشكل أساسي لاختبار التغييرات في البنية التحتية والتطبيق. بدأت الخدمة الأولى التي تم ترحيلها بقبول كمية محدودة من حركة المرور الداخلية ، ونستمر في استخدام هذه الطريقة لضمان تلبية SLO قبل دفع كل حركة المرور إلى الكتلة.
في حالة الترحيل ، هذا يعني أنه يتم إرسال الطلبات الأولى للمشاريع الداخلية إلى Kubernetes ، ثم نقوم تدريجياً بتحويل بقية حركة المرور إلى الكتلة عن طريق تغيير وزن الواجهة الخلفية من خلال HAProxy. أثناء الانتقال من VM إلى Kubernetes ، أصبح من الواضح أنه من المفيد جدًا وجود طريقة سهلة لإعادة توجيه حركة المرور بين البنية التحتية القديمة والجديدة ، وبالتالي ، الحفاظ على البنية التحتية القديمة جاهزة للتراجع في الأيام القليلة الأولى بعد الترحيل.
5. الطاقة الاحتياطية للقرون واستخدامها
على الفور تقريبًا ، تم تحديد المشكلة التالية: بدأت كبسولات خدمة التسجيل بسرعة ، لكن إطلاق البودات لـ Sidekiq استغرق ما يصل إلى . أصبحت كبسولات Sidekiq التي تعمل لفترة طويلة مشكلة عندما بدأنا في ترحيل أعباء العمل إلى Kubernetes للعمال الذين يحتاجون إلى معالجة الوظائف بسرعة وتوسيع نطاقها بسرعة.
في هذه الحالة ، كان الدرس هو أنه في حين أن جهاز القياس التلقائي الأفقي (HPA) في Kubernetes يتعامل مع نمو حركة المرور بشكل جيد ، فمن المهم مراعاة خصائص عبء العمل وتخصيص سعة حجرة احتياطية (خاصة عندما يكون الطلب غير متساوٍ). في حالتنا ، كان هناك اندفاع مفاجئ في الوظائف ، مما أدى إلى التوسع السريع ، مما أدى إلى تشبع موارد وحدة المعالجة المركزية قبل أن نتمكن من توسيع نطاق مجموعة العقد.
من المغري دائمًا الضغط على أكبر قدر ممكن من الكتلة ، ومع ذلك فقد واجهنا مشكلات في الأداء في البداية ونبدأ الآن بميزانية جراب سخية وخفضها لاحقًا ، مع مراقبة SLO عن كثب. لقد تم تسريع إطلاق البودات لخدمة Sidekiq بشكل كبير ويستغرق الآن حوالي 40 ثانية في المتوسط. فازت بكل من GitLab.com ومستخدمينا للمنشآت ذاتية الإدارة التي تدير مخطط GitLab Helm Chart الرسمي.
اختتام
بعد ترحيل كل خدمة ، ابتهجنا بفوائد استخدام Kubernetes في الإنتاج: نشر التطبيقات بشكل أسرع وأكثر أمانًا ، وتوسيع نطاقها ، وتخصيص موارد أكثر كفاءة. علاوة على ذلك ، تتجاوز مزايا الترحيل خدمة GitLab.com. مع كل تحسين على مخطط Helm الرسمي ، يستفيد مستخدموه أيضًا.
أتمنى أن تكون قد استمتعت بقصة مغامرتنا للهجرة Kubernetes. نستمر في ترحيل جميع الخدمات الجديدة إلى المجموعة. يمكن العثور على معلومات إضافية في المنشورات التالية:
- «"؛
- «"؛
- .
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com