Get best of the week

رحلة K8S Multicluster

مرحبا يا هابر!

نحن نمثل فريق منصة Exness. في وقت سابق ، كتب زملائنا بالفعل مقالًا حول صور جاهزة للإنتاج لـ k8s . نريد اليوم مشاركة تجربة هجرة الخدمة في Kubernetes.



بادئ ذي بدء ، نقدم لك بعض الأرقام لفهم أفضل لما سيتم مناقشته:

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


كما يقولون ، لا شيء يدوم إلى الأبد ، وقد أعلن رانشر لفترة طويلة بما فيه الكفاية إنهاء الدعم للإصدار 1.6. نعم ، لقد تعلمنا منذ أكثر من ثلاث سنوات كيفية طبخه وحل المشكلات التي تظهر ، ولكننا نواجه في كثير من الأحيان مشاكل لن يتم حلها على الإطلاق. يحتوي Rancher 1.6 أيضًا على نظام متحجر لإصدار الحقوق ، حيث يمكنك إما القيام بكل شيء تقريبًا أو لا شيء.

افتراضية خاصة ، على الرغم من أنها وفرت سيطرة أكبر على تخزين البيانات وأمانها ، ولكنها فرضت تكاليف تشغيلية ، والتي كان من الصعب تحملها مع النمو المستمر للشركة ، وعدد المشاريع والمتطلبات لها.

أردنا اتباع معايير IaC ، وإذا لزم الأمر ، الحصول على الطاقة بسرعة ، في أي مكان جغرافي وبدون قفل بائع ، وأن نتمكن أيضًا من التخلي عنها بسرعة.

الخطوات الأولى


بادئ ذي بدء ، أردنا الاعتماد على التقنيات والحلول الحديثة التي تتيح للفرق الحصول على دورة تطوير أسرع وتقليل تكاليف التشغيل للتفاعل مع النظام الأساسي الذي يوفر الطاقة. 
 
بالطبع ، كان أول شيء يتبادر إلى أذهاننا هو Kubernetes ، لكننا لم نشعر بالإثارة وأجرينا القليل من البحث حول موضوع الاختيار الصحيح. قمنا بتقييم حلول المصادر المفتوحة فقط ، وهزم Kubernetes دون قيد أو شرط في معركة غير عادلة.  

بعد ذلك جاء سؤال اختيار أداة لإنشاء مجموعات. قارنا الحلول الأكثر شعبية: kops ، kubespray ، kubeadm.

بادئ ذي بدء ، بدا لنا kubeadm بطريقة معقدة للغاية ، بدلاً من ذلك ، نوع من مخترع "الدراجة" ، وافتقرت الشرطة إلى المرونة.

وخرج الفائز:



بدأنا في تجربة المحاكاة الافتراضية الخاصة بنا و AWS ، محاولين إعادة إنشاء شبه تقريبي لنمط إدارة الموارد السابق الخاص بنا ، حيث يستخدم الجميع نفس "المجموعة". والآن لدينا المجموعة الأولى من 10 أجهزة افتراضية صغيرة ، اثنان منها في AWS. بدأنا في محاولة ترحيل الفرق هناك ، وبدا أن كل شيء "جيد" ، ويمكن أن تنتهي القصة ، ولكن ...

المشاكل الأولى


Ansible هو ما تم بناء kubespray عليه ، وليس الأداة التي تسمح باتباع IaC: عندما دخلت / أوقف تشغيل العقد ، حدث خطأ مستمر وكان هناك حاجة إلى أي تدخل ، وعند استخدام أنظمة تشغيل مختلفة ، تصرف كتاب التشغيل بطرق مختلفة. مع العدد المتزايد من الأوامر والعقد في المجموعة ، بدأنا نلاحظ أن كتاب التشغيل استغرق وقتًا أطول وأطول ، في النهاية ، سجلنا كان 3.5 ساعة ، وسجلك؟ :)

ويبدو أن kubespray هو Ansible فقط ، وكل شيء واضح للوهلة الأولى ، ولكن:



في بداية الرحلة كانت هناك مهمة لتشغيل القدرات فقط في AWS والافتراضية ، ولكن بعد ذلك ، كما يحدث غالبًا ، تغيرت المتطلبات.
 


في ضوء ذلك ، أصبح من الواضح أن نمطنا القديم لدمج الموارد في نظام تنسيق واحد لم يكن مناسبًا - في الحالة التي تكون فيها المجموعات بعيدة تمامًا ويديرها مزودون مختلفون. 

علاوة على ذلك. عندما تعمل جميع الفرق داخل المجموعة نفسها ، يمكن للخدمات المتنوعة التي تم تثبيت NodeSelector بشكل غير صحيح أن تنتقل إلى المضيف "الأجنبي" الخاص بفريق آخر وتستخدم الموارد هناك ، وفي حالة ضبط الحالة ، كانت هناك مكالمات مستمرة بأن هذه الخدمة أو تلك لم تكن تعمل ، وليس موزعة بشكل صحيح بسبب العامل البشري. كانت المشكلة الأخرى هي حساب التكلفة ، خاصة بالنظر إلى المشاكل في توزيع الخدمات حسب العقد.

