تحسبا فيتالي خاباروف تمت مقابلته ديمتري ستولياروف ()، المدير الفني والمؤسس المشارك لشركة فلانت. سأل فيتالي ديمتري عما يفعله فلانت، وعن Kubernetes، وتطوير النظام البيئي، ودعمه. ناقشنا سبب الحاجة إلى Kubernetes وما إذا كانت هناك حاجة إليه على الإطلاق. وأيضًا حول الخدمات الصغيرة، وAmazon AWS، ونهج "سأكون محظوظًا" تجاه DevOps، ومستقبل Kubernetes نفسها، ولماذا ومتى وكيف ستسيطر على العالم، وآفاق DevOps وما يجب على المهندسين الاستعداد له في العالم. مستقبل مشرق وقريب مع التبسيط والشبكات العصبية.
استمع كبودكاست على DevOps Deflop - وهو بودكاست باللغة الروسية حول DevOps، وفيما يلي النسخة النصية.
هنا وتحت يطرح الأسئلة مهندس من Express42.
حول "فلان"
- مرحبا ديما. أنت المدير الفني "" وكذلك مؤسسها. من فضلك أخبرنا ماذا تفعل الشركة وماذا أنت فيها؟
ديمتري: من الخارج يبدو أننا الأشخاص الذين يقومون بتثبيت Kubernetes للجميع ويفعلون شيئًا ما به. ولكن هذا ليس صحيحا. لقد بدأنا كشركة تتعامل مع Linux، ولكن نشاطنا الرئيسي لفترة طويلة جدًا كان يتمثل في خدمة الإنتاج والمشروعات الجاهزة عالية التحميل. عادةً ما نقوم ببناء البنية التحتية بأكملها من الصفر ومن ثم نكون مسؤولين عنها لفترة طويلة جدًا. ولذلك، فإن العمل الرئيسي الذي تقوم به «فلانت»، والذي تتلقى المال من أجله، هو تحمل المسؤولية وتنفيذ الإنتاج الجاهز.
أنا، بصفتي المدير الفني وأحد مؤسسي الشركة، أقضي كل النهار والليل في محاولة معرفة كيفية زيادة إمكانية الوصول إلى الإنتاج، وتبسيط تشغيله، وجعل حياة المسؤولين أسهل، وحياة المطورين أكثر متعة .
حول كوبرنيتيس
- لقد رأيت مؤخرًا الكثير من التقارير من فلانت و حول كوبرنيتيس. كيف أتيت إلى ذلك؟
ديمتري: لقد تحدثت عن هذا الأمر عدة مرات، لكن لا مانع من تكراره على الإطلاق. أعتقد أنه من الصواب إعادة هذا الموضوع لأن هناك خلطاً بين السبب والنتيجة.
نحن حقا بحاجة إلى أداة. واجهنا الكثير من المشاكل، وكافحنا، وتغلبنا عليها بمختلف العكازات، وشعرنا بالحاجة إلى أداة. لقد مررنا بالعديد من الخيارات المختلفة وقمنا ببناء دراجاتنا الخاصة واكتسبنا الخبرة. وبالتدريج وصلنا إلى النقطة التي بدأنا فيها استخدام Docker بمجرد ظهوره تقريبًا - في عام 2013 تقريبًا. في وقت ظهوره، كان لدينا بالفعل الكثير من الخبرة مع الحاويات، وقد كتبنا بالفعل نظيرًا لـ "Docker" - بعض العكازات الخاصة بنا في Python. مع ظهور Docker، أصبح من الممكن التخلص من العكازات واستخدام حل موثوق ومدعوم من المجتمع.
مع Kubernetes القصة مشابهة. بحلول الوقت الذي بدأت فيه تكتسب زخمًا - هذا هو الإصدار 1.2 بالنسبة لنا - كان لدينا بالفعل مجموعة من العكازات على كل من Shell وChef، والتي حاولنا بطريقة ما تنسيقها مع Docker. كنا نتطلع بجدية إلى Rancher ومختلف الحلول الأخرى، ولكن بعد ذلك ظهر Kubernetes، حيث يتم تنفيذ كل شيء تمامًا كما كنا نفعله أو حتى أفضل. لا يوجد شيء للشكوى.
نعم، هناك نوع من النقص هنا، وهناك نوع من النقص هناك - هناك الكثير من العيوب، و1.2 فظيع بشكل عام، ولكن... Kubernetes يشبه مبنى قيد الإنشاء - تنظر إلى المشروع وتفهمه أنه سيكون باردا. إذا كان المبنى الآن يحتوي على أساس وطابقين، فأنت تفهم أنه من الأفضل عدم الانتقال إليه بعد، ولكن لا توجد مثل هذه المشاكل مع البرنامج - يمكنك استخدامه بالفعل.
لم يكن لدينا لحظة فكرنا فيها في استخدام Kubernetes أم لا. كنا ننتظره قبل وقت طويل من ظهوره، وحاولنا إنشاء نظائره بأنفسنا.
حول كوبرنيتيس
— هل تشارك بشكل مباشر في تطوير Kubernetes نفسها؟
ديمتري: المتوسط. بل نشارك في تطوير النظام البيئي. نرسل عددًا معينًا من طلبات السحب: إلى Prometheus، إلى مختلف المشغلين، إلى Helm - إلى النظام البيئي. لسوء الحظ، لا أستطيع متابعة كل ما نقوم به وقد أكون مخطئًا، ولكن لا يوجد تجمع واحد منا في القلب.
— في الوقت نفسه، هل تقوم بتطوير العديد من أدواتك حول Kubernetes؟
ديمتري: الإستراتيجية هي كما يلي: نذهب ونسحب الطلبات إلى كل شيء موجود بالفعل. إذا لم يتم قبول طلبات السحب هناك، فإننا ببساطة نقوم بتقسيمها بأنفسنا ونعيش حتى يتم قبولها مع بنياتنا. ثم، عندما يصل إلى المنبع، نعود إلى الإصدار المنبع.
على سبيل المثال، لدينا مشغل Prometheus، الذي قمنا من خلاله بالتبديل ذهابًا وإيابًا إلى المنبع لمجموعتنا ربما 5 مرات بالفعل. نحتاج إلى نوع ما من الميزات، وقد أرسلنا طلب سحب، ونحتاج إلى طرحها غدًا، ولكننا لا نريد الانتظار حتى يتم إصدارها في المنبع. وعليه، نجتمع لأنفسنا، ونطرح تجميعنا بميزتنا، التي نحتاجها لسبب ما، إلى كل مجموعاتنا. بعد ذلك، على سبيل المثال، يقومون بتسليمها إلينا في المنبع بالكلمات: "يا شباب، دعونا نفعل ذلك من أجل حالة أكثر عمومية،" نحن، أو أي شخص آخر، ننتهي منه، ومع مرور الوقت يتم دمجه مرة أخرى.
نحاول تطوير كل ما هو موجود. العديد من العناصر التي لم تكن موجودة بعد، لم يتم اختراعها بعد، أو تم اختراعها، ولكن لم يكن لديها وقت للتنفيذ - نحن نفعل ذلك. وليس لأننا نحب العملية أو بناء الدراجات كصناعة، ولكن ببساطة لأننا بحاجة إلى هذه الأداة. كثيرا ما يُطرح السؤال لماذا فعلنا هذا الشيء أو ذاك؟ الجواب بسيط - نعم، لأنه كان علينا أن نذهب أبعد من ذلك، وحل بعض المهام العملية، وقمنا بحلها باستخدام هذه التولا.
المسار دائمًا هو هذا: نحن نبحث بعناية شديدة، وإذا لم نجد أي حل حول كيفية صنع عربة ترولي باص من رغيف الخبز، فإننا نصنع رغيفًا وحافلة خاصة بنا.
أدوات فلانتا
- أعلم أن Flant لديه الآن عوامل تشغيل إضافية، ومشغلات Shell، وأدوات dapp/werf. كما أفهمها، هذه هي نفس الأداة في تجسيدات مختلفة. أفهم أيضًا أن هناك العديد من الأدوات المختلفة داخل Flaunt. هذا صحيح؟
ديمتري: لدينا الكثير على جيثب. مما أتذكره الآن، لدينا خريطة حالة - لوحة لـ Grafana مر عليها الجميع. يتم ذكره في كل مقالة ثانية تقريبًا حول مراقبة Kubernetes على Medium. من المستحيل شرح ماهية خريطة الحالة بإيجاز - فهي تحتاج إلى مقالة منفصلة، ولكنها مفيدة جدًا لمراقبة الحالة بمرور الوقت، لأننا في Kubernetes غالبًا ما نحتاج إلى إظهار الحالة بمرور الوقت. لدينا أيضًا LogHouse - وهو شيء يعتمد على ClickHouse والسحر الأسود لجمع السجلات في Kubernetes.
الكثير من المرافق! وسيكون هناك المزيد، لأنه سيتم إصدار عدد من الحلول الداخلية هذا العام. من بين الإضافات الكبيرة جدًا المستندة إلى مشغل الإضافات، هناك مجموعة من الإضافات لـ Kubernetes، بالإضافة إلى كيفية تثبيت مدير sert بشكل صحيح - أداة لإدارة الشهادات، وكيفية تثبيت Prometheus بشكل صحيح مع مجموعة من الملحقات - هذه حوالي عشرين مختلفة الثنائيات التي تقوم بتصدير البيانات وجمع شيء ما، لذلك يحتوي بروميثيوس على أروع الرسومات والتنبيهات. كل هذا مجرد مجموعة من الإضافات إلى Kubernetes، والتي تم تثبيتها في مجموعة، وتتحول من بسيطة إلى رائعة ومتطورة وتلقائية، حيث تم بالفعل حل العديد من المشكلات. نعم، نحن نفعل الكثير.
تطوير النظام البيئي
"يبدو لي أن هذه مساهمة كبيرة جدًا في تطوير هذه الأداة وطرق استخدامها." هل يمكنك تقدير الأشخاص الآخرين الذين سيقدمون نفس المساهمة تقريبًا في تطوير النظام البيئي؟
ديمتري: في روسيا، من بين الشركات التي تعمل في سوقنا، لا يوجد أحد قريب منها. بالطبع، هذا بيان بصوت عال، لأن هناك لاعبين رئيسيين مثل Mail و Yandex - إنهم يفعلون أيضا شيئا مع Kubernetes، لكنهم لا يقتربون من مساهمة الشركات في العالم بأسره التي تفعل أكثر بكثير منا. من الصعب مقارنة Flant، التي يعمل بها 80 شخصًا، وRed Hat، التي لديها 300 مهندس لكل Kubernetes وحدها، إذا لم أكن مخطئًا. من الصعب المقارنة. لدينا 6 أشخاص في قسم RnD، بما فيهم أنا، الذين قاموا بقطع جميع أدواتنا. 6 أشخاص مقابل 300 مهندس من Red Hat - من الصعب إلى حد ما المقارنة.
- ومع ذلك، حتى عندما يتمكن هؤلاء الأشخاص الستة من فعل شيء مفيد ومنفر حقًا، عندما يواجهون مشكلة عملية ويقدمون الحل للمجتمع - فهذه حالة مثيرة للاهتمام. أفهم أنه في شركات التكنولوجيا الكبيرة، حيث يكون لديهم فريق تطوير ودعم Kubernetes خاص بهم، من حيث المبدأ، يمكن تطوير نفس الأدوات. وهذا مثال لهم على ما يمكن تطويره وإعطاؤه للمجتمع، مما يعطي زخمًا للمجتمع بأكمله الذي يستخدم Kubernetes.
ديمتري: ربما تكون هذه سمة من سمات التكامل، خصوصيته. لدينا العديد من المشاريع ونرى العديد من المواقف المختلفة. بالنسبة لنا، الطريقة الرئيسية لخلق قيمة مضافة هي تحليل هذه الحالات، وإيجاد القواسم المشتركة وجعلها رخيصة قدر الإمكان بالنسبة لنا. نحن نعمل بنشاط على هذا. من الصعب بالنسبة لي أن أتحدث عن روسيا والعالم، ولكن لدينا حوالي 40 مهندسًا في DevOps في الشركة يعملون على Kubernetes. لا أعتقد أن هناك العديد من الشركات في روسيا لديها عدد مماثل من المتخصصين الذين يفهمون نظام Kubernetes، إن وجدوا على الإطلاق.
أنا أفهم كل شيء عن المسمى الوظيفي مهندس DevOps، الجميع يفهم كل شيء وقد اعتاد على تسمية مهندسي DevOps بمهندسي DevOps، ولن نناقش هذا. يواجه كل هؤلاء المهندسين الأربعين المذهلين في DevOps المشكلات ويحلونها كل يوم، ونحن فقط نحلل هذه التجربة ونحاول تعميمها. نحن نفهم أنه إذا بقيت بداخلنا، فستكون الأداة عديمة الفائدة في غضون عام أو عامين، لأنه في مكان ما في المجتمع ستظهر تولا جاهزة. لا فائدة من تجميع هذه التجربة داخليًا - فهي ببساطة تستنزف الطاقة والوقت في dev/null. ونحن لا نشعر بالأسف لذلك على الإطلاق. ننشر كل شيء بكل سرور وندرك أنه يحتاج إلى النشر والتطوير والترويج والترويج حتى يستخدمه الناس ويضيفون تجربتهم - ثم ينمو كل شيء ويعيش. ثم بعد عامين لا يذهب الجهاز إلى سلة المهملات. ليس من المؤسف أن تستمر في صب القوة، لأنه من الواضح أن هناك من يستخدم أداتك، وبعد عامين يستخدمها الجميع.
هذا جزء من استراتيجيتنا الكبيرة مع dapp/werf. لا أتذكر متى بدأنا في صنعها، يبدو أنه منذ 3 سنوات. في البداية، كان بشكل عام على القشرة. لقد كان دليلاً رائعًا على المفهوم، فقد قمنا بحل بعض مشكلاتنا الخاصة - وقد نجح الأمر! ولكن هناك مشاكل في الصدفة، فمن المستحيل توسيعها أكثر، والبرمجة على الصدفة هي مهمة أخرى. لقد اعتدنا على الكتابة بلغة روبي، وبالتالي، قمنا بإعادة صياغة شيء ما في روبي، وقمنا بتطويره وتطويره وتطويره، وواجهنا حقيقة أن المجتمع، والحشد الذي لا يقول "نريده أو لا نريده، "يرفع أنفه نحو روبي، كم هذا مضحك؟ لقد أدركنا أنه يجب علينا كتابة كل هذه الأشياء في Go فقط لتلبية النقطة الأولى في القائمة المرجعية: يجب أن تكون أداة DevOps ثنائية ثابتة. ليس من المهم جدًا أن تكون Go أم لا، ولكن من الأفضل كتابة ثنائي ثابت في Go.
لقد استنفذنا طاقتنا، وأعدنا كتابة dapp في Go وأطلقنا عليه اسم werf. لم يعد Dapp مدعومًا، ولم يتم تطويره، ويعمل في بعض الإصدارات الأحدث، ولكن يوجد مسار ترقية مطلق إلى الأعلى، ويمكنك اتباعه.
لماذا تم إنشاء dapp؟
— هل يمكن أن تخبرنا بإيجاز عن سبب إنشاء التطبيق اللامركزي، وما هي المشكلات التي يحلها؟
ديمتري: السبب الأول هو في التجمع. في البداية، واجهنا مشكلات خطيرة في البناء عندما لم يكن لدى Docker إمكانات متعددة المراحل، لذلك قمنا بإنشاء متعدد المراحل بمفردنا. ثم واجهنا المزيد من المشكلات المتعلقة بتنظيف الصورة. كل من يستخدم CI/CD، عاجلاً وليس آجلاً، يواجه مشكلة وجود مجموعة من الصور المجمعة، وتحتاج بطريقة ما إلى تنظيف ما هو غير مطلوب وترك ما هو مطلوب.
السبب الثاني هو النشر. نعم، هناك هيلم، لكنه لا يحل سوى بعض المشاكل. ومن المضحك أنه مكتوب أن "Helm هو مدير الحزم لـ Kubernetes". بالضبط ما "". هناك أيضًا عبارة "مدير الحزم" - ما هو المتوقع المعتاد من مدير الحزم؟ نقول: "مدير الحزم - قم بتثبيت الحزمة!" ونتوقع منه أن يقول لنا: "تم تسليم الطرد".
من المثير للاهتمام أننا نقول: "Helm، قم بتثبيت الحزمة"، وعندما يرد بأنه قام بتثبيتها، اتضح أنه بدأ التثبيت للتو - أشار إلى Kubernetes: "قم بتشغيل هذا الشيء!"، وما إذا كان قد بدأ أم لا سواء كان يعمل أم لا، هيلم لا يحل هذه المشكلة على الإطلاق.
اتضح أن Helm هو مجرد معالج نصي يقوم بتحميل البيانات إلى Kubernetes.
ولكن كجزء من أي عملية نشر، نريد أن نعرف ما إذا كان التطبيق قد تم إصداره للإنتاج أم لا؟ يعني طرحه إلى المنتج أن التطبيق قد انتقل إلى هناك، وتم نشر الإصدار الجديد، وعلى الأقل لا يتعطل هناك ويستجيب بشكل صحيح. هيلم لا يحل هذه المشكلة بأي شكل من الأشكال. لحلها، تحتاج إلى بذل الكثير من الجهد، لأنك تحتاج إلى إعطاء Kubernetes الأمر لنشر ومراقبة ما يحدث هناك - سواء تم نشره أو طرحه. وهناك أيضًا الكثير من المهام المتعلقة بالنشر والتنظيف والتجميع.
خطط
هذا العام سنبدأ التنمية المحلية. نريد تحقيق ما كان موجودًا سابقًا في Vagrant - لقد كتبنا "vagrant up" وقمنا بنشر الأجهزة الافتراضية. نريد أن نصل إلى النقطة التي يوجد فيها مشروع في Git، ونكتب "werf up" هناك، وسيظهر نسخة محلية من هذا المشروع، منتشرة في mini-Kub محلي، مع ربط جميع الدلائل الملائمة للتطوير . اعتمادًا على لغة التطوير، يتم ذلك بشكل مختلف، ولكن مع ذلك، بحيث يمكن تنفيذ التطوير المحلي بسهولة ضمن الملفات المثبتة.
الخطوة التالية بالنسبة لنا هي الاستثمار في الراحة للمطورين. لنشر مشروع محليًا بسرعة باستخدام أداة واحدة، قم بتطويره ودفعه إلى Git، وسيتم طرحه أيضًا للمرحلة أو الاختبارات، اعتمادًا على المسارات، ثم استخدم نفس الأداة للانتقال إلى الإنتاج. تعد هذه الوحدة والتوحيد واستنساخ البنية التحتية من البيئة المحلية إلى المبيعات نقطة مهمة جدًا بالنسبة لنا. لكن هذا لم يتم تنفيذه بعد - نحن نخطط فقط للقيام به.
لكن المسار إلى dapp/werf كان دائمًا هو نفسه كما هو الحال مع Kubernetes في البداية. لقد واجهنا مشكلات، وقمنا بحلها باستخدام الحلول البديلة - لقد توصلنا إلى بعض الحلول لأنفسنا فيما يتعلق بالصدفة، لأي شيء. ثم حاولوا تصويب هذه الحلول بطريقة ما، وتعميمها ودمجها في ثنائيات في هذه الحالة، والتي نشاركها ببساطة.
هناك طريقة أخرى للنظر إلى هذه القصة بأكملها، من خلال القياس.
Kubernetes هو إطار سيارة بمحرك. لا توجد أبواب، زجاج، راديو، شجرة عيد الميلاد - لا شيء على الإطلاق. فقط الإطار والمحرك. وهناك هيلم - هذه هي عجلة القيادة. رائع - هناك عجلة قيادة، لكنك تحتاج أيضًا إلى دبوس توجيه ورف توجيه وعلبة تروس وعجلات، ولا يمكنك الاستغناء عنها.
في حالة werf، يعد هذا مكونًا آخر لـ Kubernetes. الآن فقط في إصدار ألفا من werf، على سبيل المثال، تم تجميع Helm داخل werf، لأننا سئمنا من القيام بذلك بأنفسنا. هناك العديد من الأسباب للقيام بذلك، سأخبرك بالتفصيل عن سبب قيامنا بتجميع الدفة بأكملها مع الحارث داخل werf .
الآن أصبح werf مكونًا أكثر تكاملاً. لقد حصلنا على عجلة قيادة جاهزة، دبوس توجيه - أنا لست جيدًا في السيارات، ولكن هذه كتلة كبيرة تحل بالفعل مجموعة واسعة من المشكلات. لا نحتاج إلى مراجعة الكتالوج بأنفسنا، واختيار جزء مقابل الآخر، والتفكير في كيفية ربطهما معًا. نحصل على مزيج جاهز يحل عددًا كبيرًا من المشكلات في وقت واحد. ولكن بداخله مبني من نفس المكونات مفتوحة المصدر، ولا يزال يستخدم Docker للتجميع، وHelm لبعض الوظائف، وهناك العديد من المكتبات الأخرى. هذه أداة متكاملة لإخراج CI/CD الرائع من الصندوق بسرعة وسهولة.
هل من الصعب صيانة Kubernetes؟
— أنت تتحدث عن التجربة التي بدأتها في استخدام Kubernetes، وهذا لك إطار، ومحرك، ويمكنك تعليق الكثير من الأشياء المختلفة عليه: الجسم، وعجلة القيادة، والمسمار على الدواسات، والمقاعد. السؤال الذي يطرح نفسه - ما مدى صعوبة دعم Kubernetes بالنسبة لك؟ لديك الكثير من الخبرة، ما مقدار الوقت والموارد التي تقضيها في دعم Kubernetes بمعزل عن كل شيء آخر؟
ديمتري: هذا سؤال صعب للغاية وللإجابة عليه، نحتاج إلى فهم ما هو الدعم وما نريده من Kubernetes. ربما يمكنك أن تكشف؟
— بقدر ما أعرف وكما أرى، ترغب العديد من الفرق الآن في تجربة Kubernetes. الجميع يسخرون أنفسهم له، ويضعونه على ركبهم. لدي شعور بأن الناس لا يفهمون دائمًا مدى تعقيد هذا النظام.
ديمتري: انها كذلك.
— ما مدى صعوبة استخدام Kubernetes وتثبيته من البداية حتى يصبح جاهزًا للإنتاج؟
ديمتري: ما مدى صعوبة زراعة القلب في رأيك؟ أفهم أن هذا سؤال مساومة. إن استخدام المشرط وعدم ارتكاب الأخطاء ليس بالأمر الصعب. إذا قالوا لك مكان القطع ومكان الخياطة، فإن الإجراء نفسه ليس معقدًا. من الصعب أن نضمن مرة تلو الأخرى أن كل شيء سينجح.
يعد تثبيت Kubernetes وتشغيله أمرًا سهلاً: فرخ! - تم التثبيت، وهناك الكثير من طرق التثبيت. ولكن ماذا يحدث عندما تنشأ المشاكل؟
تطرح الأسئلة دائمًا - ما الذي لم نأخذه بعين الاعتبار بعد؟ ما الذي لم نفعله بعد؟ ما هي معلمات Linux kernel التي تم تحديدها بشكل غير صحيح؟ يا رب، هل ذكرناهم أصلاً؟! ما هي مكونات Kubernetes التي قمنا بتسليمها وأيها لم نقم بتسليمها؟ تطرح آلاف الأسئلة، وللإجابة عليها، عليك قضاء 15-20 عامًا في هذه الصناعة.
لدي مثال حديث حول هذا الموضوع قد يكشف معنى المشكلة "هل يصعب الحفاظ على Kubernetes؟" منذ بعض الوقت، فكرنا بجدية فيما إذا كان ينبغي لنا أن نحاول تنفيذ Cilium كشبكة في Kubernetes.
اسمحوا لي أن أشرح ما هو Cilium. لدى Kubernetes العديد من التطبيقات المختلفة للنظام الفرعي للشبكات، وأحدها رائع جدًا - Cilium. ما هو معناها؟ في النواة، منذ بعض الوقت، أصبح من الممكن كتابة خطافات للنواة، والتي تغزو بطريقة أو بأخرى النظام الفرعي للشبكة والعديد من الأنظمة الفرعية الأخرى، وتسمح لك بتجاوز أجزاء كبيرة في النواة.
تحتوي نواة Linux تاريخيًا على مسار IP ومرشح زائد وجسور والعديد من المكونات القديمة المختلفة التي يبلغ عمرها 15 و20 و30 عامًا. بشكل عام، إنهم يعملون، كل شيء على ما يرام، ولكن الآن لديهم حاويات مكدسة، ويبدو وكأنه برج مكون من 15 طوبة فوق بعضها البعض، وتقف عليه على ساق واحدة - شعور غريب. وقد تطور هذا النظام تاريخياً مع العديد من الفروق الدقيقة، مثل الزائدة الدودية في الجسم. في بعض الحالات، توجد مشكلات في الأداء، على سبيل المثال.
هناك BPF رائع والقدرة على كتابة خطافات للنواة - قام الرجال بكتابة خطافات خاصة بهم للنواة. تأتي الحزمة إلى Linux kernel، ويتم إخراجها مباشرة عند الإدخال، ومعالجتها بنفسها كما ينبغي بدون جسور، بدون TCP، بدون مكدس IP - باختصار، تجاوز كل ما هو مكتوب في Linux kernel، ثم يبصقون بها إلى الحاوية.
ماذا حدث؟ أداء رائع جدًا، وميزات رائعة - رائع جدًا! لكننا ننظر إلى هذا ونرى أنه يوجد على كل جهاز برنامج يتصل بواجهة برمجة تطبيقات Kubernetes، وبناءً على البيانات التي يتلقاها من واجهة برمجة التطبيقات هذه، يقوم بإنشاء كود C وتجميع الثنائيات التي يتم تحميلها في النواة بحيث تعمل هذه الخطافات في مساحة النواة .
ماذا يحدث إذا حدث خطأ ما؟ نحن لا نعلم. لفهم هذا، تحتاج إلى قراءة كل هذا الكود، وفهم كل المنطق، ومن المدهش مدى صعوبة ذلك. ولكن، من ناحية أخرى، هناك هذه الجسور، ومرشحات الشبكة، وتوجيه IP - لم أقرأ كود المصدر الخاص بها، ولا حتى المهندسين الأربعين الذين يعملون في شركتنا. ربما القليل فقط يفهم بعض الأجزاء.
وما هو الفرق؟ اتضح أن هناك IP Rout، Linux kernel، وهناك أداة جديدة - ما الفرق الذي يحدثه، نحن لا نفهم أحدهما أو الآخر. لكننا نخشى استخدام شيء جديد - لماذا؟ لأنه إذا كان عمر الأداة 30 عامًا، فسيتم العثور على جميع الأخطاء خلال 30 عامًا، وتم التغلب على جميع الأخطاء ولا تحتاج إلى معرفة كل شيء - فهي تعمل مثل الصندوق الأسود وتعمل دائمًا. يعلم الجميع أي مفك براغي تشخيصي يجب لصقه في أي مكان، وما هو برنامج tcpdump الذي سيتم تشغيله في أي لحظة. يعرف الجميع الأدوات المساعدة التشخيصية جيدًا ويفهمون كيفية عمل هذه المجموعة من المكونات في Linux kernel - وليس كيفية عملها، ولكن كيفية استخدامها.
والهداب الرائع لم يبلغ من العمر 30 عامًا، ولم يبلغ من العمر بعد. Kubernetes لديه نفس المشكلة، نسخة. تم تثبيت Cilium بشكل مثالي، وتم تثبيت Kubernetes بشكل مثالي، ولكن عندما يحدث خطأ ما في الإنتاج، هل يمكنك أن تفهم بسرعة ما الخطأ الذي حدث في موقف حرج؟
عندما نقول هل من الصعب الحفاظ على Kubernetes - لا، إنه سهل للغاية، ونعم، إنه صعب للغاية. يعمل Kubernetes بشكل رائع بمفرده، ولكن مع وجود مليار فارق بسيط.
حول نهج "سأكون محظوظا".
— هل هناك شركات يكاد يكون من المؤكد ظهور هذه الفروق الدقيقة فيها؟ لنفترض أن Yandex ينقل فجأة جميع الخدمات إلى Kubernetes، وسيكون هناك حمولة ضخمة هناك.
ديمتري: لا، هذا ليس حديثاً عن الحمولة، بل عن أبسط الأشياء. على سبيل المثال، لدينا Kubernetes، وقمنا بنشر التطبيق هناك. كيف تعرف أنها تعمل؟ ببساطة لا توجد أداة جاهزة لفهم أن التطبيق لا يتعطل. لا يوجد نظام جاهز لإرسال التنبيهات، تحتاج إلى تكوين هذه التنبيهات وكل جدول زمني. ونحن نقوم بتحديث Kubernetes.
لدي أوبونتو 16.04. يمكنك القول أن هذه نسخة قديمة، لكننا مازلنا نعمل عليها لأنها LTS. يوجد systemd، والفارق الدقيق هو أنه لا يقوم بتنظيف المجموعات C. يقوم Kubernetes بإطلاق البودات، وإنشاء مجموعات C، ثم حذف البودات، وبطريقة ما يتبين - لا أتذكر التفاصيل، آسف - أن شرائح systemd باقية. وهذا يؤدي إلى حقيقة أنه مع مرور الوقت، تبدأ أي سيارة في التباطؤ بقوة. هذا ليس حتى سؤالاً حول التحميل العالي. إذا تم إطلاق البودات الدائمة، على سبيل المثال، إذا كان هناك Cron Job يقوم بإنشاء البودات باستمرار، فسيبدأ الجهاز الذي يعمل بنظام Ubuntu 16.04 في التباطؤ بعد أسبوع. سيكون هناك متوسط تحميل مرتفع باستمرار نظرًا لأنه تم إنشاء مجموعة من المجموعات C. هذه هي المشكلة التي سيواجهها أي شخص يقوم ببساطة بتثبيت Ubuntu 16 وKubernetes في الأعلى.
لنفترض أنه يقوم بطريقة ما بتحديث systemd أو أي شيء آخر، ولكن في Linux kernel حتى 4.16 يكون الأمر أكثر تسلية - عندما تحذف مجموعات C، فإنها تتسرب إلى النواة ولا يتم حذفها فعليًا. لذلك، بعد شهر من العمل على هذا الجهاز، سيكون من المستحيل إلقاء نظرة على إحصائيات الذاكرة الخاصة بالمواقد. نخرج ملفًا، ونلفه في البرنامج، ويتم تشغيل ملف واحد لمدة 15 ثانية، لأن النواة تستغرق وقتًا طويلاً جدًا لحساب مليون مجموعة C داخل نفسها، والتي يبدو أنها محذوفة، ولكن لا - إنها تتسرب .
لا يزال هناك الكثير من هذه الأشياء الصغيرة هنا وهناك. هذه ليست مشكلة قد تواجهها الشركات العملاقة أحيانًا تحت أحمال ثقيلة جدًا - لا، إنها مسألة أشياء يومية. يمكن للأشخاص العيش على هذا النحو لعدة أشهر - لقد قاموا بتثبيت Kubernetes ونشروا التطبيق - ويبدو أنه يعمل. بالنسبة لكثير من الناس هذا أمر طبيعي. لن يعرفوا حتى أن هذا التطبيق سيتعطل لسبب ما، ولن يتلقوا تنبيهًا، ولكن هذا هو المعيار بالنسبة لهم. في السابق، كنا نعيش على أجهزة افتراضية دون مراقبة، والآن انتقلنا إلى Kubernetes، أيضًا دون مراقبة - ما الفرق؟
والسؤال هو أننا عندما نسير على الجليد، فإننا لا نعرف سمكه أبدًا إلا إذا قمنا بقياسه مسبقًا. كثير من الناس يمشون ولا يقلقون، لأنهم مشوا من قبل.
من وجهة نظري، فإن الفارق الدقيق والتعقيد في تشغيل أي نظام هو التأكد من أن سمك الجليد يكفي تمامًا لحل مشاكلنا. هذا ما نتحدث عنه.
يبدو لي أن هناك الكثير من أساليب "سأكون محظوظًا" في مجال تكنولوجيا المعلومات. يقوم العديد من الأشخاص بتثبيت البرامج واستخدام مكتبات البرامج على أمل أن يحالفهم الحظ. بشكل عام، كثير من الناس محظوظون. ربما هذا هو السبب في أنه يعمل.
— من تقييمي المتشائم، يبدو الأمر كما يلي: عندما تكون المخاطر عالية، ويجب أن يعمل التطبيق، فستكون هناك حاجة إلى الدعم من Flaunt، ربما من Red Hat، أو تحتاج إلى فريق داخلي خاص بك مخصص خصيصًا لـ Kubernetes، وهو جاهز لسحبه.
ديمتري: موضوعيا، وهذا هو الحال. إن الدخول في قصة Kubernetes لفريق صغير بمفردك ينطوي على عدد من المخاطر.
هل نحتاج إلى حاويات؟
— هل يمكنك أن تخبرنا عن مدى انتشار نظام Kubernetes في روسيا؟
ديمتري: لا أملك هذه البيانات، ولست متأكدًا من أن أي شخص آخر لديه هذه البيانات. نقول: "Kubernetes، Kubernetes"، ولكن هناك طريقة أخرى للنظر إلى هذه القضية. لا أعرف أيضًا مدى انتشار الحاويات، لكنني أعرف رقمًا من التقارير الموجودة على الإنترنت يفيد بأن 70% من الحاويات يتم تنسيقها بواسطة Kubernetes. لقد كان مصدرًا موثوقًا لعينة كبيرة إلى حد ما حول العالم.
ثم سؤال آخر هل نحتاج إلى حاويات؟ شعوري الشخصي والموقف العام لشركة Flant هو أن Kubernetes هو المعيار الفعلي.
لن يكون هناك شيء سوى Kubernetes.
يعد هذا بمثابة تغيير مطلق في مجال إدارة البنية التحتية. فقط مطلق - هذا كل شيء، لا مزيد من Ansible، Chef، الأجهزة الافتراضية، Terraform. أنا لا أتحدث عن أساليب المزرعة الجماعية القديمة. Kubernetes هو التغيير المطلقوالآن سيكون الأمر هكذا فقط.
من الواضح أن الأمر يستغرق عامين بالنسبة للبعض، والبعض الآخر لعقود من الزمن لتحقيق ذلك. ليس لدي أدنى شك في أنه لن يكون هناك سوى Kubernetes وهذا المظهر الجديد: لم نعد نلحق الضرر بنظام التشغيل، بل نستخدمه البنية التحتية كرمز، ليس فقط باستخدام الكود، ولكن باستخدام yml - وهي بنية تحتية موصوفة بشكل تصريحي. لدي شعور بأن الأمر سيكون دائمًا هكذا.
— أي أن تلك الشركات التي لم تتحول بعد إلى Kubernetes ستتحول إليها بالتأكيد أو ستبقى في غياهب النسيان. لقد فهمتك بشكل صحيح؟
ديمتري: وهذا أيضا ليس صحيحا تماما. على سبيل المثال، إذا كانت لدينا مهمة تشغيل خادم DNS، فيمكن تشغيله على FreeBSD 4.10 ويمكن أن يعمل بشكل مثالي لمدة 20 عامًا. مجرد العمل وهذا كل شيء. ربما خلال 20 عامًا، سيلزم تحديث شيء ما مرة واحدة. إذا كنا نتحدث عن البرنامج بالتنسيق الذي أطلقناه ويعمل بالفعل لسنوات عديدة دون أي تحديثات، دون إجراء تغييرات، فلن يكون هناك Kubernetes بالطبع. ليست هناك حاجة له هناك.
كل ما يتعلق بـ CI/CD - حيثما تكون هناك حاجة إلى التسليم المستمر، حيث تحتاج إلى تحديث الإصدارات، وإجراء تغييرات نشطة، حيثما تحتاج إلى بناء التسامح مع الأخطاء - فقط Kubernetes.
حول الخدمات المصغرة
- هنا لدي تنافر طفيف. للعمل مع Kubernetes، تحتاج إلى دعم خارجي أو داخلي - هذه هي النقطة الأولى. ثانيًا، عندما نبدأ للتو في التطوير، نكون شركة ناشئة صغيرة، وليس لدينا أي شيء بعد، وقد يكون تطوير Kubernetes أو بنية الخدمات الصغيرة بشكل عام معقدًا وليس له ما يبرره اقتصاديًا دائمًا. أنا مهتم برأيك - هل تحتاج الشركات الناشئة إلى البدء على الفور في الكتابة لـ Kubernetes من الصفر، أم أنها لا تزال قادرة على كتابة متراصة، ثم تأتي فقط إلى Kubernetes؟
ديمتري: سؤال رائع. لدي حديث عن الخدمات المصغرة لقد واجهت في كثير من الأحيان أشخاصًا يحاولون طرق المسامير بالمجهر. النهج نفسه صحيح، فنحن أنفسنا نصمم برامجنا الداخلية بهذه الطريقة. ولكن عندما تفعل ذلك، عليك أن تفهم بوضوح ما تفعله. الكلمة التي أكرهها أكثر فيما يتعلق بالخدمات الصغيرة هي "الصغرى". تاريخيًا، نشأت هذه الكلمة هناك، ولسبب ما يعتقد الناس أن الميكرو صغير جدًا، أقل من ملليمتر، مثل الميكرومتر. هذا خطأ.
على سبيل المثال، هناك كتلة متراصة كتبها 300 شخص، وكل من شارك في التطوير يدرك أن هناك مشاكل هناك، ويجب تقسيمها إلى أجزاء صغيرة - حوالي 10 قطع، كل منها مكتوبة بواسطة 30 شخصًا في الحد الأدنى من الإصدار. هذا مهم وضروري ورائع. ولكن عندما تأتي إلينا شركة ناشئة، حيث كتب 3 رجال رائعين وموهوبين 60 خدمة صغيرة على ركبهم، في كل مرة أبحث فيها عن Corvalol.
يبدو لي أنه قد تم الحديث عن هذا بالفعل آلاف المرات - لقد حصلنا على كتلة متراصة موزعة بشكل أو بآخر. وهذا ليس له ما يبرره اقتصاديا، فهو صعب للغاية بشكل عام في كل شيء. لقد رأيت هذا مرات عديدة لدرجة أنه يؤلمني حقًا، لذلك أواصل الحديث عنه.
فيما يتعلق بالسؤال الأولي، هناك تعارض بين حقيقة أن Kubernetes مخيف الاستخدام من ناحية، لأنه ليس من الواضح ما الذي يمكن أن ينكسر هناك أو لا يعمل، ومن ناحية أخرى، من الواضح أن كل شيء يسير على هذا النحو ولن يكون هناك شيء سوى Kubernetes. إجابة - قم بوزن مقدار الفائدة التي تأتي، وحجم المهام التي يمكنك حلها. وهذا على جانب واحد من المقياس. من ناحية أخرى، هناك مخاطر مرتبطة بالتوقف عن العمل أو بانخفاض وقت الاستجابة ومستوى التوفر - مع انخفاض مؤشرات الأداء.
ها هو - إما أن نتحرك بسرعة، ويتيح لنا Kubernetes القيام بأشياء كثيرة بشكل أسرع وأفضل، أو نستخدم حلولًا موثوقة تم اختبارها عبر الزمن، ولكننا نتحرك ببطء أكبر. هذا هو الاختيار الذي يجب على كل شركة القيام به. يمكنك التفكير فيه كطريق في الغابة - عندما تمشي لأول مرة، يمكنك أن تقابل ثعبانًا أو نمرًا أو غريرًا مسعورًا، وعندما تمشي 10 مرات، تكون قد مشيت على الطريق، وأزلته الفروع والمشي أسهل. في كل مرة يصبح المسار أوسع. ثم إنه طريق أسفلتي، وبعد ذلك شارع جميل.
Kubernetes لا يقف ساكنا. السؤال مرة أخرى: Kubernetes، من ناحية، هو 4-5 ثنائيات، من ناحية أخرى، هو النظام البيئي بأكمله. هذا هو نظام التشغيل الذي لدينا على أجهزتنا. ما هذا؟ أوبونتو أو التحف؟ هذه هي نواة لينكس، وهي عبارة عن مجموعة من المكونات الإضافية. كل هذه الأشياء هنا، تم إلقاء ثعبان سام من الطريق، وتم نصب سياج هناك. يتطور Kubernetes بسرعة وديناميكية كبيرة، وحجم المخاطر، وحجم المجهول يتناقص كل شهر، وبالتالي، تتم إعادة توازن هذه المقاييس.
ردًا على سؤال حول ما يجب أن تفعله الشركة الناشئة، أود أن أقول - تعال إلى Flaunt، وادفع 150 ألف روبل واحصل على خدمة DevOps سهلة الاستخدام. إذا كنت شركة ناشئة صغيرة مع عدد قليل من المطورين، فهذا ينجح. بدلاً من توظيف DevOps الخاص بك، والذي سيحتاج إلى تعلم كيفية حل مشاكلك ودفع الراتب في هذا الوقت، سوف تحصل على حل جاهز لجميع المشكلات. نعم، هناك بعض العيوب. نحن، كمتعاقدين خارجيين، لا يمكننا أن نكون منخرطين إلى هذا الحد ونستجيب بسرعة للتغييرات. لكن لدينا الكثير من الخبرة والممارسات الجاهزة. نحن نضمن أننا سنكتشف ذلك بسرعة في أي موقف ونقوم بإقامة أي Kubernetes من بين الأموات.
أوصي بشدة بالاستعانة بمصادر خارجية للشركات الناشئة والشركات القائمة حتى حجم يمكنك من خلاله تخصيص فريق من 10 أشخاص للعمليات، لأنه لا فائدة من خلاف ذلك. ومن المؤكد أنه من المنطقي الاستعانة بمصادر خارجية لهذا.
حول أمازون وجوجل
— هل يمكن اعتبار مضيف من حل من أمازون أو جوجل بمثابة مصدر خارجي؟
ديمتري: نعم بالطبع، وهذا يحل عددا من القضايا. ولكن مرة أخرى هناك فروق دقيقة. لا تزال بحاجة إلى فهم كيفية استخدامه. على سبيل المثال، هناك آلاف الأشياء الصغيرة في عمل Amazon AWS: يجب تسخين Load Balancer أو كتابة طلب مسبقًا "يا شباب، سنتلقى حركة المرور، قم بتسخين Load Balancer لنا!" أنت بحاجة إلى معرفة هذه الفروق الدقيقة.
عندما تلجأ إلى الأشخاص المتخصصين في هذا، فإنك تغلق كل الأشياء النموذجية تقريبًا. لدينا الآن 40 مهندسًا، ومن المحتمل أن يصل عددهم إلى 60 مهندسًا بحلول نهاية العام، وقد واجهنا كل هذه الأمور بالتأكيد. حتى لو واجهنا هذه المشكلة مرة أخرى في بعض المشاريع، فإننا نسأل بعضنا البعض بسرعة ونعرف كيفية حلها.
ربما يكون الجواب هو - بالطبع، القصة المستضافة تجعل بعض الأجزاء أسهل. والسؤال هو ما إذا كنت على استعداد للوثوق بهؤلاء المضيفين وما إذا كانوا سيحلون مشاكلك. لقد كان أداء أمازون وجوجل جيدًا. لجميع حالاتنا - بالضبط. ليس لدينا المزيد من التجارب الإيجابية. جميع السحب الأخرى التي حاولنا العمل معها تخلق الكثير من المشاكل - Ager، وكل ما هو موجود في روسيا، وجميع أنواع OpenStack في تطبيقات مختلفة: Headster، Overage - كل ما تريد. كلهم يخلقون مشاكل لا تريد حلها.
لذلك، الجواب هو نعم، ولكن في الواقع، لا يوجد الكثير من الحلول المستضافة الناضجة.
من يحتاج إلى Kubernetes؟
- ومع ذلك، من يحتاج إلى Kubernetes؟ من الذي يجب عليه التحول بالفعل إلى Kubernetes، من هو عميل Flaunt النموذجي الذي يأتي خصيصًا لـ Kubernetes؟
ديمتري: هذا سؤال مثير للاهتمام، لأنه الآن، في أعقاب Kubernetes، يأتي إلينا الكثير من الأشخاص: "يا شباب، نحن نعلم أنكم تفعلون Kubernetes، افعلوا ذلك من أجلنا!" نجيبهم: "أيها السادة، نحن لا نقوم بعمل Kubernetes، بل نحث على كل ما يتعلق به". لأنه من المستحيل حاليًا صنع منتج دون إجراء جميع عمليات CI/CD وهذه القصة بأكملها. لقد ابتعد الجميع عن التقسيم الذي لدينا تنمية بالتنمية، ومن ثم الاستغلال بالاستغلال.
يتوقع عملاؤنا أشياء مختلفة، لكن الجميع ينتظر معجزة جيدة أن لديهم مشاكل معينة، والآن - قفز! — Kubernetes سوف يحلها. يؤمن الناس بالمعجزات. إنهم يدركون في أذهانهم أنه لن تكون هناك معجزة، لكنهم يأملون في أرواحهم - ماذا لو أن Kubernetes سيحل لنا الآن كل شيء، يتحدثون كثيرًا عن ذلك! فجأة الآن - يعطس! - ورصاصة فضية، عطس! - ولدينا وقت تشغيل بنسبة 100%، ويمكن لجميع المطورين إصدار أي شيء يدخل مرحلة الإنتاج 50 مرة، دون أن يتعطل. بشكل عام، معجزة!
عندما يأتي إلينا مثل هؤلاء نقول: "آسف، لكن لا يوجد شيء اسمه معجزة". لكي تكون بصحة جيدة، عليك أن تأكل جيدًا وتمارس الرياضة. للحصول على منتج موثوق، يجب أن يتم تصنيعه بشكل موثوق. للحصول على CI/CD ملائم، يجب أن تجعله هكذا. هذا كثير من العمل الذي يجب القيام به.
الإجابة على سؤال من يحتاج إلى Kubernetes - لا أحد يحتاج إلى Kubernetes.
لدى بعض الأشخاص فكرة خاطئة بأنهم بحاجة إلى Kubernetes. يحتاج الناس، لديهم حاجة عميقة للتوقف عن التفكير والدراسة والاهتمام بكل مشاكل البنية التحتية ومشاكل تشغيل تطبيقاتهم. إنهم يريدون أن تعمل التطبيقات فقط وتنشر فقط. بالنسبة لهم، يعد Kubernetes بمثابة الأمل في أن يتوقفوا عن سماع القصة التي تقول "كنا مستلقين هناك"، أو "لا يمكننا طرحها"، أو أي شيء آخر.
عادة ما يأتي إلينا المدير الفني. يسألونه شيئين: من ناحية، أعطنا ميزات، ومن ناحية أخرى، الاستقرار. نقترح عليك أن تأخذ الأمر على عاتقك وتفعله. الحل السحري، أو بالأحرى، هو أنك ستتوقف عن التفكير في هذه المشاكل وإضاعة الوقت. سيكون لديك أشخاص مميزون سيغلقون هذه المشكلة.
إن الصياغة التي نحتاجها نحن أو أي شخص آخر إلى Kubernetes غير صحيحة.
يحتاج المسؤولون حقًا إلى Kubernetes، لأنها لعبة مثيرة جدًا للاهتمام يمكنك اللعب بها والتعديل عليها. لنكن صادقين - الجميع يحب الألعاب. نحن جميعا أطفال في مكان ما، وعندما نرى واحدة جديدة، نريد أن نلعبها. بالنسبة للبعض، تم تثبيط هذا، على سبيل المثال، في الإدارة، لأنهم لعبوا بالفعل بما فيه الكفاية وهم متعبون بالفعل لدرجة أنهم ببساطة لا يريدون ذلك. ولكن هذا لا يضيع تماما لأحد. على سبيل المثال، إذا كنت قد سئمت من الألعاب في مجال إدارة النظام وDevOps لفترة طويلة، فما زلت أحب الألعاب، وما زلت أشتري بعض الألعاب الجديدة. كل الناس، بطريقة أو بأخرى، لا يزالون يريدون نوعا من الألعاب.
لا حاجة للعب مع الإنتاج. كل ما أوصي بشدة بعدم القيام به وما أراه الآن بشكل جماعي: "أوه، لعبة جديدة!" - ركضوا لشرائه، اشتروه وقالوا: "دعونا نأخذه إلى المدرسة الآن ونعرضه على جميع أصدقائنا". لا تفعل هذا. أعتذر، أطفالي يكبرون للتو، أرى شيئًا ما عند الأطفال باستمرار، وألاحظه في نفسي، ثم أعممه على الآخرين.
الجواب النهائي هو: لست بحاجة إلى Kubernetes. تحتاج إلى حل مشاكلك.
ما يمكنك تحقيقه هو:
- همز لا يسقط.
- وحتى لو حاول أن يسقط، فنحن نعرف ذلك مسبقًا، ويمكننا أن نضع شيئًا فيه؛
- يمكننا تغييره بالسرعة التي تتطلبها أعمالنا، ويمكننا القيام بذلك بسهولة، ولا يسبب لنا أي مشاكل.
هناك نوعان من الاحتياجات الحقيقية: الموثوقية والديناميكية/المرونة في الطرح. كل من يقوم حاليًا بتنفيذ نوع ما من مشاريع تكنولوجيا المعلومات، بغض النظر عن نوع العمل - الناعم لتسهيل العالم، ومن يفهم ذلك، يحتاج إلى حل هذه الاحتياجات. Kubernetes مع النهج الصحيح، مع الفهم الصحيح والخبرة الكافية يسمح لك بحلها.
حول الخادم
— إذا نظرت إلى المستقبل قليلاً، ثم حاولت حل مشكلة عدم وجود مشاكل في البنية التحتية، مع سرعة النشر وسرعة تغيير التطبيق، تظهر حلول جديدة، على سبيل المثال، بدون خادم. هل تشعر بأي احتمال في هذا الاتجاه، ولنقل، خطرًا على Kubernetes والحلول المماثلة؟
ديمتري: هنا نحتاج إلى الإدلاء بملاحظة مرة أخرى بأنني لست عرافًا يتطلع إلى الأمام ويقول - سيكون الأمر هكذا! على الرغم من أنني فعلت نفس الشيء. أنظر إلى قدمي وأرى هناك مجموعة من المشاكل، على سبيل المثال، كيفية عمل الترانزستورات في الكمبيوتر. إنه مضحك، أليس كذلك؟ نحن نواجه بعض الأخطاء في وحدة المعالجة المركزية.
جعل الخوادم بدون خوادم موثوقة ورخيصة وفعالة ومريحة، مما يؤدي إلى حل جميع مشكلات النظام البيئي. وأنا أتفق هنا مع إيلون ماسك في أن هناك حاجة إلى كوكب ثانٍ لخلق التسامح مع الخطأ لدى البشرية. على الرغم من أنني لا أعرف ما يقوله، إلا أنني أفهم أنني لست مستعدًا للسفر إلى المريخ بنفسي ولن يحدث ذلك غدًا.
مع عدم وجود خادم، من الواضح أن هذا أمر صحيح من الناحية الأيديولوجية، مثل التسامح مع الخطأ بالنسبة للبشرية - وجود كوكبين أفضل من كوكب واحد. ولكن كيف نفعل ذلك الآن؟ لا يمثل إرسال رحلة استكشافية واحدة مشكلة إذا ركزت جهودك عليها. أعتقد أن إرسال عدة بعثات وتوطين عدة آلاف من الأشخاص هناك أمر واقعي أيضًا. لكن جعلها متسامحة تمامًا مع الأخطاء بحيث يعيش نصف البشرية هناك، يبدو لي الآن مستحيلًا، ولا يتم أخذه في الاعتبار.
مع وجود خادم واحد لواحد: الأمر رائع، لكنه بعيد عن مشاكل عام 2019. أقرب إلى عام 2030 - دعونا نعيش لنرى ذلك. ليس لدي أدنى شك في أننا سنعيش، سنعيش بالتأكيد (كرر قبل الذهاب إلى السرير)، لكننا الآن بحاجة إلى حل مشاكل أخرى. إنه مثل الإيمان بحكاية المهر الخيالية قوس قزح. نعم، يتم حل بضعة بالمائة من الحالات، ويتم حلها بشكل مثالي، ولكن بشكل شخصي، بدون خادم هو قوس قزح... بالنسبة لي، هذا الموضوع بعيد جدًا وغير مفهوم للغاية. أنا لست مستعدا للحديث. في عام 2019، لا يمكنك كتابة تطبيق واحد بدون خادم.
كيف سيتطور نظام Kubernetes؟
— بينما نتحرك نحو هذا المستقبل البعيد الذي يحتمل أن يكون رائعًا، كيف تعتقد أن Kubernetes والنظام البيئي المحيط به سيتطور؟
ديمتري: لقد فكرت في هذا الأمر كثيرًا ولدي إجابة واضحة. الأول هو الحالة الكاملة - ففي نهاية المطاف، من الأسهل القيام بالحالة عديمة الجنسية. استثمر Kubernetes في البداية المزيد في هذا الأمر، وبدأ كل شيء به. يعمل برنامج Stateless بشكل مثالي تقريبًا في Kubernetes، ولا يوجد ما يدعو للشكوى. لا يزال هناك الكثير من المشاكل، أو بالأحرى، الفروق الدقيقة. كل شيء هناك يعمل بشكل رائع بالنسبة لنا، ولكن هذا نحن. سوف يستغرق الأمر بضع سنوات أخرى على الأقل حتى ينجح هذا الأمر مع الجميع. وهذا ليس مؤشرا محسوبا، ولكن شعوري من رأسي.
باختصار، يجب أن يتطور Statefull بقوة كبيرة جدًا، لأن جميع تطبيقاتنا تخزن الحالة؛ ولا توجد تطبيقات عديمة الحالة. هذا وهم، فأنت تحتاج دائمًا إلى نوع من قاعدة البيانات وشيء آخر. يدور برنامج Statefull حول تصحيح كل ما هو ممكن، وإصلاح جميع الأخطاء، وتحسين جميع المشكلات التي تتم مواجهتها حاليًا - دعنا نسميها التبني.
مستوى المجهول، ومستوى المشاكل التي لم يتم حلها، ومستوى احتمال مواجهة شيء ما سينخفض بشكل كبير. هذه قصة مهمة. والمشغلون - كل ما يتعلق بتدوين منطق الإدارة، ومنطق التحكم من أجل الحصول على خدمة سهلة: خدمة MySQL السهلة، وخدمة RabbitMQ السهلة، وخدمة Memcache السهلة - بشكل عام، كل هذه المكونات التي نحتاج إلى ضمان العمل بها الصندوق. وهذا يحل المشكلة التي تتمثل في أننا نريد قاعدة بيانات، لكننا لا نريد إدارتها، أو أننا نريد Kubernetes، لكننا لا نريد إدارتها.
ستكون قصة تطوير المشغل بشكل أو بآخر مهمة في العامين المقبلين.
أعتقد أن سهولة الاستخدام يجب أن تزيد بشكل كبير - سيصبح الصندوق أسودًا أكثر فأكثر، وأكثر موثوقية، مع المزيد والمزيد من المقابض البسيطة.
لقد استمعت ذات مرة إلى مقابلة قديمة مع إسحاق أسيموف من الثمانينيات على موقع YouTube على برنامج Saturday Night Live - وهو برنامج مثل Urgant، مثير للاهتمام فقط. سألوه عن مستقبل أجهزة الكمبيوتر. وقال إن المستقبل في البساطة، تماما مثل الراديو. كان جهاز استقبال الراديو في الأصل شيئًا معقدًا. لالتقاط موجة، كان عليك إدارة المقابض لمدة 80 دقيقة، وإدارة الأسياخ ومعرفة كيفية عمل كل شيء بشكل عام، وفهم فيزياء نقل الموجات الراديوية. ونتيجة لذلك، لم يتبق سوى مقبض واحد في الراديو.
الآن في عام 2019 ما الراديو؟ وفي السيارة، يجد جهاز الاستقبال جميع الموجات وأسماء المحطات. ولم تتغير فيزياء العملية منذ 100 عام، ولكن سهولة الاستخدام تغيرت. الآن، وليس الآن فقط، في عام 1980، عندما كانت هناك مقابلة مع أزيموف، استخدم الجميع الراديو ولم يفكر أحد في كيفية عمله. لقد نجحت دائمًا - وهذا أمر مسلم به.
ثم قال أزيموف أن الأمر سيكون نفسه مع أجهزة الكمبيوتر - سوف تزيد سهولة الاستخدام. بينما في عام 1980 كان عليك أن تتدرب على الضغط على الأزرار الموجودة على جهاز الكمبيوتر، لن يكون هذا هو الحال في المستقبل.
لدي شعور أنه مع Kubernetes ومع البنية التحتية ستكون هناك أيضًا زيادة كبيرة في سهولة الاستخدام. هذا، في رأيي، واضح - إنه يقع على السطح.
ماذا تفعل مع المهندسين؟
— ماذا سيحدث بعد ذلك للمهندسين ومسؤولي النظام الذين يدعمون Kubernetes؟
ديمتري: ماذا حدث للمحاسب بعد ظهور 1C؟ عن المشابه. قبل ذلك، كانوا يعتمدون على الورق - الآن في البرنامج. لقد زادت إنتاجية العمل بأضعاف مضاعفة، لكن العمل نفسه لم يختف. إذا كان الأمر يتطلب في السابق 10 مهندسين لتركيب مصباح كهربائي، فإن مهندسًا واحدًا سيكون كافيًا الآن.
يبدو لي أن حجم البرامج وعدد المهام ينمو الآن بمعدل أسرع من ظهور DevOps الجديدة وتتزايد الكفاءة. هناك نقص محدد في السوق في الوقت الحالي وسيستمر لفترة طويلة. في وقت لاحق، سيعود كل شيء إلى نوع ما من الحالة الطبيعية، حيث ستزداد كفاءة العمل، وسيكون هناك المزيد والمزيد من عدم وجود خادم، وسيتم إرفاق خلية عصبية بـ Kubernetes، والتي ستختار جميع الموارد تمامًا حسب الحاجة، وبشكل عام سوف افعل كل شيء بنفسه، كما ينبغي - فالشخص يبتعد فقط ولا يتدخل.
لكن سيظل هناك شخص ما بحاجة إلى اتخاذ القرارات. ومن الواضح أن مستوى مؤهلات وتخصص هذا الشخص أعلى. في الوقت الحاضر، في قسم المحاسبة، لا تحتاج إلى 10 موظفين يحفظون الدفاتر حتى لا تتعب أيديهم. إنه ببساطة ليس ضروريا. يتم مسح العديد من المستندات ضوئيًا والتعرف عليها تلقائيًا بواسطة نظام إدارة المستندات الإلكتروني. يكفي وجود محاسب رئيسي ذكي يتمتع بالفعل بمهارات أكبر بكثير ويتمتع بفهم جيد.
بشكل عام، هذا هو الطريق الصحيح في جميع الصناعات. الأمر نفسه بالنسبة للسيارات: في السابق، كانت السيارة تأتي مع ميكانيكي وثلاثة سائقين. في الوقت الحاضر، أصبحت قيادة السيارة عملية بسيطة نشارك فيها جميعًا كل يوم. لا أحد يعتقد أن السيارة شيء معقد.
لن تذهب DevOps أو هندسة الأنظمة إلى أي مكان - سيزداد العمل والكفاءة على مستوى عالٍ.
— سمعت أيضًا فكرة مثيرة للاهتمام وهي أن العمل سيزداد بالفعل.
ديمتري: بالطبع مائة بالمائة! لأن كمية البرامج التي نكتبها تتزايد باستمرار. يتزايد باستمرار عدد المشكلات التي نحلها باستخدام البرامج. حجم العمل آخذ في الازدياد. الآن أصبح سوق DevOps محمومًا بشكل رهيب. ويمكن ملاحظة ذلك في توقعات الراتب. بطريقة جيدة، دون الخوض في التفاصيل، يجب أن يكون هناك صغار يريدون X، ومتوسطون يريدون 1,5X، وكبار السن يريدون 2X. والآن، إذا نظرت إلى سوق رواتب DevOps في موسكو، فستجد أن المبتدئ يريد من X إلى 3X ويريد كبير السن من X إلى 3X.
لا أحد يعرف كم يكلف. يتم قياس مستوى الراتب من خلال ثقتك بنفسك، بصراحة، سوق محموم للغاية.
بالطبع، سيتغير هذا الوضع قريبًا جدًا - يجب أن يحدث بعض التشبع. هذا ليس هو الحال مع تطوير البرمجيات - على الرغم من حقيقة أن الجميع يحتاج إلى مطورين، والجميع يحتاج إلى مطورين جيدين، فإن السوق يفهم من يستحق ماذا - استقرت الصناعة. هذا ليس هو الحال مع DevOps هذه الأيام.
— مما سمعته، خلصت إلى أن مسؤول النظام الحالي لا ينبغي أن يقلق كثيرًا، ولكن حان الوقت لرفع مستوى مهاراته والاستعداد لحقيقة أنه سيكون هناك المزيد من العمل غدًا، ولكن سيكون مؤهلاً بدرجة أكبر.
ديمتري: مئة بالمئة. بشكل عام نحن نعيش في عام 2019 وقاعدة الحياة هي: التعلم مدى الحياة - نتعلم طوال حياتنا. يبدو لي أن الجميع يعرف هذا ويشعر به الآن، لكن لا يكفي أن تعرفه - عليك أن تفعل ذلك. كل يوم يجب أن نتغير. إذا لم نفعل ذلك، فسوف نسقط عاجلا أم آجلا على هامش المهنة.
كن مستعدًا للمنعطفات الحادة بزاوية 180 درجة. لا أستبعد الموقف الذي يتغير فيه شيء ما بشكل جذري، ويتم اختراع شيء جديد - يحدث ذلك. قفز! - ونحن الآن نتصرف بشكل مختلف. من المهم أن تكون مستعدًا لذلك ولا داعي للقلق. قد يحدث أن كل ما أفعله غدا سيكون غير ضروري - لا شيء، لقد درست طوال حياتي وأنا على استعداد لتعلم شيء آخر. ليست مشكلة. ليست هناك حاجة للخوف من الأمان الوظيفي، ولكن عليك أن تكون مستعدًا لتعلم شيء جديد باستمرار.
رغبات ودقيقة من الإعلانات
- هل لديك أي رغبة؟
ديمتري: نعم، لدي عدة رغبات.
الأول والتجاري - اشترك في . عزيزي القراء، انتقل إلى موقع يوتيوب واشترك في قناتنا. في غضون شهر تقريبًا، سنبدأ التوسع النشط في خدمة الفيديو. وسيكون لدينا الكثير من المحتوى التعليمي حول Kubernetes، المفتوح والمتنوع: بدءًا من الأشياء العملية، وصولاً إلى المختبرات، إلى الأشياء النظرية الأساسية العميقة وكيفية استخدام Kubernetes في مستوى المبادئ والأنماط.
الرغبة التجارية الثانية - اذهب إلى ونضع النجوم لأننا نتغذى عليها. إذا لم تعطنا النجوم، فلن يكون لدينا أي شيء نأكله. إنها مثل المانا في لعبة كمبيوتر. نحن نفعل شيئًا ما، ونفعله، ونحاول، ويقول أحدهم إن هذه دراجات فظيعة، ويقول شخص آخر إن كل شيء ليس على ما يرام، لكننا نستمر ونتصرف بأمانة تامة. نرى مشكلة ونحلها ونشارك تجربتنا. لذلك أعطنا نجمة، لن تبتعد عنك، بل ستأتي إلينا، لأننا نتغذى عليها.
ثالثًا، رغبة مهمة ولم تعد تجارية - التوقف عن الإيمان بالحكايات الخيالية. أنتم محترفون. DevOps هي مهنة جادة ومسؤولة للغاية. التوقف عن اللعب في مكان العمل. دعها تنقر لك وسوف تفهم ذلك. تخيل أنك أتيت إلى المستشفى، وهناك يقوم الطبيب بإجراء التجارب عليك. أفهم أن هذا قد يكون مسيئًا لشخص ما، ولكن على الأرجح، لا يتعلق الأمر بك، بل يتعلق بشخص آخر. اطلب من الآخرين التوقف أيضًا. هذا يدمر حياتنا جميعًا حقًا - يبدأ الكثيرون في التعامل مع العمليات والمسؤولين وDevOps على أنهم رجال كسروا شيئًا ما مرة أخرى. كان هذا "مكسورًا" في أغلب الأحيان لأننا ذهبنا للعب ولم ننظر بوعي بارد إلى أن هذا هو الحال، وهذا هو الحال.
هذا لا يعني أنه لا يجب عليك التجربة. نحن بحاجة إلى التجربة، ونحن نفعل ذلك بأنفسنا. لنكون صادقين، نحن أنفسنا نلعب أحيانًا الألعاب - وهذا بالطبع أمر سيء للغاية، لكن لا يوجد شيء بشري غريب علينا. لنعلن أن عام 2019 هو عام التجارب الجادة والمدروسة، وليس عام ألعاب الإنتاج. ربما لذلك.
- شكراً جزيلاً!
ديمتري: شكرًا لك، فيتالي، على الوقت وعلى المقابلة. أعزائي القراء، شكرًا جزيلاً لكم إذا وصلتم إلى هذه النقطة فجأة. آمل أن نكون قد جلبنا لك بعض الأفكار على الأقل.
في المقابلة، تطرق ديمتري إلى مسألة Werf. الآن أصبح هذا سكينًا سويسريًا عالميًا يحل جميع المشكلات تقريبًا. ولكنها لم تكن كذلك دائما. على في المهرجان سيخبرك ديمتري ستولياروف عن هذه الأداة بالتفصيل. في التقرير سيكون هناك كل شيء: المشاكل والفروق الدقيقة المخفية في Kubernetes، وخيارات حل هذه الصعوبات والتنفيذ الحالي لـ werf بالتفصيل. انضم إلينا يومي 27 و28 مايو، وسوف نقوم بإنشاء الأدوات المثالية.
المصدر: www.habr.com