تحسبا ل
DevOpsConf ، أجرى فيتالي خاباروف مقابلة مع
ديمتري ستولياروف (
distol ) ، المدير الفني والمؤسس المشارك لـ Flant. سأل فيتالي ديميتري عما يفعله فلانت ، حول Kubernetes ، تطوير النظام البيئي ، الدعم. ناقشنا لماذا هناك حاجة Kubernetes وما إذا كانت هناك حاجة على الإطلاق. وأيضًا حول الخدمات المصغرة ، Amazon AWS ، نهج "أنا محظوظ" في DevOps ، مستقبل Kubernetes نفسه ، ولماذا ومتى وكيف سيتولى العالم ، آفاق DevOps وما يجب على المهندسين الاستعداد له في المستقبل المشرق القريب مع التبسيط والشبكات العصبية.
استمع إلى
المقابلة الأصلية على هيئة بودكاست على DevOps Deflop ، وهو بودكاست باللغة الروسية حول DevOps ، وفيما يلي إصدار نصي.
فيما يلي الأسئلة التي طرحها المهندس فيتالي خاباروف على أسئلة من Express42.
حول فلانت
- ديما ، مرحبا. أنت المدير التقني لشركة Flant وأيضًا مؤسسها. أخبرني ، من فضلك ، ماذا تفعل الشركة وهل أنت فيه؟
ديمتري : من الخارج ، يبدو أننا الرجال الذين نذهب ونضع Kubernetes على الجميع ونفعل شيئًا ما معه. لكن هذا ليس كذلك. لقد بدأنا كشركة تتعامل مع Linux ، ولكن لفترة طويلة جدًا كان نشاطنا الرئيسي هو خدمة الإنتاج ومشاريع تسليم المفتاح الكبيرة. عادة ما نقوم ببناء البنية التحتية بأكملها من نقطة الصفر وبعد ذلك نحن مسؤولون عن ذلك لفترة طويلة. لذلك ، يتمثل العمل الرئيسي الذي يؤديه Flant ، والذي يتلقى المال من أجله ، في
تحمل المسؤولية وتنفيذ الإنتاج بنظام تسليم المفتاح .
بصفتي مديرًا فنيًا وواحدًا من مؤسسي الشركة ، أعمل على مدار الساعة للتفكير في طرق لزيادة توفر الإنتاج ، وتبسيط عملياته ، وجعل الحياة أسهل للمسؤولين ، وجعل الحياة أكثر متعة للمطورين.
حول Kubernetes
- آخر مرة من "Flanta" أرى الكثير من التقارير والمقالات حول Kubernetes. كيف أتيت إليه؟ديمتري : لقد تحدثت بالفعل عن هذا الأمر عدة مرات ، لكنني لست آسف على الإطلاق لتكرار ذلك. أعتقد أنه من الصحيح تكرار هذا الموضوع ، لأنه يوجد خلط بين السبب والنتيجة.
نحن حقا بحاجة إلى أداة. واجهنا الكثير من المشاكل ، ناضلنا ، وتغلبنا عليها بعكازات مختلفة وشعرنا بالحاجة إلى أداة. من خلال العديد من الخيارات المختلفة ، بنيت دراجاتهم ، اكتسبت الخبرة. تدريجيا وصلنا إلى النقطة التي بدأنا باستخدام Docker تقريبا بمجرد ظهوره - حوالي عام 2013. في وقت ظهوره ، كان لدينا بالفعل الكثير من الخبرة في مجال الحاويات ، لقد كتبنا بالفعل نظيرًا لـ "Docker" - بعض عكازاتنا في بيثون. مع ظهور Docker ، يمكن التخلص من العكازات واستخدامها بواسطة حل موثوق ومدعوم من المجتمع.
مع Kubernetes ، القصة متشابهة. بحلول الوقت الذي بدأ يكتسب فيه الزخم - بالنسبة لنا هذا هو الإصدار 1.2 - كان لدينا بالفعل مجموعة من العكازات على كل من Shell and Chef ، والتي حاولنا بطريقة ما تنظيم Docker بها. نظرنا بجدية نحو Rancher والحلول الأخرى المختلفة ، ولكن بعد ذلك ظهرت Kubernetes ، حيث يتم تنفيذ كل شيء تمامًا كما نفعل أو أفضل. لا يوجد شيء للشكوى.
نعم ، هناك نوع من العيوب ، وهناك نوع من العيوب - هناك الكثير من العيوب ، و 1.2 أمر فظيع بشكل عام ، لكن .... Kubernetes يشبه المبنى قيد الإنشاء - تنظر إلى المشروع وتفهم أنه سيكون رائعًا. إذا كان للمبنى الآن أساس وطابقان ، فأنت تدرك أنه من الأفضل عدم نشره بعد ، ولكن لا توجد مشكلات من هذا القبيل في البرنامج - يمكنك استخدامه بالفعل.
لم يكن لدينا اللحظة التي اعتقدنا فيها استخدام Kubernetes أم لا. كنا ننتظره قبل وقت طويل من ظهوره ، وحاولنا صنع نظائرنا بأنفسنا.
بالقرب من Kubernetes
- هل تشارك مباشرة في تطوير Kubernetes نفسها؟ديمتري : المتوسط. نحن أكثر عرضة للمشاركة في تطوير النظام البيئي. نرسل كمية معينة من طلبات السحب: إلى Prometheus ، لجميع أنواع المشغلين ، إلى Helm إلى النظام البيئي. لسوء الحظ ، أنا غير قادر على متابعة كل ما نقوم به ويمكن أن أكون مخطئًا ، لكن لا يوجد مجموعة واحدة من جوهرنا.
- هل تقوم بتطوير الكثير من الأدوات الخاصة بك حول Kubernetes؟ديمتري : الإستراتيجية هي: نذهب ونجذب إلى كل شيء موجود بالفعل. إذا لم يتم قبول طلبات السحب هناك ، فنحن ببساطة نتفهمها ونعيش حتى يتم قبولها باستخدام تصميماتنا. ثم ، عندما يصل إلى المنبع ، نعود إلى إصدار المنبع.
على سبيل المثال ، لدينا مشغل بروميثيوس الذي تحولنا جيئة وذهابا إلى المنبع لتجميعنا 5 مرات بالفعل ، على الأرجح. نحتاج إلى بعض الميزات ، وأرسلنا طلب سحب ، ونحتاج إلى طرحه غدًا ، ولا نريد الانتظار حتى يتم إصداره في اتجاه المنبع. وفقًا لذلك ، نجمعها بأنفسنا ، ونجمع تجميعنا بميزتنا ، التي نحتاجها لسبب ما ، إلى جميع مجموعاتنا. بعد ذلك ، على سبيل المثال ، يلفوننا بعبارات: "الرجال ، دعونا نفعل ذلك لحالة أكثر عمومية" ، سننتهي ، نحن أو أي شخص آخر ، ونندمج مرة أخرى في النهاية.
كل ما هو موجود ، نحن نحاول تطوير . العديد من العناصر التي لم يتم إنشاؤها بعد لم يتم اختراعها أو تم اختراعها ، ولكن لم يتم تنفيذها بعد - نحن نقوم بذلك. ليس لأننا نحب العملية نفسها أو بناء الدراجات كصناعة ، ولكن ببساطة لأننا نحتاج إلى هذه الأداة. غالبًا ما يطرحون السؤال ، لماذا فعلنا هذا أو ذاك؟ الجواب بسيط - لأننا اضطررنا إلى المضي قدمًا في حل بعض المشكلات العملية وحلها بهذه الأداة.
دائمًا ما يكون هذا هو: نحن ننظر بعناية فائقة ، وإذا لم نجد أي حل ، وكيفية صنع حافلة ترولي من رغيف الخبز ، فإننا نصنع رغيفنا وحافلة ترولي الخاصة بنا.
أدوات فلانت
"أعرف أن لدى Flant الآن مشغلي الملحق ، ومشغلي shell ، وأدوات dapp / werf. كما أفهمها ، هذه هي الأداة نفسها في تجسيد مختلف. أفهم أيضًا أن هناك العديد من الأدوات المختلفة داخل Flant. هل هذا صحيح؟ديمتري : لا يزال لدينا الكثير من الأشياء على جيثب. من ما أتذكره الآن ، لدينا خريطة حالة - لوحة لـ Grafana وصلت إلى الجميع. تم ذكره في كل مقالة ثانية تقريبًا حول مراقبة Kubernetes على المتوسط. من المستحيل أن تصف باختصار ما هي خريطة الحالة - أنت بحاجة إلى مقالة منفصلة ، لكن هذا شيء مفيد جدًا لمراقبة الحالة بمرور الوقت ، لأننا في Kubernetes نحتاج غالبًا إلى إظهار الحالة بمرور الوقت. لدينا أيضًا LogHouse - هذه قطعة ClickHouse وقائمة على السحر الأسود لجمع السجلات في Kubernetes.
العديد من المرافق! وسيكون هناك المزيد ، لأنه سيتم إصدار عدد من الحلول الداخلية هذا العام. من بين المشغلين الكبار للغاية المستندة إلى الإضافات ، هناك مجموعة من الإضافات إلى Kubernetes ، ولكن كيفية تثبيت مدير sert بشكل صحيح - أداة لإدارة الشهادات ، وكيفية تثبيت Prometheus مع مجموعة من المراوغات بشكل صحيح - هذه عشرون ثنائيات مختلفة تقوم بتصدير البيانات وجمع شيء ما ، لهذا بروميثيوس هو الرسومات والتنبيهات رهيبة. كل هذا هو مجرد مجموعة من الإضافات إلى Kubernetes التي يتم وضعها في كتلة ، وتتحول من بسيطة إلى باردة ومتطورة وتلقائية ، والتي تم بالفعل حل العديد من القضايا. نعم ، نحن نفعل الكثير.
تطوير النظم الايكولوجية
- يبدو لي أن هذه مساهمة كبيرة جدًا في تطوير هذه الأداة وطرق استخدامها. هل يمكنك تقريبًا معرفة من الذي سيقدم نفس المساهمة في تطوير النظام البيئي؟ديمتري :
في روسيا ، لا يوجد أي من الشركات التي تعمل في سوقنا قريبة . بالطبع ، هذا بيان رفيع المستوى ، لأن هناك لاعبين كبرياء مثل Mail with Yandex - إنهم يفعلون شيئًا أيضًا مع Kubernetes ، لكن حتى أنهم لم يقابلوا مساهمة الشركات في العالم ، التي تقوم بأكثر مما نفعل. من الصعب مقارنة Flant مع موظفين من 80 شخصًا و Red Hat ، حيث يوجد 300 مهندس Kubernetes فقط ، إذا لم أكن مخطئًا. من الصعب المقارنة. لدينا 6 أشخاص في قسم RnD ، بمن فيهم أنا ، الذين يشاهدون جميع أدواتنا. 6 أشخاص مقابل 300 مهندس ريد هات - من الصعب المقارنة.
- على الرغم من ذلك ، حتى عندما يتمكن هؤلاء الأشخاص الستة من فعل شيء مفيد حقًا وغربة ، عندما يواجهون مهمة عملية ويتخذون قرارًا للمجتمع - هناك حالة مثيرة للاهتمام. أفهم أنه في شركات التكنولوجيا الكبيرة ، حيث يوجد لديها فريق دعم خاص بها لتطوير Kubernetes ، من حيث المبدأ ، يمكن تطوير الأدوات نفسها. هذا مثال لهؤلاء الذين يمكن تطويرهم وإعطاءهم للمجتمع ، لإعطاء زخم للمجتمع بأكمله الذي يستخدم Kubernetes.ديمتري : ربما تكون هذه رقاقة متكاملة ، ميزتها. لدينا العديد من المشاريع ونرى العديد من المواقف المختلفة. بالنسبة لنا ، تتمثل الطريقة الرئيسية لإنشاء قيمة مضافة في تحليل هذه الحالات والعثور على الحالات الشائعة وجعلها رخيصة قدر الإمكان بالنسبة لنا. نحن نفعل هذا بنشاط. من الصعب بالنسبة لي التحدث عن روسيا والعالم ، ولكن لدينا حوالي 40 مهندسا من DevOps في Kubernetes. لا أعتقد أنه يوجد في روسيا العديد من الشركات التي لديها عدد مماثل من المتخصصين الذين يفهمون Kubernetes ، إن وجدت.
أفهم كل شيء عن مهندس DevOps المسمى الوظيفي ، والجميع يفهم كل شيء معتادًا على استدعاء مهندسي DevOps المهندسين DevOps ، ولن نناقش ذلك. يواجه كل مهندسي DevOps الأربعين هؤلاء مشاكل كل يوم ونحلها ، نحلل هذه التجربة ونحاول تلخيصها. نحن نتفهم أنه إذا بقيت معنا ، فعندئذ في غضون عام أو عامين ستكون الأداة عديمة الفائدة ، لأنه في مكان ما في المجتمع ستظهر أداة جاهزة. لا معنى لتجميع هذه التجربة في الداخل - إنها مجرد استنزاف للوقت والطاقة في تطوير / إلغاء. وبالتالي نحن لسنا آسفين على الإطلاق. إنه لمن دواعي سرورنا أن ننشر كل شيء ونفهم أننا بحاجة إلى نشره وتطويره وترقيته والترويج له ، حتى يتمكن الناس من استخدام وإضافة تجاربهم الخاصة - ثم ينمو كل شيء وحياته. ثم ، بعد عامين ، لا تذهب الأداة إلى سلة المهملات. ليس من المؤسف الاستمرار في صب الطاقة ، لأنه من الواضح أن شخصًا ما يستخدم أداتك ، وبعد عامين يستخدمها الجميع.
هذا جزء من استراتيجيتنا الكبيرة مع dapp / werf . لا أتذكر متى بدأنا القيام بذلك ، على ما يبدو ، منذ حوالي 3 سنوات. في البداية ، كان عموما على قذيفة. لقد كان برهانًا رائعًا على المفهوم ، فقد حللنا بعض مهامنا الخاصة - اتضح! ولكن هناك مشكلات في shell ، من المستحيل زيادة بنائها ، والبرمجة على shell شيء آخر. كانت لدينا عادة من الكتابة في روبي ، على التوالي ، في روبي قمنا بإعادة تصميم شيء ما ، وتطويره وتطويره وتطويره ، واعتمدنا على حقيقة أن المجتمع ، وهو حشد لا يقول "نريد أو لا نريد" ، يظهر أنف روبي ، هذا ليس مضحكا. لقد أدركنا أنه يتعين علينا كتابة كل هذه الأشياء في Go ، لمجرد مطابقة الفقرة الأولى في قائمة التحقق:
يجب أن تكون أداة DevOps-bite ثنائية ثابتة . على الذهاب أو لا تذهب ليست مهمة جدا ، ولكن ثنائي ثابت مكتوب في الذهاب هو أفضل.
جهد مستنفد ، أعد كتابة dapp على Go وأطلق عليها اسم werf. Dapp لم يعد مدعومًا ، لا يتطور ، يعمل في بعض الإصدارات الأحدث ، ولكن يوجد مسار ترقية مطلق إلى الأعلى ، ويمكنك متابعته.
لماذا تم إنشاء dapp؟
- هل يمكن أن تخبرنا لفترة وجيزة لماذا تم إنشاء dapp ، ما هي المشاكل التي يحلها؟ديمتري : السبب الأول في التجمع. في البداية ، واجهنا مشكلات بناء قوية عندما لم يكن Docker يعرف كيفية المراحل المتعددة ، وقمنا بمراحل متعددة من تلقاء أنفسنا. ثم كان لدينا مجموعة من الأسئلة مع صورة التنظيف. يواجه كل من يقوم بإعداد CI / CD ، عاجلاً وليس آجلاً ، مشكلة وجود مجموعة من الصور التي تم جمعها ، تحتاج إلى تنظيف ما هو غير ضروري وترك ما هو مطلوب.
السبب الثاني في النشر. نعم ، هناك هيلم ، لكنه لا يحل سوى جزء من المشاكل. ومن المفارقات ، هو مكتوب أن "هيلم - مدير الحزم ل Kubernetes". وهي أن "ال". هناك أيضًا الكلمات "مدير الحزم" - ما هو التوقع المعتاد من مدير الحزم؟ نقول: "مدير الحزم - تسليم الحزمة!" ونتوقع منه أن يقول لنا: "تم تسليم الطرد".
من المثير للاهتمام أن نقول: "Helm ، ضع الحزمة" ، وعندما يجيب أنه قام بتثبيتها ، اتضح أنه بدأ التثبيت - أشار Kubernetes: "تشغيل هذا الشيء!" ، لكنه بدأ أم لا ، إنه يعمل أم لا حلم لا يحل هذه المشكلة على الإطلاق.
اتضح أن Helm هو مجرد معالج نص مسبق يقوم بتحميل البيانات إلى Kubernetes.
لكننا نريد أن نعرف في إطار أي نشر - التطبيق قد خرج إلى همز أم لا؟ إن طرح المنتج على المنتج يعني أن التطبيق قد ذهب إلى هناك ، وقد تم نشر نسخة جديدة ، وأنه على الأقل لم يتعطل ويستجيب بشكل صحيح. حلم لا يحل هذه المشكلة. لحلها ، تحتاج إلى إنفاق الكثير من الطاقة ، لأنك تحتاج إلى إعطاء Kubernetes الأمر لتوزيع ومراقبة ما يحدث هناك - ما إذا كان قد تم الدوران حوله ، سواء تم تشغيله. وهناك أيضًا مجموعة من المهام المتعلقة بالنشر والتنظيف والتجميع.
خطط
هذا العام سوف نذهب إلى التنمية المحلية. نريد أن نتوصل إلى ما كان موجودًا في Vagrant - لقد كتبنا كلمة "vagrant up" ونشرنا أجهزة افتراضية. نريد أن نتوصل إلى مثل هذه الحالة التي يوجد فيها مشروع في Git ، نكتب "werf up" هناك ، ويثير نسخة محلية من هذا المشروع ، تم نشرها في mini-kub محلي ، مع كل الدلائل المناسبة للتطوير. اعتمادًا على لغة التطوير ، يتم ذلك بطرق مختلفة ، ولكن ، مع ذلك ، من المناسب إجراء تطوير محلي تحت الملفات المحمّلة.
الخطوة التالية بالنسبة لنا هي
الاستثمار بكثافة في راحة المطورين . من أجل نشر مشروع محليًا بسرعة ، باستخدام أداة واحدة ، لإكماله ، اضغط على Git ، وسيتم طرحه أيضًا على خشبة المسرح أو الاختبارات ، اعتمادًا على خطوط الأنابيب ، ثم انتقل إلى المنتج باستخدام الأداة نفسها. هذه الوحدة والتوحيد واستنساخ البنية التحتية من البيئة المحلية إلى البيع هي لحظة مهمة للغاية بالنسبة لنا. لكن هذا لم يحن بعد - مجرد التخطيط للقيام بذلك.
لكن الطريق إلى dapp / werf كان دائمًا كما كان مع Kubernetes في البداية. واجهنا مشاكل ، وحلها عن طريق الحلول - توصلنا إلى نوع من الحلول لأنفسنا على قذيفة ، على أي شيء. ثم حاولت هذه الحلول ، بطريقة ما ، التعميم والتوحيد في الثنائيات في هذه الحالة ، التي نشاركها ببساطة.
هناك وجهة نظر أخرى لهذه القصة كاملة ، مع القياس.
Kubernetes هو إطار سيارة مع محرك. لا توجد أبواب ونوافذ وراديو وأشجار عيد الميلاد - لا شيء على الإطلاق. فقط الإطار والمحرك. وهناك هيلم - هذه هي عجلة القيادة. رائع - هناك عجلة قيادة ، ولكن لا تزال بحاجة إلى دبوس توجيه ، ورف مقود ، وعلبة تروس وعجلات ، ولكن بدونها لا شيء.
في حالة werf ، هذا مكون آخر لـ Kubernetes. الآن فقط في إصدار ألفا الخاص بنا من werf ، على سبيل المثال ، يجمع Helm إلى werf تمامًا ، لأننا تعبنا من القيام بذلك بأنفسنا. هناك العديد من الأسباب للقيام بذلك ، وبالتفصيل حول سبب قيامنا بتجميع الدفة برمتها مع tiller داخل werf ، سأقول فقط
في التقرير على RIT ++ .
الآن werf هو مكون أكثر تكاملا. نحصل على عجلة قيادة جاهزة ، ودبوس توجيه - لست جيدًا جدًا في السيارات ، لكن هذه كتلة كبيرة تحل بالفعل مجموعة واسعة من المهام. لا نحتاج إلى تسلق الكتالوج بأنفسنا ، والتقاط جزءًا إلى آخر ، والتفكير في كيفية ربطها ببعضها البعض. نحصل على مزيج جاهز يحل على الفور مجموعة كبيرة من المهام. لكن داخلها يتكون من جميع مكونات المصدر المفتوح نفسه ، كما أنه يستخدم Docker للتجميع ، Helm لجزء من الوظيفة ، وهناك العديد من المكتبات الأخرى. هذه أداة مدمجة لإخراج CI / CD من الجهاز بسرعة وسهولة.
هل من الصعب الحفاظ على Kubernetes؟
- تتحدث عن التجربة التي بدأت في استخدام Kubernetes ، وهذا إطار ومحرك لك ، ويمكنك تعليق الكثير من الأشياء المختلفة عليه: الجسم ، عجلة القيادة ، ربط الدواسات والمقاعد. والسؤال هو - ما مدى صعوبة دعم Kubernetes لك؟ لديك تجربة غنية ، ما مقدار الوقت والموارد التي تحتاجها لدعم Kubernetes بشكل منفصل عن أي شيء آخر؟ديميتري : هذا سؤال صعب للغاية وللاجابة ، تحتاج إلى فهم ما هو الدعم وماذا نريد من Kubernetes. ربما سوف تكشف؟
- بقدر ما أعرف وكما أراه ، تريد الآن العديد من الفرق تجربة Kubernetes. تسخير الجميع له ، وضعت على ركبته. لدي شعور بأن الناس لا يفهمون دائمًا تعقيد هذا النظام.ديمتري : هذا كل شيء.
- ما مدى صعوبة أخذ وتوصيل Kubernetes دون أي شيء لجعل الإنتاج جاهزًا؟ديمتري : هل تعتقد أنه من الصعب زرع قلب؟ أنا أفهم ، والسؤال هو المساومة. الحمل بمشرط ولا يرتكب خطأ ليس بالأمر الصعب. إذا تم إخبارك بمكان قصه وأين يتم الخياطة ، فإن الإجراء نفسه بسيط. من الصعب أن نضمن من وقت لآخر أن كل شيء سينجح.
ضع Kubernetes واجعلها بسيطة: فرخ! - تسليمها ، هناك مجموعة من طرق التثبيت. ولكن ماذا يحدث عندما تنشأ المشاكل؟
تثار الأسئلة دائمًا - ما الذي لم نأخذه في الاعتبار بعد؟ ما لم نفعل بعد؟ ما معلمات نواة لينكس التي حددتها بشكل غير صحيح؟ يا رب ، هل أشرنا لهم؟ ما هي مكونات Kubernetes التي قدمناها والتي ليست كذلك؟ تنشأ الآلاف من الأسئلة ، وللإجابة عليها ، تحتاج إلى طهي الطعام لمدة 15-20 سنة في هذه الصناعة.
لدي مثال جديد على هذا الموضوع قد يكشف عن معنى مشكلة "هل من الصعب الحفاظ على Kubernetes؟" منذ بعض الوقت ، درسنا بجدية ما إذا كان ينبغي لنا محاولة تنفيذ Cilium كشبكة في Kubernetes.
اسمحوا لي أن أشرح ما هو Cilium. لدى Kubernetes العديد من التطبيقات المختلفة للنظام الفرعي للشبكة ، أحدها رائع للغاية - إنه Cilium. ما هو معناها؟ في النواة منذ بعض الوقت ، أصبح من الممكن كتابة السنانير للنواة التي تغزو بطريقة ما النظام الفرعي للشبكة والأنظمة الفرعية الأخرى المختلفة وتسمح لك بتجاوز الأجزاء الكبيرة في النواة.
يحتوي Linux kernel تاريخياً على توجيه ip ، عامل تصفية فائق ، جسور ، والعديد من المكونات القديمة المختلفة التي تتراوح أعمارها بين 15 و 20 و 30 عامًا. بشكل عام ، إنهم يعملون ، كل شيء رائع ، لكنهم صنعوا الآن حاوية من الحاويات ، ويبدو كالبرج الذي يتكون من 15 قطعة فوق بعضها ، وأنت تقف على ساق واحدة - إحساس غريب. وقد تطور هذا النظام تاريخيا مع العديد من الفروق الدقيقة ، مثل التذييل في الجسم. في بعض الحالات ، هناك مشاكل في الأداء ، على سبيل المثال.
هناك BPF رائعة وقدرة على كتابة الخطافات للنواة - كتب الرجال الخطافات الخاصة بهم للنواة. تأتي الحزمة إلى kernel Linux ، حيث يتم إخراجها مباشرة عند الإدخال ، ومعالجتها بأنفسهم دون جسور ، ودون TCP ، وبدون مكدس IP - باختصار ، متجاوزة كل شيء مكتوب في kernel Linux ، وبصقه على الفور في الحاوية.
ماذا حدث؟ أداء رائع للغاية ، ميزات رائعة - رائع! لكننا ننظر إلى هذا ونرى أنه يوجد في كل جهاز برنامج يتصل بـ Kubernetes API ، ووفقًا للبيانات الواردة من API ، يقوم بإنشاء رمز C ويجمع الثنائيات التي يتم تحميلها في kernel حتى تعمل هذه السنانير في مساحة kernel .
ماذا يحدث إذا حدث خطأ ما؟ نحن لا نعرف. لفهم هذا ، تحتاج إلى قراءة كل هذا الرمز ، وفهم كل المنطق ، وهذا مذهل ، كم هو صعب. ولكن ، من ناحية أخرى ، هناك هذه الجسور ، والمرشحات الصافية ، وملكية الفكرية - لم أكن أقرأ مصادرهم ، و 40 مهندسًا يعملون في شركتنا أيضًا. ربما بعض القطع تفهم الوحدات.
وما الفرق؟ اتضح أن هناك توجيه بروتوكول الإنترنت ، ونواة لينكس ، وهناك أداة جديدة - ما هو الفرق ، نحن لا نفهم أحدًا أو الآخر. لكننا خائفون من استخدام الجديد - لماذا؟ لأنه إذا كان عمر الأداة 30 عامًا ، فقد تم العثور على جميع الخلل على مدار 30 عامًا ، وقد حان كل الخرف ولا تحتاج إلى معرفة كل شيء - إنها تعمل مثل الصندوق الأسود ، وتعمل دائمًا. يعلم الجميع أي مفك تشخيصي يتمسك به في أي مكان ، والذي tcpdump عند نقطة البدء. يعلم الجميع الأدوات المساعدة للتشخيص جيدًا ويفهم كيف تعمل هذه المجموعة من المكونات في نواة Linux - وليس كيفية عملها ، ولكن كيفية استخدامها.
وبهدوء بارد Cilium ليس 30 سنة ، فإنه لم ينضج بعد. مع Kubernetes نفس المشكلة ، نسخ. تم إعداد Cilium بشكل مثالي ، وأن Kubernetes تم ضبطه بشكل مثالي ، ولكن عندما يحدث خطأ ما في المنتج ، هل يمكنك فهم ما حدث بسرعة في موقف حرج؟
عندما نقول أنه من الصعب الحفاظ على Kubernetes ، لا ، إنه بسيط للغاية ، ونعم ، إنه أمر صعب للغاية. Kubernetes , .
« »
— , ? , Kubernetes, - .: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.
Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.
, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .
. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?
, , , . , .
, , , , . .
IT, , « ». , , . , . .
— : , , «», , Red Hat, , Kubernetes, .: . Kubernetes — .
?
— , Kubernetes ?: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .
— ? «» , Kubernetes — -.
, Kubernetes .
game-changer . — , Ansible, Chef, , Terraform. .
Kubernetes — changer , .
, - , - , . , , Kubernetes : ,
infrastructure as code , , yml — . , .
— , Kubernetes, . ?: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .
, CI/CD — , Continuous Delivery, , , , — Kubernetes.
— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?: .
«: ». , . , . , , . «». , , - , — , , . هذا ليس كذلك.
, , 300 , , , , , - — 10, 30 . , . , 3 60 , .
, — . , . , , .
, , , , Kubernetes , , , , , , Kubernetes, . —
, , , . . — , , — .
— , Kubernetes , , , . . — , , , 10 — , . . , .
Kubernetes . : Kubernetes, , 4-5 , — . , . ما هذا Ubuntu Curios? Linux, . , . Kubernetes , , , , .
, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.
, 10 , . .
Amazon Google
— Amazon Google?: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .
, , . 40 , , , 60 — . - , , .
, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .
, — , , , hosted- .
Kubernetes?
— - Kubernetes? Kubernetes, «», Kubernetes?: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .
, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !
, : «, ». , . , . CI/CD, . , .
, Kubernetes — Kubernetes .
, Kubernetes. , , , . , . Kubernetes — , , « », « », - .
. : , , — . . , , , , . , .
, - Kubernetes — .
Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .
. : «, !» — , : « , ». . , , - , , .
: Kubernetes. .
, :
: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .
حول serverless
- إذا نظرت إلى أبعد من ذلك قليلاً في المستقبل ، ثم حاولت حل مشكلة نقص الصداع مع البنية التحتية ، مع سرعة البدء وسرعة تغيير التطبيق ، تظهر حلول جديدة ، على سبيل المثال ، بدون خادم. هل تشعر بأي احتمال في هذا الاتجاه ، ودعونا نقول ذلك ، يشكل خطرا على Kubernetes والحلول المماثلة؟ديميتري : هنا نحتاج إلى الإدلاء بتصريح مرة أخرى ، أنني لست من أصحاب الرؤية التي تتطلع إلى الأمام وتقول - سيكون الأمر كذلك! على الرغم من أنني فعلت الشيء نفسه. أنظر إلى قدمي وأرى مجموعة من المشاكل هناك ، على سبيل المثال ، كيف تعمل الترانزستورات في جهاز الكمبيوتر. مضحك ، هاه؟ نواجه بعض الأخطاء في وحدة المعالجة المركزية.
جعل serverless موثوقة بما فيه الكفاية ، ورخيصة وفعالة ومريحة ، وحل جميع مشاكل النظام البيئي. ثم أتفق مع قناع Elon على أننا نحتاج إلى كوكب ثانٍ لنحمل الأخطاء من أجل الإنسانية. على الرغم من أنني لا أعرف ما يقوله ، إلا أنني أفهم أنني لست مستعدًا للسفر إلى المريخ بنفسي ولن يكون غدًا.
مع عدم وجود خادم ، من الواضح أن هذا هو الشيء الصحيح أيديولوجيًا ، كتسامح مع الخطأ للبشرية - كواكب أفضل من واحد. ولكن كيف نفعل ذلك الآن؟ لإرسال بعثة واحدة ليست مشكلة إذا ركزنا على هذا الجهد. إن إرسال عدة بعثات وتعبئة آلاف الأشخاص هناك ، كما أعتقد ، أمر واقعي أيضًا. ولكن من أجل جعل التسامح مع الخطأ هو أن نصف البشر يعيشون هناك ، يبدو لي الآن مستحيلًا ، ولا يتم النظر فيه.
مع خادم واحد إلى واحد: الشيء رائع ، لكنه بعيد عن مشاكل 2019. أقرب إلى 2030 - دعونا نعيش لرؤيتها. ليس لدي أدنى شك في أننا سنبقى على قيد الحياة ، وبالتأكيد سوف نعيش (نكرر قبل النوم) ، لكننا نحتاج الآن إلى حل المشكلات الأخرى. انها مثل الاعتقاد في قوس قزح المهر رائع. نعم ، تم حل اثنين بالمائة من الحالات ، وتم حلها بشكل مثالي ، ولكن بدون خادم ذاتي هو قوس قزح ... بالنسبة لي هذا الموضوع بعيد جدًا وغير مفهوم. أنا لست مستعدًا للتحدث. في عام 2019 ، بدون خادم ، لن تكتب طلبًا واحدًا.
كيف سيتطور Kubernetes
"بينما نتحرك نحو هذا المستقبل البعيد الجميل ، ما الذي تعتقد أنه سيطور Kubernetes والنظام البيئي المحيط به؟"ديمتري : لقد فكرت كثيرًا في هذا الأمر ولدي إجابة واضحة. الأول هو الدولة - لا يزال عديمي الجنسية أسهل في القيام به. Kubernetes استثمرت في البداية أكثر في ذلك ، كل شيء بدأ معها. يعمل عديمي الجنسية بشكل مثالي تقريبًا في Kubernetes ، لا يوجد شيء للشكوى منه. من قبل الدولة لا تزال هناك الكثير من المشاكل ، أو بالأحرى ، الفروق الدقيقة. كل شيء يعمل بشكل جيد بالفعل بالنسبة لنا هناك ، لكننا. لكي يعمل هذا من أجل الجميع ، تحتاج إلى عامين آخرين على الأقل. هذا ليس مؤشرا محسوبا ، ولكن شعوري من الرأس.
باختصار ، يحتاج التطوير - وسوف - سوف يتطور كثيرًا ، نظرًا لأن جميع طلباتنا لها حالة ، لا توجد تطبيقات عديمة الجنسية. هذا هو الوهم ، فأنت تحتاج دائمًا إلى نوع من قواعد البيانات وشيء آخر. Statefull هو تصحيح كل ما هو ممكن ، وتصحيح جميع الأخطاء ، وتحسين جميع المشاكل التي تواجه حاليا - دعنا نسميها اعتماد.
مستوى المجهول ، ومستوى المشاكل التي لم تحل ، ومستوى احتمال مواجهة شيء ما ، سوف ينخفض بشكل حاد. هذه قصة مهمة. والمشغلين - كل ما يتعلق بتدوين منطق الإدارة ، منطق التحكم ، للحصول على خدمة سهلة: خدمة MySQL سهلة ، خدمة RabbitMQ سهلة ، خدمة Memcache سهلة - بشكل عام ، كل هذه المكونات التي نحتاج إلى الحصول عليها مضمونة للعمل خارج الصندوق. هذا فقط يحل الألم الذي نريده لقاعدة بيانات ، لكن لا نريد إدارته ، أو نريد Kubernetes ، لكن لا نريد إدارته.
هذه القصة مع تطور المشغلين بشكل أو بآخر ستكون مهمة في العامين المقبلين.
أعتقد أن سهولة الاستخدام يجب أن تزيد بشكل كبير - سيصبح الصندوق أسود أكثر فأكثر ، وأكثر موثوقية ، مع مزيد من التحولات البسيطة.
لقد استمعت ذات مرة إلى مقابلة إسحاق أسيموف القديمة في الثمانينيات من القرن الماضي على موقع يوتيوب في ساترداي نايت لايف ، وهو برنامج شبيه بالإعجاب ومثير للاهتمام. سئل هناك عن مستقبل أجهزة الكمبيوتر. قال إن المستقبل بسيط ، كما كان الحال مع الراديو. كان الراديو في الأصل شيئًا معقدًا. للقبض على الموجة ، استغرق الأمر 15 دقيقة لتحريف الدوّارات وبرم الأسياخ ومعرفة كيفية عمل كل شيء بشكل عام لفهم فيزياء إرسال الموجة الراديوية. ونتيجة لذلك ، ظل تطور واحد في الراديو.
الآن في عام 2019 ، أي الراديو؟ في السيارة ، يجد الراديو كل الموجات ، اسم المحطات. فيزياء العملية لم تتغير منذ 100 عام ، لقد تغيرت سهولة الاستخدام. الآن ، وليس الآن فقط ، بالفعل في عام 1980 ، عندما أجريت مقابلة مع عظيموف ، استخدم الجميع الراديو ولم يفكر أحد في كيفية ترتيبه. كان يعمل دائما - هو معين.
ثم قال عظيموف إنه سيكون مماثلاً لأجهزة الكمبيوتر -
ستزداد سهولة الاستخدام . إذا كنت في عام 1980 تحتاج إلى الحصول على تعليم خاص للضغط على الأزرار الموجودة على جهاز الكمبيوتر ، فلن يكون ذلك في المستقبل.
لدي شعور بأنه مع Kubernetes والبنية التحتية ، ستزداد سهولة الاستخدام أيضًا بشكل كبير. هذا ، في رأيي ، واضح - إنه يقع على السطح.
ماذا تفعل مع المهندسين؟
- ثم ماذا سيحدث للمهندسين ومسؤولي النظام الذين يدعمون Kubernetes؟ديمتري : وماذا حدث للمحاسب بعد ظهور 1C؟ عن نفسه. قبل ذلك ، فكروا في ورقة - الآن في البرنامج. زادت إنتاجية العمل بأعداد ضخمة ، ولم يختف العمل نفسه من هذا. في السابق ، كان هناك 10 مهندسين يحتاجون إلى تثبيت اللمبة ، لكن الآن سيكون هناك واحد كافٍ.
يبدو أن عدد البرامج وعدد المهام ، ينمو بسرعة أكبر من DevOps الجديدة وتتزايد الكفاءة. هناك نقص محدد في السوق وسيستمر لفترة طويلة. في وقت لاحق ، سيذهب كل شيء إلى معيار معين ، حيث ستزداد كفاءة العمل ، وسيصبح بدون خادم ، وسيقوم بتوصيل الخلايا العصبية إلى Kubernetes ، التي ستختار كل الموارد كما ينبغي ، وبوجه عام ستقوم بكل شيء كما ينبغي - الشخص يفلت ولا يزعج.
لكن على أي حال ، سيتعين على شخص ما اتخاذ القرارات. من الواضح أن مستوى التأهيل والتخصص لهذا الشخص أعلى. الآن في قسم المحاسبة ، لا تحتاج إلى 10 موظفين يحتفظون بدفاتر حتى لا تتعب أيديهم. انها ليست فقط ضرورية. يتم فحص العديد من المستندات تلقائيًا والتعرف عليها بواسطة نظام إدارة المستندات الإلكتروني. أحد كبار المحاسبين الأذكياء يكفي ، بالفعل مع مهارات أكبر بكثير ، مع فهم جيد.
بشكل عام ، مثل هذا المسار في جميع القطاعات. هو نفسه مع السيارات: في وقت سابق ، تم ربط ميكانيكي السيارة وثلاثة سائقين في السيارة. الآن قيادة السيارة هي أبسط عملية نشارك فيها جميعًا كل يوم. لا أحد يعتقد أن السيارة شيء معقد.
لن تذهب DevOps أو هندسة النظم إلى أي مكان - ستزداد الكفاءة التشغيلية عالية المستوى.
- سمعت أيضًا فكرة مثيرة للاهتمام مفادها أن العمل سيزداد في الواقع.ديمتري : بالطبع ، مئة بالمائة! لأن كمية البرامج التي نكتبها تنمو باستمرار. يتزايد عدد المشكلات التي نحلها مع البرامج باستمرار. حجم العمل ينمو. الآن سوق DevOps محموم بشكل رهيب. وهذا واضح من توقعات الرواتب. بطريقة جيدة ، دون الخوض في التفاصيل ، يجب أن يكون هناك صغار يريدون X ، و middles الذين يريدون 1.5X ، وكبار السن الذين يريدون 2X. والآن ، إذا نظرت إلى سوق رواتب Moscow DevOps ، يريد الصغار من X إلى 3X والرغبات الكبيرة من X إلى 3X.
لا أحد يعرف كم يكلف. يتم قياس مستوى راتبك من خلال ثقتك - منزل مجنون ، لتكون صادقة ، سوق محموم بشكل رهيب.
بالطبع ، سيتغير هذا الموقف قريبًا جدًا - يجب أن يأتي بعض التشبع. مع تطوير البرمجيات ، ليس هذا هو الحال - على الرغم من حقيقة أن كل شخص يحتاج إلى مطورين وأن الجميع بحاجة إلى مطورين جيدين ، فإن السوق يدرك كم يكلف - لقد استقرت الصناعة. هذا ليس هو الحال مع DevOps.
- من ما سمعت ، خلصت إلى أن مسؤول النظام الحالي لا ينبغي أن يكون قلقًا للغاية ، ولكن حان الوقت لتنزيل المهارات والتحضير لحقيقة أنه سيكون هناك المزيد من العمل غدًا ، لكنه سيكون مؤهلاً بدرجة عالية.ديمتري : بالتأكيد. بشكل عام ، نحن نعيش في عام 2019 وسيادة الحياة هي:
التعلم مدى الحياة - نتعلم كل حياتنا . يبدو لي الآن أن الجميع يعرفون ذلك ويشعرون به ، لكن معرفة القليل أمر ضروري. كل يوم علينا أن نغير. إذا لم نفعل ذلك ، فسوف يتم إنزالنا عاجلاً أم آجلاً على هامش المهنة.
استعد لدوران حاد قدره 180 درجة. أنا لا أستبعد موقفًا عندما يتغير شيء ما بشكل كبير ، بل يأتي بشيء جديد - يحدث ذلك. قفز! - والآن نحن نتصرف بشكل مختلف. من المهم أن تكون مستعدا لهذا وليس للبخار. قد يحدث أن كل ما أفعله غدًا لن يكون ضروريًا - لا شيء ، لقد درست طوال حياتي وأنا على استعداد لتعلم شيء آخر. هذه ليست مشكلة. لا ينبغي أن تخاف من الأمن الوظيفي ، ولكن عليك أن تكون مستعدًا لتعلم شيء جديد باستمرار.
التمنيات ودقيقة الإعلان
- هل لديك أي رغبة؟ديمتري : نعم ، لدي بعض الأمنيات.
الأول والتجاري - الاشتراك في
يوتيوب . أعزائي القراء ، انتقل إلى YouTube واشترك في قناتنا. في غضون شهر تقريبًا ، سنبدأ توسعًا نشطًا في خدمة الفيديو ، وسيكون لدينا مجموعة من المحتوى التعليمي حول Kubernetes ، مفتوحة ومختلفة: من الأشياء العملية ، وحتى المختبرات ، إلى الأشياء النظرية الأساسية العميقة وكيفية تطبيق Kubernetes على مستوى المبادئ والأنماط.
الرغبة الثانية التجارية - انتقل إلى
جيثب ووضع النجوم ، لأننا نأكلها. إذا لم تعطنا النجوم ، فلن يكون لدينا شيء نأكله. انها مثل مانا في لعبة الكمبيوتر. نحن نفعل شيئًا ما ، ونفعل ، ونحاول ، يقول شخص ما إن هذه دراجات فظيعة ، شخص ما كل شيء خاطئ عمومًا ، ونحن نواصل ونتصرف بأمانة تامة. نرى المشكلة وحلها وتبادل تجربتنا. لذلك ، أعطنا علامة النجمة ، فلن تنقص منك ، ولكنها ستأتي إلينا ، لأننا نأكلها.
الرغبة الثالثة ، المهمة ، ولم تعد تجارية -
توقف عن الاعتقاد في القصص الخيالية . أنت محترف DevOps هي مهنة خطيرة ومسؤولة للغاية. توقف عن اللعب في مكان العمل. تتيح لك النقر وسوف تفهم ذلك. تخيل أنك ستأتي إلى المستشفى ، وهناك سيختبرك الطبيب. أدرك أن هذا يمكن أن يكون مسيئًا لشخص ما ، ولكن على الأرجح هذا ليس عنك ، ولكن عن شخص آخر. أخبر الآخرين بالتوقف أيضًا. إنها حقا تفسد الحياة لنا جميعًا - يبدأ الكثيرون في الاستغلال ، إلى مدراء و DevOps ، مثل الرجال الذين كسروا شيئًا ما مرة أخرى. كان هذا "مكسورًا" في أغلب الأحيان بسبب حقيقة أننا ذهبنا للعب ، ولم ننظر بوعي بارد إلى أن الأمر كان هكذا ، ولكن بهذه الطريقة.
هذا لا يعني أنك لست بحاجة إلى التجربة. نحن بحاجة إلى التجربة ، ونحن نفعل ذلك بأنفسنا. لنكون صادقين ، نحن أنفسنا نلعب أحيانًا أيضًا - هذا ، بالطبع ، سيء جدًا ، لكن لا يوجد شيء بشري غريب علينا. دعنا نعلن عام 2019 سنة التجارب الجادة ، وليس الألعاب على همز. ربما هكذا.
- شكرا جزيلا لك!دميتري : شكرًا ، فيتالي ، على الوقت وعلى المقابلة. أعزائي القراء ، شكرًا جزيلاً إذا وصلت إلى هذه النقطة فجأة. آمل أن نقدم لك على الأقل بضعة أفكار.
في مقابلة ، تطرق ديمتري werf. الآن أصبحت سكين سويسرية عالمية تحل جميع المهام تقريبًا. ولكن هذا لم يكن الحال دائما. في DevOpsConf في مهرجان RIT ++ ، سيتحدث ديمتري ستولياروف عن هذه الأداة بالتفصيل. سيكون التقرير "werf هو أداة لدينا CI / CD في Kubernetes" كل شيء: المشاكل والفروق الدقيقة في Kubernetes ، حلول لهذه الصعوبات والتنفيذ الحالي لل werf بالتفصيل. انضم إلى يومي 27 و 28 مايو ، سنقوم بإنشاء أدوات مثالية.