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