يا هبر!
نحن نمثل فريق منصة Exness. في السابق، كتب زملاؤنا بالفعل مقالًا عنه . اليوم نريد أن نشارك تجربتنا في ترحيل الخدمات إلى Kubernetes.
في البداية، نقدم لك بعض الأرقام لفهم أفضل لما سيتم مناقشته:
- يتكون قسم التطوير لدينا من أكثر من 100 شخص، بما في ذلك أكثر من 10 فرق مختلفة تتمتع بعمليات ضمان الجودة وDevOps وScrum ذاتية الاكتفاء. مكدس التطوير - Python وPHP وC++ وJava وGolang.
- يبلغ حجم بيئات الاختبار والإنتاج حوالي 2000 حاوية لكل منهما. إنهم يقومون بتشغيل Rancher v1.6 على المحاكاة الافتراضية الخاصة بهم وتحت برنامج VMware.
حافز
كما يقولون، لا شيء يدوم إلى الأبد، وقد أعلن رانشر عن نهاية دعم الإصدار 1.6 منذ وقت طويل. نعم، لقد تعلمنا منذ أكثر من ثلاث سنوات كيفية إعداده وحل المشكلات التي تنشأ، ولكن في كثير من الأحيان نواجه مشاكل لن يتم تصحيحها أبدًا. يحتوي Rancher 1.6 أيضًا على نظام متحجر لإصدار الحقوق، حيث يمكنك إما القيام بكل شيء تقريبًا أو لا شيء على الإطلاق.
على الرغم من أن المحاكاة الافتراضية الخاصة توفر تحكمًا أكبر في تخزين البيانات وأمنها، إلا أنها فرضت تكاليف تشغيل كان من الصعب قبولها نظرًا للنمو المستمر للشركة وعدد المشاريع والمتطلبات الخاصة بها.
أردنا اتباع معايير IaC، وإذا لزم الأمر، الحصول على السعة بسرعة، في أي موقع جغرافي وبدون قفل البائع، وأيضًا أن نكون قادرين على التخلي عنها بسرعة.
الخطوات الأولى
بادئ ذي بدء، أردنا الاعتماد على التقنيات والحلول الحديثة التي من شأنها أن تسمح للفرق بالحصول على دورة تطوير أسرع وتقليل تكاليف التشغيل للتفاعل مع النظام الأساسي الذي يوفر الطاقة.
بالطبع، أول ما يتبادر إلى أذهاننا هو Kubernetes، لكننا لم نتحمّس وأجرينا القليل من البحث لمعرفة ما إذا كان هذا هو الخيار الصحيح. لقد قمنا بتقييم الحلول مفتوحة المصدر فقط، وفي معركة غير عادلة، فاز Kubernetes دون قيد أو شرط.
بعد ذلك جاءت مسألة اختيار أداة لإنشاء المجموعات. قمنا بمقارنة الحلول الأكثر شعبية: kops، kubespray، kubeadm.
في البداية، بدا لنا أن kubeadm مسار معقد للغاية، بل يشبه نوعًا من مخترع "الدراجة"، ولم يكن لدى kops مرونة كافية.
والفائز كان:
لقد بدأنا بتجربة المحاكاة الافتراضية الخاصة بنا وAWS، محاولين إعادة إنشاء شيء مشابه تقريبًا لنمط إدارة الموارد السابق لدينا، حيث شارك الجميع في نفس "المجموعة". والآن لدينا مجموعتنا الأولى المكونة من 10 أجهزة افتراضية صغيرة، يوجد اثنان منها في AWS. بدأنا نحاول ترحيل الفرق إلى هناك، بدا كل شيء "جيدًا"، ويمكن أن تنتهي القصة، لكن...
المشاكل الأولى
Ansible هو ما تم بناء kubespray عليه، فهو ليس أداة تسمح لك بمتابعة IaC: عند تشغيل/إيقاف تشغيل العقد، حدث خطأ ما باستمرار وكان هناك حاجة إلى نوع من التدخل، وعند استخدام أنظمة تشغيل مختلفة، تصرف دليل التشغيل بشكل مختلف. . مع زيادة عدد الفرق والعقد في المجموعة، بدأنا نلاحظ أن دليل قواعد اللعبة كان يستغرق وقتًا أطول وأطول لإكماله، ونتيجة لذلك، كان سجلنا 3,5 ساعة، فماذا عن سجلك؟ 🙂
ويبدو أن kubespray هو مجرد أمر ممكن، وكل شيء واضح للوهلة الأولى، ولكن:
في بداية الرحلة، كانت المهمة هي إطلاق القدرات فقط في AWS وعلى المحاكاة الافتراضية، ولكن بعد ذلك، كما يحدث غالبًا، تغيرت المتطلبات.
في ضوء ذلك، أصبح من الواضح أن نمطنا القديم المتمثل في دمج الموارد في نظام تنسيق واحد لم يكن مناسبًا - في حالة كون المجموعات بعيدة جدًا ويتم إدارتها بواسطة مقدمي خدمات مختلفين.
بالإضافة إلى. عندما تعمل جميع الفرق ضمن نفس المجموعة، يمكن للخدمات المختلفة التي تم تثبيت NodeSelectors بشكل غير صحيح أن تطير إلى المضيف "الأجنبي" لفريق آخر وتستخدم الموارد هناك، وإذا تم ضبط الخلل، كانت هناك طلبات مستمرة تفيد بأن خدمة أو أخرى لا تعمل، لم يتم توزيعها بشكل صحيح بسبب العامل البشري. كانت المشكلة الأخرى هي حساب التكلفة، خاصة بالنظر إلى مشاكل توزيع الخدمات عبر العقد.
كانت القصة المنفصلة هي إصدار الحقوق للموظفين: أراد كل فريق أن يكون "على رأس" المجموعة ويديرها بالكامل، مما قد يتسبب في انهيار كامل، لأن الفرق مستقلة بشكل أساسي عن بعضها البعض.
ماذا تفعل؟
مع الأخذ في الاعتبار ما ورد أعلاه ورغبات الفرق في أن تكون أكثر استقلالية، توصلنا إلى نتيجة بسيطة: فريق واحد - مجموعة واحدة.
لذلك حصلنا على واحدة ثانية:
ثم المجموعة الثالثة:
ثم بدأنا بالتفكير: لنفترض أنه في غضون عام سيكون لدى فرقنا أكثر من مجموعة واحدة؟ في مناطق جغرافية مختلفة، على سبيل المثال، أو تحت سيطرة مقدمي خدمات مختلفين؟ وسيريد البعض منهم أن يكونوا قادرين على نشر مجموعة مؤقتة لبعض الاختبارات بسرعة.
سيأتي 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، حيث يتم وصف كل مجموعة بواسطة مستودع، ويتم إصدار حالتها. في الوقت نفسه، يتم توصيل معظم الوحدات من مستودعات خارجية بحيث كل ما يتبقى هو تمرير المتغيرات أو وصف التكوين المخصص الخاص بك للمثيلات، مما يساعد على تقليل النسبة المئوية لتكرار التعليمات البرمجية.
بالطبع، رحلتنا لم تنته بعد ولا يزال هناك العديد من المهام المثيرة للاهتمام في المستقبل، مثل نقطة عمل واحدة مع سجلات ومقاييس أي مجموعات، وشبكة الخدمة، وgitops لإدارة الأحمال في مجموعة متعددة وأكثر من ذلك بكثير. نأمل أن تجد تجربتنا مثيرة للاهتمام!
تمت كتابة المقال بواسطة أ. أنتيبوف، أ. غانوش، مهندسو المنصات.
المصدر: www.habr.com