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