كانت قصة منفصلة قضية حقوق الموظفين: أراد كل فريق أن يكون "على رأس" المجموعة وإدارتها بالكامل ، مما قد يتسبب في انهيار كامل ، حيث أن الفرق في الغالب مستقلة عن بعضها البعض.

كيف تكون


بالنظر إلى ما سبق ورغبات الفرق في أن تكون أكثر استقلالية ، توصلنا إلى استنتاج بسيط: فريق واحد - مجموعة واحدة. 

لذا حصلنا على مجموعة ثانية:



ثم المجموعة الثالثة: 



ثم بدأنا بالتفكير: لنفترض ، في غضون عام ، سيكون لدى فرقنا أكثر من مجموعة واحدة؟ في مناطق جغرافية مختلفة ، على سبيل المثال ، أو تحت سيطرة مزودي مختلفين؟ وسيريد البعض أن يكونوا قادرين على نشر مجموعة مؤقتة لأي اختبارات بسرعة. 



سيأتي Kubernetes الكامل! هذا نوع من MultiKubernetes ، اتضح. 

في الوقت نفسه ، سنحتاج جميعًا إلى دعم جميع هذه المجموعات بطريقة أو بأخرى ، لنكون قادرين على التحكم بسهولة في الوصول إليها ، بالإضافة إلى إنشاء مجموعات جديدة وتفكيك القديمة منها دون تدخل يدوي.

منذ بداية رحلتنا في عالم Kubernetes ، مر بعض الوقت ، وقررنا إعادة فحص الحلول المتاحة. اتضح أنه موجود بالفعل في السوق - Rancher 2.2.



في المرحلة الأولى من بحثنا ، قامت Rancher Labs بالفعل بإصدار الإصدار الأول من الإصدار 2 ، ولكن على الرغم من أنه يمكن رفعه بسرعة كبيرة عن طريق تشغيل الحاوية بدون تبعيات خارجية مع بعض المعلمات أو باستخدام مخطط HELM الرسمي ، فقد بدا لنا فظًا ، ولم نكن نعرف إذا الاعتماد على هذا القرار ، سواء تم تطويره أو التخلي عنه بسرعة. الكتلة = نموذج النقرات نفسه في واجهة المستخدم لا تناسبنا أيضًا ، ولم نرغب في الارتباط بـ RKE ، لأن هذه أداة ضيقة الأفق إلى حد ما. 

كان لإصدار Rancher 2.2 بالفعل مظهر أكثر كفاءة ، بالإضافة إلى الميزات السابقة ، كان لديه مجموعة من الميزات المثيرة للاهتمام خارج الصندوق ، مثل التكامل مع العديد من المزودين الخارجيين ، ونقطة توزيع واحدة للحقوق وملفات kubeconfig ، وإطلاق صورة kubectl مع حقوقك في واجهة المستخدم ، ومساحات الأسماء المتداخلة المعروفة أيضًا باسم المشاريع. 

تم تشكيل مجتمع بالفعل حول Rancher 2 ، وتم إنشاء موفر HashiCorp Terraform لإدارته ، مما ساعدنا على تجميع كل شيء معًا.

ماذا حدث


ونتيجة لذلك ، حصلنا على مجموعة صغيرة واحدة يتم فيها إطلاق Rancher ، ويمكن الوصول إليها من قبل جميع المجموعات الأخرى ، بالإضافة إلى العديد من المجموعات المرتبطة بها ، ويمكن الوصول إلى أي منها بمجرد إضافة مستخدم إلى دليل ldap ، بغض النظر عن مكان وجوده يقع والموارد التي يستخدمها مزود.

باستخدام gitlab-ci و Terraform ، تم إنشاء نظام يسمح لك بإنشاء مجموعة من أي تكوين في مزودي الخدمات السحابية أو بنيتنا التحتية الخاصة بنا وربطهم بـ Rancher. كل هذا يتم بأسلوب IaC ، حيث يتم وصف كل عنقود من قبل مستودع ، ويتم إصدار حالته. في هذه الحالة ، يتم توصيل معظم الوحدات من مستودعات خارجية بحيث يبقى فقط لنقل المتغيرات أو وصف تكوينها المخصص للمثيل ، مما يساعد على تقليل النسبة المئوية لتكرار التعليمات البرمجية.



بالطبع ، رحلتنا لم تنته بعد ولا تزال هناك العديد من المهام المثيرة للاهتمام في المستقبل ، مثل نقطة عمل واحدة مع سجلات ومقاييس أي مجموعات ، وشبكة خدمة ، وبوابات لإدارة الأحمال في مجموعة متعددة ، وأكثر من ذلك بكثير. نأمل أن تكون مهتمًا بتجربتنا! 

كتب هذا المقال أ. أنتيبوف ، أ. جانوش ، مهندسو المنصات. 

More articles:


All Articles