تقريبا. العابرة. : Dailymotion هي واحدة من أكبر خدمات استضافة الفيديو في العالم ، وبالتالي فهي مستخدم بارز في Kubernetes. في هذه المقالة ، يشارك مهندس النظام David Donchez نتائج إنشاء منصة إنتاج للشركة استنادًا إلى K8s ، والتي بدأت بعملية تثبيت سحابية في GKE وانتهت كحل هجين ، مما أتاح تحقيق وقت رد فعل أفضل وتوفير تكاليف البنية التحتية.عندما قررنا إعادة بناء واجهة برمجة تطبيقات
Dailymotion الأساسية قبل ثلاث سنوات ، أردنا تطوير طريقة أكثر فعالية لاستضافة التطبيقات وتيسير
عمليات التطوير والإنتاج . لهذا الغرض ، قررنا استخدام منصة تزامن الحاوية واخترنا Kubernetes بشكل طبيعي.
لماذا يستحق إنشاء منصة Kubernetes الخاصة بك؟
واجهة برمجة تطبيقات مستوى الإنتاج في أقرب وقت ممكن باستخدام Google Cloud
صيف 2016
قبل ثلاث سنوات ، مباشرة بعد أن اشترت
Vivendi Dailymotion ، ركزت فرقنا الهندسية على هدف عالمي واحد: إنشاء منتج جديد تمامًا Dailymotion.
استنادًا إلى تحليل الحاويات وحلول الأوركسترا وتجربتنا السابقة ، تأكدنا من أن Kubernetes هو الخيار الصحيح. كان لدى بعض المطورين بالفعل فكرة عن المفاهيم الأساسية ويعرفون كيفية استخدامها ، والتي كانت ميزة كبيرة لتحويل البنية التحتية.
من وجهة نظر البنية التحتية ، كان يلزم وجود نظام قوي ومرن لاستضافة أنواع جديدة من التطبيقات السحابية الأصلية. لقد اخترنا البقاء في السحابة في بداية رحلتنا من أجل بناء منصة محلية موثوقة بهدوء. قرروا نشر تطبيقاتهم باستخدام Google Kubernetes Engine ، على الرغم من أنهم يعلمون أننا عاجلاً أم آجلاً سنتحول إلى مراكز البيانات الخاصة بنا ونطبق استراتيجية مختلطة.
لماذا تختار GKE؟
لقد اتخذنا هذا الاختيار بشكل رئيسي لأسباب فنية. بالإضافة إلى ذلك ، كان من الضروري توفير البنية التحتية التي تلبي احتياجات أعمال الشركة بسرعة. كان لدينا بعض متطلبات التطبيق ، مثل التوزيع الجغرافي ، والتدرجية ، والتسامح مع الخطأ.
مجموعات GKE في ديلي موشننظرًا لأن Dailymotion عبارة عن منصة فيديو متوفرة في جميع أنحاء العالم ، فقد أردنا حقًا تحسين جودة الخدمة من خلال تقليل
زمن الوصول . في السابق ، كانت
واجهة برمجة التطبيقات متوفرة فقط في باريس ، والتي لم تكن مثالية. أردت أن أكون قادرًا على استضافة التطبيقات ليس فقط في أوروبا ، ولكن أيضًا في آسيا والولايات المتحدة.
تعني هذه الحساسية للتأخيرات أنه سيتعين علينا العمل بجدية على بنية شبكة النظام الأساسي. في حين أن معظم الخدمات السحابية أرغمتهم على إنشاء شبكة خاصة بهم في كل منطقة ثم توصيلهم عبر VPN أو خدمة معينة مُدارة ، أتاحت Google Cloud إنشاء شبكة موحدة قابلة للتوجيه بالكامل تغطي جميع مناطق Google. هذا هو زائد كبيرة من حيث التشغيل وكفاءة النظام.
بالإضافة إلى ذلك ، تقوم خدمات الشبكة وموازنات التحميل من Google Cloud بعمل ممتاز. إنها تتيح لك ببساطة استخدام عناوين IP العامة التعسفية من كل منطقة ، ويتولى بروتوكول BGP الرائع الاهتمام بالباقي (أي ، إعادة توجيه المستخدمين إلى أقرب مجموعة). من الواضح ، في حالة حدوث عطل ، سوف تنتقل حركة المرور تلقائيًا إلى منطقة أخرى دون أي تدخل بشري.
جوجل تحميل موازنة الرصدكما تستخدم منصتنا بنشاط معالجات الرسومات. Google Cloud يجعلها فعالة للغاية لاستخدامها مباشرة في مجموعات Kubernetes.
في ذلك الوقت ، ركز فريق البنية التحتية بشكل أساسي على المكدس القديم الذي تم نشره على الخوادم الفعلية. هذا هو السبب في أن استخدام الخدمة المدارة (بما في ذلك المكونات الرئيسية لـ Kubernetes) يفي بمتطلباتنا ويسمح لنا بتدريب الفرق على العمل مع المجموعات المحلية.
ونتيجة لذلك ، تمكنا من بدء قبول حركة الإنتاج على بنية Google Cloud الأساسية بعد 6 أشهر فقط من بدء العمل.
ومع ذلك ، على الرغم من عدد من المزايا ، يرتبط العمل مع مزود خدمة السحاب بتكاليف معينة ، والتي يمكن أن تزيد حسب الحمل. هذا هو السبب في أننا قمنا بتحليل كل خدمة مُدارة مستخدمة بعناية ، على أمل تنفيذها في أماكن العمل في المستقبل. في الواقع ، بدأ إدخال التجمعات المحلية في نهاية عام 2016 ، وفي الوقت نفسه تم إطلاق إستراتيجية مختلطة.
إطلاق منصة Dailymotion المحلية لتنسيق الحاويات
خريف 2016
في الظروف التي تكون فيها المجموعة الكاملة جاهزة للإنتاج ،
واستمر العمل على واجهة برمجة التطبيقات ، كان هناك وقت للتركيز على المجموعات الإقليمية.
في ذلك الوقت ، شاهد المستخدمون أكثر من 3 مليارات مقطع فيديو شهريًا. بالطبع ، نحن ندير شبكة توصيل المحتوى المتفرعة الخاصة بنا لسنوات. أردنا الاستفادة من هذا الظرف ونشر مجموعات Kubernetes في مراكز البيانات الحالية.
بلغ إجمالي البنية التحتية لـ Dailymotion أكثر من 2.5 ألف خادم في ستة مراكز بيانات. يتم تكوين جميع باستخدام Saltstack. بدأنا في إعداد جميع الوصفات اللازمة لإنشاء العقد الرئيسية والعامل ، وكذلك مجموعة etcd.
جزء الشبكة
شبكتنا قابلة للتوجيه بشكل كامل. يعلن كل خادم IP الخاص به على الشبكة باستخدام Exabgp. قارنا العديد من المكونات الإضافية للشبكة وكان
Calico هو الوحيد الذي يلبي جميع الاحتياجات (نظرًا للنهج المستخدم في المستوى L3). تناسبها تماما في نموذج البنية التحتية للشبكة الحالية.
نظرًا لأنني أردت استخدام جميع عناصر البنية التحتية المتاحة ، بادئ ذي بدء ، اضطررت إلى التعامل مع الأداة المساعدة للشبكة المحلية (المستخدمة على جميع الخوادم): استخدمها للإعلان عن نطاقات عناوين IP على شبكة بها عقد Kubernetes. سمحنا لـ Calico بتعيين عناوين IP للقرون ، لكننا لم نستخدمها ولا نستخدمها لجلسات BGP على أجهزة الشبكة. في الواقع ، يتم معالجة التوجيه بواسطة Exabgp ، والتي تعلن عن الشبكات الفرعية التي يستخدمها Calico. هذا يتيح لنا الوصول إلى أي جراب من الشبكة الداخلية (وخاصة من موازنات التحميل).
كيف ندير حركة المرور
لإعادة توجيه الطلبات الواردة إلى الخدمة المطلوبة ، تقرر استخدام Ingress Controller نظرًا لتكاملها مع موارد إدخال Kubernetes.
منذ ثلاث سنوات ، كانت وحدة التحكم nginx-ingress هي أكثر أدوات التحكم نضجًا: لقد تم استخدام Nginx لفترة طويلة وكان معروفًا بثباته وأدائه.
في نظامنا ، قررنا وضع وحدات التحكم على خوادم نصلية ذات 10 جيجابت. تم توصيل كل وحدة تحكم بنقطة النهاية الخاصة بـ kube-apiserver في المجموعة المقابلة. تم استخدام Exabgp أيضًا على هذه الخوادم للإعلان عن عناوين IP العامة أو الخاصة. يسمح لنا طبولوجيا شبكتنا باستخدام BGP من وحدات التحكم هذه لتوجيه كل حركة المرور مباشرة إلى السنفات دون استخدام خدمة مثل NodePort. هذا النهج يساعد على تجنب حركة المرور الأفقية بين العقد ويحسن الكفاءة.
حركة المرور من الإنترنت إلى القرونالآن وبعد أن اكتشفت نظامنا الأساسي المختلط ، يمكنك البحث في عملية ترحيل حركة المرور.
نقل حركة المرور من Google Cloud إلى البنية الأساسية Dailymotion
خريف 2018
بعد ما يقرب من عامين من الإنشاء والاختبار والتكوين ، حصلنا أخيرًا على حزمة Kubernet كاملة ، جاهزة لاستقبال بعض البيانات المرورية.
استراتيجية التوجيه الحالية بسيطة للغاية ، لكنها تفي بالاحتياجات. بالإضافة إلى IP العام (في Google Cloud و Dailymotion) ، يُستخدم AWS Route 53 لتعيين السياسات وإعادة توجيه المستخدمين إلى المجموعة التي نختارها.
مثال على سياسة التوجيه باستخدام المسار 53مع Google Cloud ، يكون الأمر سهلاً ، لأننا نستخدم عنوان IP واحدًا لكل المجموعات ، ويتم إعادة توجيه المستخدم إلى أقرب مجموعة GKE. التكنولوجيا مختلفة عن مجموعاتنا لأن عناوين IP الخاصة بهم مختلفة.
أثناء الترحيل ، سعينا إلى إعادة توجيه الطلبات الإقليمية إلى المجموعات المعنية وتقييم مزايا هذا النهج.
نظرًا لتكوين مجموعات GKE الخاصة بنا لتوسيع نطاقها تلقائيًا باستخدام المقاييس المخصصة ، فإنها تزيد / تنقص الطاقة اعتمادًا على حركة المرور الواردة.
في الوضع العادي ، يتم توجيه كل حركة المرور الإقليمية إلى الكتلة المحلية ، وتعمل GKE كاحتياطي في حالة حدوث مشاكل (يتم إجراء الفحوصات الصحية بواسطة الطريق 53).
...
في المستقبل ، نريد أتمتة سياسات التوجيه بشكل كامل للحصول على استراتيجية هجينة مستقلة تعمل باستمرار على تحسين إمكانية وصول المستخدم. بالنسبة للإيجابيات: تم تخفيض تكلفة السحابة بشكل كبير ، وتم تقليل وقت استجابة واجهة برمجة التطبيقات. نحن نثق في النظام الأساسي السحابي الناتج ، ونحن على استعداد لإعادة توجيه المزيد من الزيارات إليه إذا لزم الأمر.
PS من المترجم
قد تكون مهتمًا أيضًا بنشر منشور Dailymotion حديثًا عن Kubernetes. وهي مكرسة لنشر تطبيقات Helm للعديد من مجموعات Kubernetes
وتم نشرها منذ شهر تقريبًا.
اقرأ أيضًا في مدونتنا: