على مر السنين، أنشأ مستخدمو Pinterest البالغ عددهم 300 مليون أكثر من 200 مليار دبوس على أكثر من 4 مليارات لوحة. ولخدمة هذا الجيش من المستخدمين وقاعدة المحتوى الواسعة، طورت البوابة آلاف الخدمات، بدءًا من الخدمات الصغيرة التي يمكن التعامل معها بواسطة عدد قليل من وحدات المعالجة المركزية (CPUs)، إلى وحدات متراصة عملاقة تعمل على أسطول كامل من الأجهزة الافتراضية. ثم جاءت اللحظة التي وقعت فيها أعين الشركة على k8s. لماذا يبدو "المكعب" جيدًا على موقع Pinterest؟ سوف تتعلم عن هذا من خلال ترجمتنا لمقالة حديثة من .
لذلك، مئات الملايين من المستخدمين ومئات المليارات من الدبابيس. ولخدمة هذا الجيش من المستخدمين وقاعدة المحتوى الواسعة، قمنا بتطوير آلاف الخدمات، بدءًا من الخدمات الصغيرة التي يمكن التعامل معها بواسطة عدد قليل من وحدات المعالجة المركزية (CPUs)، إلى وحدات متراصة عملاقة تعمل على أساطيل كاملة من الأجهزة الافتراضية. بالإضافة إلى ذلك، لدينا مجموعة متنوعة من أطر العمل التي قد تتطلب أيضًا الوصول إلى وحدة المعالجة المركزية أو الذاكرة أو الإدخال/الإخراج.
في الحفاظ على مجموعة الأدوات هذه، يواجه فريق التطوير عددًا من التحديات:
- لا توجد طريقة موحدة للمهندسين لإدارة بيئة الإنتاج. تعتمد الخدمات عديمة الحالة والخدمات والمشاريع ذات الحالة قيد التطوير النشط على مجموعات تقنية مختلفة تمامًا. أدى ذلك إلى إنشاء دورة تدريبية كاملة للمهندسين، كما أدى إلى تعقيد عمل فريق البنية التحتية لدينا بشكل خطير.
- يشكل المطورون الذين يمتلكون أسطولهم الخاص من الأجهزة الافتراضية عبئًا كبيرًا على المسؤولين الداخليين. ونتيجة لذلك، تستغرق العمليات البسيطة مثل تحديث نظام التشغيل أو AMI أسابيع وأشهر. يؤدي هذا إلى زيادة عبء العمل في مواقف تبدو يومية تمامًا.
- صعوبات في إنشاء أدوات عالمية لإدارة البنية التحتية بالإضافة إلى الحلول الحالية. ومما يزيد الوضع تعقيدًا حقيقة أن العثور على مالكي الأجهزة الافتراضية ليس بالأمر السهل. أي أننا لا نعرف ما إذا كان من الممكن استخراج هذه القدرة بشكل آمن للعمل في أجزاء أخرى من بنيتنا التحتية.
تعد أنظمة تنسيق الحاويات وسيلة لتوحيد إدارة عبء العمل. إنها تفتح الباب أمام زيادة سرعة التطوير وتبسيط إدارة البنية التحتية، حيث تتم إدارة جميع الموارد المشاركة في المشروع من خلال نظام مركزي واحد.
الشكل 1: أولويات البنية التحتية (الموثوقية وإنتاجية المطورين والكفاءة).
اكتشف فريق منصة إدارة السحابة في Pinterest K8s في عام 2017. بحلول النصف الأول من عام 2017، قمنا بتوثيق معظم قدراتنا الإنتاجية، بما في ذلك واجهة برمجة التطبيقات (API) وجميع خوادم الويب الخاصة بنا. بعد ذلك، أجرينا تقييمًا شاملاً للأنظمة المختلفة لتنسيق حلول الحاويات وبناء المجموعات والعمل معها. في نهاية عام 2017، قررنا استخدام Kubernetes. لقد كانت مرنة للغاية ومدعومة على نطاق واسع في مجتمع المطورين.
حتى الآن، قمنا ببناء أدوات التمهيد العنقودية الخاصة بنا استنادًا إلى Kops وقمنا بترحيل مكونات البنية التحتية الحالية مثل الشبكات والأمان والمقاييس والتسجيل وإدارة الهوية وحركة المرور إلى Kubernetes. لقد قمنا أيضًا بتنفيذ نظام نمذجة عبء العمل لموردنا، والذي تم إخفاء تعقيده عن المطورين. نحن نركز الآن على ضمان استقرار المجموعة وتوسيع نطاقها وربط العملاء الجدد.
Kubernetes: طريق بينتريست
إن بدء استخدام Kubernetes على نطاق Pinterest كمنصة يحبها مهندسونا كان مصحوبًا بالكثير من التحديات.
باعتبارنا شركة كبيرة، فقد استثمرنا بشكل كبير في أدوات البنية التحتية. تتضمن الأمثلة أدوات الأمان التي تتعامل مع معالجة الشهادات وتوزيع المفاتيح، ومكونات التحكم في حركة المرور، وأنظمة اكتشاف الخدمة، ومكونات الرؤية، ومكونات إرسال السجل والمقاييس. تم جمع كل هذا لسبب ما: لقد مررنا بالمسار الطبيعي للتجربة والخطأ، وبالتالي أردنا دمج كل هذه المعدات في البنية التحتية الجديدة على Kubernetes بدلاً من إعادة اختراع العجلة القديمة على منصة جديدة. أدى هذا الأسلوب بشكل عام إلى تبسيط عملية الترحيل، نظرًا لأن كل دعم التطبيقات موجود بالفعل ولا يلزم إنشاؤه من البداية.
من ناحية أخرى، فإن نماذج التنبؤ بالأحمال في Kubernetes نفسها (مثل عمليات النشر والوظائف ومجموعات Daemon) ليست كافية لمشروعنا. تمثل مشكلات قابلية الاستخدام هذه عوائق كبيرة أمام الانتقال إلى Kubernetes. على سبيل المثال، سمعنا أن مطوري الخدمة يشكون من إعدادات تسجيل الدخول المفقودة أو غير الصحيحة. لقد واجهنا أيضًا استخدامًا غير صحيح لمحركات القوالب، حيث تم إنشاء مئات النسخ بنفس المواصفات والمهمة، مما أدى إلى مشكلات تصحيح الأخطاء الكابوسية.
كما كان من الصعب جدًا الاحتفاظ بإصدارات مختلفة في نفس المجموعة. تخيل مدى تعقيد دعم العملاء إذا كنت بحاجة إلى العمل في وقت واحد في إصدارات متعددة من نفس بيئة التشغيل، مع كل المشاكل والأخطاء والتحديثات.
خصائص المستخدم ووحدات التحكم في Pinterest
لتسهيل قيام مهندسينا بتنفيذ Kubernetes، ولتبسيط البنية التحتية لدينا وتسريعها، قمنا بتطوير تعريفات الموارد المخصصة (CRDs) الخاصة بنا.
توفر CRDs الوظائف التالية:
- الجمع بين موارد Kubernetes الأصلية المختلفة بحيث تعمل كعبء عمل واحد. على سبيل المثال، يتضمن مورد PinterestService عملية نشر وخدمة تسجيل دخول وخريطة تكوين. وهذا يسمح للمطورين بعدم القلق بشأن إعداد DNS.
- تنفيذ دعم التطبيق اللازم. يحتاج المستخدم إلى التركيز فقط على مواصفات الحاوية وفقًا لمنطق أعماله، بينما تقوم وحدة التحكم CRD بتنفيذ جميع حاويات init الضرورية ومتغيرات البيئة ومواصفات pod. وهذا يوفر مستوى مختلفًا تمامًا من الراحة للمطورين.
- تقوم وحدات تحكم CRD أيضًا بإدارة دورة حياة الموارد الأصلية وتحسين توفر تصحيح الأخطاء. يتضمن ذلك التوفيق بين المواصفات المطلوبة والفعلية، وتحديث حالة CRD والاحتفاظ بسجلات الأحداث، والمزيد. بدون CRD، سيضطر المطورون إلى إدارة موارد متعددة، الأمر الذي لن يؤدي إلا إلى زيادة احتمالية الخطأ.
فيما يلي مثال على PinterestService ومورد داخلي تتم إدارته بواسطة وحدة التحكم لدينا:
كما ترون أعلاه، لدعم حاوية مخصصة، نحتاج إلى دمج حاوية init والعديد من الوظائف الإضافية لتوفير الأمان والرؤية وحركة مرور الشبكة. بالإضافة إلى ذلك، قمنا بإنشاء قوالب خريطة التكوين وتنفيذ الدعم لقوالب PVC للمهام المجمعة، بالإضافة إلى تتبع متغيرات البيئة المتعددة لتتبع الهوية واستهلاك الموارد وجمع البيانات المهملة.
من الصعب أن نتخيل أن المطورين قد يرغبون في كتابة ملفات التكوين هذه يدويًا دون دعم CRD، ناهيك عن صيانة التكوينات وتصحيح أخطائها.
سير عمل نشر التطبيق
توضح الصورة أعلاه كيفية نشر مورد Pinterest المخصص إلى مجموعة Kubernetes:
- يتفاعل المطورون مع مجموعة Kubernetes الخاصة بنا من خلال واجهة سطر الأوامر (CLI) وواجهة المستخدم.
- تقوم أدوات CLI/UI باسترداد ملفات YAML لتكوين سير العمل وخصائص البناء الأخرى (نفس معرف الإصدار) من Artifactory ثم إرسالها إلى خدمة تقديم الوظائف. تضمن هذه الخطوة تسليم إصدارات الإنتاج فقط إلى المجموعة.
- JSS هي بوابة لمنصات مختلفة، بما في ذلك Kubernetes. هنا تتم مصادقة المستخدم، ويتم إصدار الحصص ويتم فحص تكوين CRD الخاص بنا جزئيًا.
- بعد التحقق من CRD على جانب JSS، يتم إرسال المعلومات إلى واجهة برمجة تطبيقات منصة k8s.
- تقوم وحدة التحكم CRD الخاصة بنا بمراقبة الأحداث على جميع موارد المستخدم. يقوم بتحويل CRs إلى موارد k8s الأصلية، ويضيف الوحدات الضرورية، ويحدد متغيرات البيئة المناسبة، وينفذ أعمال دعم أخرى لضمان أن تطبيقات المستخدم الموجودة في حاويات تتمتع بدعم كافٍ للبنية التحتية.
- تقوم وحدة التحكم CRD بعد ذلك بتمرير البيانات المستلمة إلى Kubernetes API بحيث يمكن معالجتها بواسطة المجدول ووضعها في الإنتاج.
لاحظ: تم إنشاء تدفق عمل النشر المسبق هذا للمستخدمين الأوائل لمنصة k8s الجديدة. نحن حاليًا بصدد تحسين هذه العملية للتكامل الكامل مع CI/CD الجديد الخاص بنا. هذا يعني أنه لا يمكننا إخبارك بكل ما يتعلق بـ Kubernetes. ونحن نتطلع إلى مشاركة خبرتنا والتقدم الذي أحرزه الفريق في هذا الاتجاه في منشور مدونتنا التالي، "إنشاء منصة CI/CD لـ Pinterest".
أنواع الموارد الخاصة
استنادًا إلى احتياجات Pinterest المحددة، قمنا بتطوير CRDs التالية لتناسب سير العمل المختلفة:
- PinterestService هي خدمات عديمة الحالة تم تشغيلها لفترة طويلة. تعتمد العديد من أنظمتنا الأساسية على مجموعة من هذه الخدمات.
- نماذج PinterestJobSet لوظائف الدفعات ذات الدورة الكاملة. أحد السيناريوهات الشائعة على موقع Pinterest هو أن المهام المتعددة تقوم بتشغيل نفس الحاويات بالتوازي، بغض النظر عن العمليات المماثلة الأخرى.
- يُستخدم PinterestCronJob على نطاق واسع مع الأحمال الدورية الصغيرة. هذا عبارة عن غلاف لعمل cron الأصلي مع آليات دعم Pinterest المسؤولة عن الأمان وحركة المرور والسجلات والمقاييس.
- يشمل PinterestDaemon البنية التحتية الشياطين. تستمر هذه العائلة في النمو حيث نضيف المزيد من الدعم لمجموعاتنا.
- يمتد PinterestTrainingJob إلى عمليات Tensorflow وPytorch، مما يوفر نفس مستوى دعم وقت التشغيل مثل جميع CRDs الأخرى. نظرًا لأن Pinterest يستخدم Tensorflow وأنظمة التعلم الآلي الأخرى بشكل نشط، فقد كان لدينا سبب لإنشاء CRD منفصل حولها.
نحن نعمل أيضًا على PinterestStatefulSet، والذي سيتم تكييفه قريبًا ليناسب مستودعات البيانات والأنظمة ذات الحالة الأخرى.
دعم وقت التشغيل
عند تشغيل حجرة تطبيق على Kubernetes، فإنها تتلقى تلقائيًا شهادة لتعريف نفسها. تُستخدم هذه الشهادة للوصول إلى التخزين السري أو للتواصل مع الخدمات الأخرى عبر mTLS. وفي الوقت نفسه، سيقوم Container Init Configurator وDaemon بتنزيل جميع التبعيات الضرورية قبل تشغيل التطبيق الموجود في الحاوية. عندما يكون كل شيء جاهزًا، ستقوم عربة المرور الجانبية وDaemon بتسجيل عنوان IP الخاص بالوحدة مع Zookeeper حتى يتمكن العملاء من اكتشافه. كل هذا سيعمل لأنه تم تكوين وحدة الشبكة قبل بدء تشغيل التطبيق.
ما سبق هو أمثلة نموذجية لدعم وقت التشغيل لأحمال العمل. قد تتطلب الأنواع الأخرى من أعباء العمل دعمًا مختلفًا قليلًا، ولكنها جميعًا تأتي في شكل ملفات جانبية على مستوى الكبسولة، أو على مستوى العقدة، أو على مستوى الجهاز الظاهري. نحن نضمن أن يتم نشر كل هذا داخل البنية التحتية للإدارة ويكون متسقًا عبر التطبيقات، مما يؤدي في النهاية إلى تقليل العبء بشكل كبير فيما يتعلق بالعمل الفني ودعم العملاء.
الاختبار وضمان الجودة
لقد قمنا ببناء خط أنابيب اختبار شامل فوق البنية التحتية الحالية لاختبار Kubernetes. تنطبق هذه الاختبارات على جميع مجموعاتنا. لقد مر خط الأنابيب الخاص بنا بالعديد من المراجعات قبل أن يصبح جزءًا من مجموعة المنتجات.
بالإضافة إلى أنظمة الاختبار، لدينا أنظمة مراقبة وتنبيه تراقب باستمرار حالة مكونات النظام واستهلاك الموارد وغيرها من المؤشرات المهمة، ولا تبلغنا إلا عندما يكون التدخل البشري ضروريًا.
البدائل
لقد بحثنا في بعض البدائل للموارد المخصصة، مثل وحدات التحكم في الوصول للطفرة وأنظمة القوالب. ومع ذلك، فإنها جميعًا تواجه تحديات تشغيلية كبيرة، لذلك اخترنا طريق CRD.
تم استخدام وحدة التحكم بالقبول الطفري لتقديم السيارات الجانبية ومتغيرات البيئة ودعم وقت التشغيل الآخر. ومع ذلك، فقد واجهت مشاكل مختلفة، مثل ربط الموارد وإدارة دورة الحياة، حيث لا تنشأ مثل هذه المشاكل في CRD.
ملاحظة: تُستخدم أيضًا أنظمة القوالب مثل مخططات Helm على نطاق واسع لتشغيل التطبيقات ذات التكوينات المشابهة. ومع ذلك، فإن تطبيقات العمل لدينا متنوعة للغاية بحيث لا يمكن إدارتها باستخدام القوالب. وأيضًا أثناء النشر المستمر، سيكون هناك الكثير من الأخطاء عند استخدام القوالب.
العمل القادم
نحن نتعامل حاليًا مع حمل مختلط عبر جميع مجموعاتنا. ولدعم مثل هذه العمليات بمختلف أنواعها وأحجامها، فإننا نعمل في المجالات التالية:
- تقوم مجموعة من المجموعات بتوزيع التطبيقات الكبيرة عبر مجموعات مختلفة من أجل قابلية التوسع والاستقرار.
- ضمان استقرار المجموعة وقابلية التوسع والرؤية لإنشاء اتصال التطبيقات واتفاقيات مستوى الخدمة.
- إدارة الموارد والحصص بحيث لا تتعارض التطبيقات مع بعضها البعض، ويتم التحكم في حجم المجموعة من جانبنا.
- منصة CI/CD جديدة لدعم ونشر التطبيقات على Kubernetes.
المصدر: www.habr.com