في الأسبوع الماضي ،
تم الإعلان عن إطلاق خدمات Reddit الجديدة من الآن فصاعدًا على بنية تحتية تعتمد على مجموعات Kubernetes. يعد هذا معلمًا هامًا على طريق الترحيل إلى K8s لأحد أكثر الموارد شعبية على الإنترنت ، وإليك كيفية الوصول إلى ...
Likbez : حتى الآن ، رديت في أفضل 20 موقعًا عالميًا (والرقم 6 في الولايات المتحدة) وفقًا لـ Alexa . يضم هذا المجتمع عبر الإنترنت من أصل أمريكي أكثر من 400 مليون مستخدم نشط (خلال شهر واحد) و 12 مليون منشور و 2 مليار صوت يوميًا.حول سبب وكيفية وصول مهندسي Reddit إلى Kubernetes ، في ديسمبر الماضي في KubeCon 2018
( عرض تقديمي + فيديو ) جريج تايلور ، رئيس مجموعة هندسة إطلاق هندسة المشاريع ، قسم البنية التحتية.
لماذا أتيت إلى كوبيرنيتيس؟
في بداية عام 2016 ، كانت الخدمة ، التي تم تنفيذها كتطبيق
مترابط ، تضم حوالي 20 مهندسًا فقط من 3 فرق ، أحدهم بطل القصة - فريق البنية التحتية. ومع ذلك ، أحدث هذا العام تغييرات كبيرة: بحلول نهاية العام ، كان أكثر من 60 مهندسًا يعملون في الشركة (وبحلول نهاية عام 2018 ، ارتفع عددهم إلى 200 ، أي في
3 سنوات فقط
، كانت هناك زيادة بمقدار 10 أضعاف في عدد الموظفين ).
وضعت معدلات النمو السريع هذه على جدول الأعمال عدم ملاءمة (عدم كفاءة) بنية التطبيقات المتجانسة ، حيث أصبح إجراء العديد من التغييرات على مكوناتها المختلفة (بواسطة فرق مختلفة) أمرًا بالغ الصعوبة. بعد أن تجمعوا لحل المشكلة والنظر في العديد من الخيارات ، اختار المهندسون
طريق الهندسة المعمارية الموجهة نحو الخدمة (SOA) .
التبديل إلى بنية خدمة بدلاً من متراصة كبيرة ، واجهت Reddit مشكلة جديدة.
أصبح فريق البنية التحتية عنق الزجاجة في أنشطة المطورين الذين تحولوا إلى اعتماد كبير عليه في مراحل مختلفة: أثناء تهيئة الخدمات ، وأثناء تشغيلها المستمر ، وأثناء تصحيح الأخطاء وحل مشكلات الأداء. كحل سريع للمشكلة ، شكلت الشركة فرقًا أكثر اكتفاءً ذاتيًا تسمى "موجهة للبنية التحتية": كان لدى المشاركين في هذه الفرق المهارات اللازمة في مجال تشغيل البنية التحتية ، مما أتاح لهم التغلب على العديد من الصعوبات دون انتظار تصرفات فريق البنية التحتية ، والتي كانت محملة بتراكم لا نهاية له من العديد من المطورين.
ومع ذلك ، كان لا يزال حلاً مؤقتًا وأظهرت الممارسة أنه لا يريد الجميع تشغيل المكدس بالكامل لخدمتهم:
كيف تم حل هذا الوضع؟ قدمت المنظمة مفهوم
أصحاب الخدمة ، الذين يمكنهم
تطوير خدمتهم من البداية إلى النهاية ،
ونشر الخدمة في وقت مبكر ، وغالبا ما تقوم
بتشغيل الخدمة (بما في ذلك مشكلات توفرها وأدائها). ولكن كيف لتحقيق هذا؟
بدلاً من توقع أن تقوم فرق من المهندسين ذوي المهارات التي لا تشوبها شائبة بدمج الخدمات معًا من عشرات الطوب ، والتي قد لا يكون لدى الكثير منهم معرفة ، يجب عليك أن تقدم لهم مسارًا مدروسًا مسبقًا ومحددة مسبقًا لتقديم الخدمات إلى الإنتاج ، مما يؤثر على الحد الأدنى من التكنولوجيا. سيوفر هذا المهندسين من الاضطرار إلى تعلم العديد من التقنيات والأدوات الجديدة ، والتي يمكن أن تكون كثيرة:
"من أجل وضع هذه الفكرة موضع التنفيذ ، نحتاج إلى" تجميع "معرفتنا وعمليةنا وأفضل الممارسات وأكثر من ذلك بكثير في شكل يسهل الوصول إليه."
InfreRedd - Kubernetes في رديت
هذه هي الطريقة التي ظهرت بها InfreRedd ، منتج البنية التحتية الداخلية لـ Reddit ، والمبني على Kubernetes.
كيف تم تلبية الاحتياجات الثلاثة لأصحاب الخدمة المحددة في تعريفهم؟
1. التنمية
لا يشير معيار التطوير في المؤسسة إلى اختيار لغة معينة أو إطار عمل معين ، ولكنه يحدد "الشكل" العام للخدمة ، الذي يجب أن يتوافق معه. يتضمن المعيار -
وهو مواصفات خدمة مستقلة عن لغة البرمجة - تعريف بروتوكول RPC ، والعمل مع الأسرار ، وإرجاع المقاييس ، وإمكانية التتبع ، وتنسيق إصدار السجلات. مثال على تنفيذ مثل هذه المواصفات في Python يمكن العثور عليه في مشروع
اللوح الأساس ، والذي ، مع ذلك ، من غير المرجح أن يكون مفيدًا لشخص ما للاستخدام الفعلي ، ولكن يمكن أن يكون مصدر إلهام.
بالإضافة إلى ذلك ، تم إنشاء المواد لبداية سريعة عند كتابة خدمات جديدة: رموز كعب برمجية للغات مختلفة (Python و Go و Node) وكذلك Dockerfile وتهيئة مخططات CI وحتى Helm.
للمساعدة في التطوير المحلي ، وقع اختيار مهندسي Reddit على منتج Google -
Skaffold ، والذي يوفر للمطورين
تعديلًا لدورة
القراءة → ← إعادة
الإنشاء ← التحديث ، والذي:
- لا يتطلب معرفة متعمقة من Kubernetes ؛
- أقرب ما يمكن إلى الإنتاج ؛
- يسمح لك باستخدام الرسوم البيانية / الصور القياسية ؛
- - على عكس Minikube الذي تم استخدامه من قبل - لا يتطلب العمل مع Skaffold موارد ضخمة من أجهزة الكمبيوتر المحمولة العاملة (نظرًا لأن التشغيل التجريبي يتم على مجموعات عن بُعد).
2. نشر
يستخدم Reddit منصة التسليم المستمر
Drone لتشغيل الاختبارات وبناء القطع الأثرية (عادةً صور Docker).
كان Kubernetes يستخدم أصلاً المكون الإضافي Helm لـ Drone للنشر ، ولكن بسرعة كبيرة توصل المهندسون إلى أن Helm لم يكن راضيًا عنهم لأنهم أرادوا نظامًا "يفهم بشكل أفضل حالة الكائنات التي تم إنشاؤها أو المحدثة" ، وأدى التشغيل الآلي لعمليات النشر إلى الحاجة إلى حل يمكن أن يروق للأدوات المستخدمة وإيقاف الاستعادة مؤقتًا إذا حدثت مشكلات فشل أو أداء.
نتيجة لذلك ، تم اختيار
Spinnaker لتنظيم عملية النشر في Kubernetes. بالنسبة له ، تم إنشاء قوالب لخطوط الأنابيب النموذجية (على Jsonnet). بعد ذلك ، يتم إنشاء مخططات Helm ، والتي تم طرحها بالفعل في Kubernetes
بواسطة Spinnaker. يتلقى المستخدمون معلومات عن التقدم المحرز في النشر ويساعدون في التشخيص في حالة حدوث أي مشاكل. إليك ما تبدو عليه عملية النشر النموذجية في التدريج / الإنتاج بطريقة عامة جدًا:
3. العملية
أولاً ، كيف يتم تقاسم التزامات أصحاب الخدمة وفريق البنية التحتية؟
- أصحاب الخدمات : فهم أساسيات Kubernetes ونشر وتشغيل خدماتهم ؛
- فريق البنية التحتية : الحفاظ على قابلية تشغيل مجموعات Kubernet (التشغيل ، والدعم ، والتوسع) ، وتزويدهم بجميع الموارد اللازمة ، وإسداء النصح لمهندسي المنظمة على تصميم خدمات موثوقة ومثمرة ومتسامحة مع الأخطاء (على وجه الخصوص ، تُعقد الدورات التدريبية بانتظام ، ويتم بعد ذلك توزيع السجلات في جميع أنحاء الشركة).
أصحاب الخدمات محدودون في حقوقهم. ومع ذلك ، للوصول إلى الإنتاج (لتشخيص المشكلة) ، من الممكن أن تطلب (من خلال أداة مساعدة خاصة في وحدة التحكم) رمزًا مؤقتًا مؤقتًا يمنحهم الحقوق الكاملة لمساحات الأسماء الخاصة بهم.
نقطة مهمة أخرى للتشغيل هي التقليل إلى الحد الأدنى من الأضرار المحتملة التي قد تأتي من مصادر مختلفة. إليك ما يفعله Reddit لهذا:
لجعل الحياة أسهل للمهندسين المشاركين في العملية ، يتم تضمين ما يلي أيضًا:
حالة Kubernetes في رديت
فيما يلي إحصاءات عامة عن البنية التحتية لشركة Kubernetes في شهر ديسمبر من العام الماضي:
- 7 مجموعات (من 3 إلى 6 مجموعات جديدة ستضاف في الأشهر القليلة المقبلة) ؛
- يتفاعل ثلث جميع الفرق الهندسية مع Kubernetes ؛
- حوالي 20 خدمة Reddit في الإنتاج مع K8s ؛
- في يوم عمل ، يتم نشر 10-20 من هذه الخدمات إلى K8s.
تم التخطيط لتوفير InfreRedd مع Kubernetes للمؤسسة بأكملها في الربع الأول من عام 2019 ، مما يعني ضمناً نشر أي خدمة جديدة في الإنتاج تخدمها Kubernetes.
(في ذلك الوقت ، كان هذا يحدث لحوالي 3 من 4 خدمات جديدة.)كما ذكر في بداية المقال ، تم الوصول إلى هذا الإنجاز بنجاح في الأسبوع الماضي فقط:
مقالات أخرى من الدورة