اسمي فيكتور ياجوفاروف ، وأنا أقوم بتطوير منصة Kubernetes في DomClick كمدير تطوير تقني في فريق العمليات (العمليات). أود أن أخبركم عن هيكل عمليات التطوير <-> العمليات الخاصة بنا ، وعن ميزات تشغيل واحدة من أكبر مجموعات k8s في روسيا ، بالإضافة إلى ممارسات DevOps / SRE التي يستخدمها فريقنا.
فريق العمليات
يضم فريق العمليات حاليًا 15 شخصًا. ثلاثة منهم مسؤولون عن المكتب ، واثنان يعملان في منطقة زمنية مختلفة ومتاحين ، بما في ذلك في الليل. وبالتالي ، فإن شخصًا ما من Ops يكون دائمًا على الشاشة ومستعدًا للرد على أي حادث معقد. ليس لدينا نوبات ليلية ، مما يحافظ على عقليتنا ويمنح الجميع فرصة الحصول على قسط كافٍ من النوم وقضاء وقت الفراغ ليس فقط على الكمبيوتر.
كل شخص لديه كفاءات مختلفة: المسوقين الشبكيين ، مسؤولي قواعد البيانات ، المتخصصين في ELK stack ، والمشرفين / المطورين في Kubernetes ، والمراقبة ، والمحاكاة الافتراضية ، ومتخصصي الأجهزة ، وما إلى ذلك. هناك شيء واحد يوحد الجميع - يمكن للجميع استبدال أي منا إلى حد ما: على سبيل المثال ، إدخال عقد جديدة في مجموعة k8s ، وتحديث PostgreSQL ، وكتابة خط أنابيب CI / CD + Ansible ، وأتمتة شيء ما في Python / Bash / Go ، وربط قطعة من الأجهزة إلى DPC. لا تتداخل الكفاءات القوية في أي مجال مع تغيير اتجاه النشاط والبدء في الضخ في بعض المجالات الأخرى. على سبيل المثال ، حصلت على وظيفة في شركة كمتخصص في PostgreSQL ، والآن مجال مسؤوليتي الرئيسي هو مجموعات Kubernetes. في الفريق ، أي نمو هو موضع ترحيب فقط ويتم تطوير الإحساس بالكتف بشكل كبير.
بالمناسبة ، نحن نصطاد. متطلبات المرشحين معيارية جدًا. بالنسبة لي شخصيًا ، من المهم أن يتناسب الشخص مع الفريق ، وأن يكون غير متضارب ، ولكنه يعرف أيضًا كيف يدافع عن وجهة نظره ، ويريد التطوير ولا يخشى القيام بشيء جديد ، لعرض أفكاره. أيضًا ، مهارات البرمجة في لغات البرمجة النصية ومعرفة أساسيات Linux واللغة الإنجليزية مطلوبة. اللغة الإنجليزية مطلوبة فقط حتى يتمكن الشخص في حالة fakap من حل المشكلة في google في 10 ثوانٍ ، وليس في 10 دقائق. مع المتخصصين الذين لديهم معرفة عميقة بلينكس ، أصبح الأمر الآن صعبًا للغاية: مضحك ، لكن اثنين من كل ثلاثة مرشحين لا يستطيعون الإجابة على السؤال "ما هو متوسط التحميل؟ ما الذي تتكون منه؟ "، والسؤال" كيفية جمع نفايات أساسية من برنامج sish "يعتبر شيئًا من عالم البشر الخارقين ... أو الديناصورات. علينا أن نتحمل هذا ، لأن الناس عادة ما يكون لديهم كفاءات أخرى عالية التطور ، وسنعلم لينكس. يجب ترك الإجابة على السؤال "لماذا يحتاج مهندس DevOps إلى معرفة كل هذا في عالم السحب الحديث" خارج نطاق المقالة ، ولكن بثلاث كلمات: كل هذا ضروري.
قيادة الأدوات
يلعب فريق الأدوات دورًا مهمًا في الأتمتة. وتتمثل مهمتهم الرئيسية في إنشاء أدوات رسومية وأدوات CLI مناسبة للمطورين. على سبيل المثال ، يتيح لك تطوير Confer الداخلي الخاص بنا طرح تطبيق على Kubernetes ببضع نقرات بالماوس فقط ، وتهيئة موارده ، ومفاتيح من المخزن ، وما إلى ذلك. اعتاد أن يكون هناك Jenkins + Helm 2 ، لكن كان عليّ تطوير أداتي الخاصة لإزالة لصق النسخ وإضفاء التوحيد على دورة حياة البرنامج.
لا يكتب فريق Ops خطوط الأنابيب للمطورين ، ولكن يمكنه تقديم المشورة بشأن أي مشكلات كتابية (لا يزال لدى البعض Helm 3).
DevOps
بالنسبة إلى DevOps ، نراه على النحو التالي:
تقوم فرق التطوير بكتابة التعليمات البرمجية ، وطرحها عبر Confer to dev -> qa / stage -> prod. تقع على عاتق فرق التطوير والعمليات مسؤولية ضمان عدم إبطاء الكود وعدم حدوث أخطاء. في النهار ، يجب على الضابط المناوب من فريق العمليات الرد على أي حادث مع تطبيقه ، وفي المساء والليل ، يجب على المسؤول المناوب (Ops) إيقاظ المطور في الخدمة إذا كان يعلم على وجه اليقين أن المشكلة ليست كذلك في البنية التحتية. تظهر جميع المقاييس والتنبيهات في المراقبة تلقائيًا أو شبه تلقائي.
تبدأ منطقة مسؤولية Ops من لحظة طرح التطبيق للإنتاج ، لكن مسؤولية Dev لا تنتهي عند هذا الحد - فنحن نفعل شيئًا واحدًا ونحن في نفس القارب.
ينصح المطورون المسؤولين إذا كانوا بحاجة إلى مساعدة في كتابة خدمة مصغرة للمشرف (على سبيل المثال ، Go backend + HTML5) ، وينصح المسؤولون المطورين بشأن أي مشكلات متعلقة بالبنية التحتية أو k8s.
بالمناسبة ، ليس لدينا متراصة على الإطلاق ، فقط خدمات مصغرة. يتقلب عددهم حتى الآن بين 900 و 1000 في مجموعة prod k8s ، إذا تم قياسه من خلال الرقم نشر. يتقلب عدد الكبسولات بين 1700 و 2000. وتبلغ أعداد القرون الموجودة في مجموعة البودات الآن حوالي 2000.
لا يمكنني إعطاء أرقام دقيقة ، لأننا نراقب الخدمات المصغرة غير الضرورية ونقطعها في الوضع شبه التلقائي. يساعدنا تتبع الكيانات غير الضرورية في k8s مما يوفر الموارد والمال.
إدارة الموارد
رصد
تصبح المراقبة المبنية بكفاءة والغنية بالمعلومات حجر الزاوية في تشغيل مجموعة كبيرة. لم نعثر بعد على حل شامل يغطي 100٪ من جميع احتياجات المراقبة ، لذلك نقوم بشكل دوري بتثبيت حلول مخصصة مختلفة في هذه البيئة.
- Zabbix. المراقبة القديمة الجيدة ، والتي تم تصميمها بشكل أساسي لمراقبة الحالة العامة للبنية التحتية. يخبرنا عندما تموت العقدة بواسطة المعالج والذاكرة والأقراص والشبكة وما إلى ذلك. لا شيء خارق للطبيعة ، ولكن لدينا أيضًا مجموعة DaemonSet منفصلة من الوكلاء ، بمساعدة منها ، على سبيل المثال ، نراقب حالة DNS في المجموعة: نحن نبحث عن قرون غبية ، ونتحقق من توفر مضيفين خارجيين. يبدو أن سبب الإزعاج من أجل ذلك ، ولكن بالنسبة للأحجام الكبيرة من حركة المرور ، يعد هذا المكون نقطة فشل خطيرة. سابقا لدي كيف كافحت مع أداء DNS في الكتلة.
- مشغل بروميثيوس. تعطي مجموعة من المصدرين المختلفين نظرة عامة رائعة على جميع مكونات الكتلة. بعد ذلك ، نتخيل كل هذا على لوحات المعلومات الكبيرة في Grafana ، ونستخدم alertmanager للإشعارات.
أداة أخرى مفيدة لنا هي . لقد كتبناه بعد عدة مرات واجهنا موقفًا تداخل فيه فريق واحد مع دخول فريق آخر مع مساراته ، مما تسبب في حدوث أخطاء 50x. الآن ، قبل النشر في الإنتاج ، يتحقق المطورون من أنهم لن يؤذوا أي شخص ، وبالنسبة لفريقي فهذه أداة جيدة للتشخيص الأولي لمشاكل Ingresses. من المضحك أنه في البداية تمت كتابته للمسؤولين ويبدو أنه "غير لائق" إلى حد ما ، ولكن بعد أن وقعت فرق المطورين في حب الأداة ، تغيرت كثيرًا وبدأت تبدو وكأنها "قام المشرف بإنشاء وجه ويب للمشرفين" . قريباً سنتخلى عن هذه الأداة وسيتم التحقق من صحة مثل هذه المواقف حتى قبل طرح خط الأنابيب.
موارد الفريق في "Cube"
قبل الشروع في الأمثلة ، يجدر بنا شرح كيفية تخصيص الموارد لها الخدمات المصغرة.
لفهم أي فرق وبأي كميات تستخدم موارد (المعالج ، الذاكرة ، SSD المحلي) ، نخصص أنفسنا مساحة الاسم في "Cube" ويحد من إمكانياته القصوى من حيث المعالج والذاكرة والقرص ، بعد أن ناقش سابقًا احتياجات الفرق. وفقًا لذلك ، لن يحظر أمر واحد ، في الحالة العامة ، الكتلة بأكملها للنشر ، ويخصص آلاف النوى وتيرابايت من الذاكرة لنفسه. يتم إصدار الوصول إلى مساحة الاسم من خلال AD (نستخدم RBAC). تتم إضافة مساحات الأسماء وحدودها عبر طلب سحب إلى مستودع GIT ، ثم يتم طرح كل شيء تلقائيًا عبر خط أنابيب Ansible.
مثال على تخصيص الموارد لكل فريق:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
الطلبات والقيود
مكعبة " أطلب هو عدد الموارد المحجوزة المضمونة تحت جراب (حاوية واحدة أو أكثر من حاويات الإرساء) في مجموعة. الحد هو الحد الأقصى غير المضمون. يمكنك غالبًا أن ترى في المخططات كيف قام فريق ما بتعيين نفسه لعدد كبير جدًا من الطلبات لجميع تطبيقاته ولا يمكنه نشر التطبيق على "Cube" ، نظرًا لأن جميع الطلبات ضمن مساحة الاسم الخاصة بهم قد "استنفدت" بالفعل.
الطريقة الصحيحة للخروج من هذا الموقف هي النظر إلى استهلاك الموارد الفعلي ومقارنته بالمبلغ المطلوب (الطلب).
توضح لقطات الشاشة أعلاه أن وحدات المعالجة المركزية "المطلوبة" (المطلوبة) يتم تحديدها إلى العدد الحقيقي للخيوط ، ويمكن أن تتجاوز الحدود العدد الحقيقي لخيوط وحدة المعالجة المركزية =)
الآن دعنا نلقي نظرة فاحصة على بعض مساحات الاسم (اخترت مساحة الاسم kube-system - مساحة اسم النظام لمكونات "Cube" نفسها) ونرى نسبة وقت المعالج والذاكرة المستخدمة فعليًا إلى المساحة المطلوبة:
من الواضح أن هناك ذاكرة ووحدة معالجة مركزية محجوزة لخدمات النظام أكثر بكثير مما هو مستخدم بالفعل. في حالة نظام kube ، هذا له ما يبرره: حدث أن وحدة تحكم دخول nginx أو nodelocaldns في الذروة استقرت على وحدة المعالجة المركزية وأكلت الكثير من ذاكرة الوصول العشوائي ، لذلك هنا مثل هذا الهامش له ما يبرره. بالإضافة إلى ذلك ، لا يمكننا الاعتماد على الرسوم البيانية للساعات الثلاث الماضية: من المستحسن رؤية المقاييس التاريخية على مدى فترة زمنية طويلة.
تم تطوير نظام "التوصيات". على سبيل المثال ، يمكنك هنا معرفة أي الموارد سيكون من الأفضل رفع "الحدود" (الشريط العلوي المسموح به) بحيث لا يحدث "الاختناق": اللحظة التي قضى فيها الكبسولة بالفعل وحدة المعالجة المركزية أو الذاكرة للوقت المخصص وينتظر حتى يتم "رفع التجميد":
وإليك القرون التي يجب أن تلطف شهيتهم:
حول خانق + مراقبة الموارد ، يمكنك كتابة أكثر من مقال ، لذا اطرح الأسئلة في التعليقات. باختصار ، يمكنني القول إن مهمة أتمتة مثل هذه المقاييس صعبة للغاية وتتطلب الكثير من الوقت وموازنة العمل مع وظائف "window" و "CTE" Prometheus / VictoriaMetrics (هذه المصطلحات موجودة بين علامتي اقتباس ، نظرًا لوجود لا شيء مثل هذا تقريبًا في PromQL ، وعليك إحاطة الاستفسارات المخيفة على عدة شاشات من النصوص وتحسينها).
نتيجة لذلك ، يمتلك المطورون أدوات لمراقبة مساحات الأسماء الخاصة بهم في "Cube" ، وهم قادرون على اختيار المكان والوقت الذي يمكن فيه للتطبيقات "قطع" الموارد ، وأي البودات يمكن منحها وحدة المعالجة المركزية بالكامل طوال الليل.
المنهجيات
في شركة مثل الآن عصريا، فنحن نلتزم بـ DevOps- و SRE-ممارس المهنة عندما يكون لدى الشركة 1000 خدمة مصغرة ، وحوالي 350 مطورًا و 15 مسؤولًا للبنية التحتية بأكملها ، يجب أن تكون "عصريًا": وراء كل هذه "الكلمات الطنانة" ، هناك حاجة ملحة لأتمتة كل شيء وكل شيء ، ويجب ألا يكون المسؤولون في عنق الزجاجة في العمليات.
بصفتنا شركة Ops ، نقدم مقاييس ولوحات معلومات متنوعة للمطورين فيما يتعلق بوقت استجابة الخدمات وأخطائهم.
نستخدم منهجيات مثل: , и من خلال الجمع بينهما. نحاول تقليل عدد لوحات المعلومات بحيث يتضح للوهلة الأولى الخدمة المتدهورة حاليًا (على سبيل المثال ، رموز الاستجابة في الثانية ، ووقت الاستجابة عند النسبة المئوية 99) ، وما إلى ذلك. بمجرد أن تصبح بعض المقاييس الجديدة للوحات المعلومات العامة ضرورية ، نقوم برسمها وإضافتها على الفور.
لم أرسم رسومات منذ شهر حتى الآن. ربما تكون هذه علامة جيدة: فهي تعني أن معظم "الاحتياجات" قد تم تنفيذها بالفعل. لقد حدث أنني قمت برسم مخطط جديد لمدة أسبوع على الأقل مرة واحدة في اليوم.
والنتيجة الناتجة ذات قيمة لأن المطورين الآن نادراً ما يذهبون إلى المسؤولين بأسئلة "أين يمكن رؤية نوع من المقاييس".
مقدمة من شبكة الخدمة قاب قوسين أو أدنى ويجب أن تجعل الحياة أسهل للجميع ، فالزملاء من الأدوات قريبون بالفعل من تنفيذ "Istio of a health person" المجرد: ستكون دورة حياة كل طلب HTTP (طلبات) مرئية في المراقبة ، و سيكون من الممكن دائمًا فهم "في أي مرحلة تعطل كل شيء" في التفاعل بين الخدمات (وليس فقط). اشترك في الأخبار من مركز DomClick. =)
دعم البنية التحتية Kubernetes
تاريخيا ، نحن نستخدم النسخة المصححة كوبسبراي - دور لا يمكن تصديقه لنشر وتوسيع وتحديث Kubernetes. في مرحلة ما ، تم قطع الدعم للتركيبات غير kubeadm من الفرع الرئيسي ، ولم يتم اقتراح عملية الانتقال إلى kubeadm. نتيجة لذلك ، صنعت Southbridge شوكة خاصة بها (مع دعم kubeadm وإصلاح سريع للمشكلات الحرجة).
تبدو عملية الترقية لجميع مجموعات k8s كما يلي:
- أخذ كوبسبراي من ساوثبريدج ، تحقق من فرعنا ، Merjim.
- طرح التحديث على إجهاد- "كيوب".
- نطرح التحديث عقدة واحدة في كل مرة (في Ansible هذا هو "serial: 1") في ديف- "كيوب".
- التحديث همز مساء السبت ، عقدة واحدة في كل مرة.
في المستقبل هناك خطط لاستبدال كوبسبراي إلى شيء أسرع والذهاب إلى com.kubeadm.
إجمالاً ، لدينا ثلاثة "مكعبات": الإجهاد ، والتطوير ، والإنتاج. نحن نخطط لإطلاق آخرالاستعداد الساخن) Prod- "Cube" في مركز البيانات الثاني. إجهاد и ديف العيش في الأجهزة الافتراضية (oVirt for Stress و VMWare cloud for Dev). همز- يعيش "Cube" على "معدن مكشوف" (معدن مكشوف): هذه هي نفس العقد التي تحتوي على 32 خيطًا لوحدة المعالجة المركزية ، وذاكرة 64-128 جيجابايت ، و 300 جيجابايت من SSD RAID 10 - يوجد 50 منها إجمالاً. ثلاث عقد "رفيعة" مخصصة لـ "الماجستير" همز- "كوبا": ذاكرة 16 جيجا بايت ، 12 موضوعًا لوحدة المعالجة المركزية.
للبيع ، نفضل استخدام "المعدن المكشوف" وتجنب الطبقات غير الضرورية مثل كومة مفتوحة: لسنا بحاجة إلى "جيران مزعجين" ووحدة المعالجة المركزية سرقة الوقت. ويزداد تعقيد الإدارة بمقدار النصف تقريبًا في حالة OpenStack الداخلية.
بالنسبة إلى CI / CD Cubic ومكونات البنية التحتية الأخرى ، نستخدم خادم GIT منفصل ، Helm 3 الذري) ، جينكينز ، أنسيبل ودوكر. نحن نحب الفروع المميزة وننتشر في بيئات مختلفة من نفس المستودع.
اختتام
هذه هي الطريقة التي تبدو ، بشكل عام ، عملية DevOps في DomClick من جانب مهندس العمليات. تبين أن المقال أقل تقنيًا مما توقعت: لذلك ، تابع أخبار DomClick على Habré: سيكون هناك المزيد من المقالات "المتشددة" حول Kubernetes والمزيد.
المصدر: www.habr.com