در پیش بینی ویتالی خاباروف مصاحبه کرد دیمیتری استولیاروف ()، مدیر فنی و یکی از بنیانگذاران شرکت فلانت. ویتالی از دیمیتری درباره کارهایی که فلانت انجام می دهد، درباره Kubernetes، توسعه اکوسیستم، پشتیبانی پرسید. ما بحث کردیم که چرا Kubernetes مورد نیاز است و آیا اصلاً مورد نیاز است. و همچنین در مورد میکروسرویس‌ها، آمازون AWS، رویکرد «خوش‌شانس خواهم بود» به DevOps، آینده خود Kubernetes، چرا، کی و چگونه جهان را تسخیر می‌کند، چشم‌انداز DevOps و آنچه مهندسان باید برای آن آماده شوند. آینده روشن و نزدیک با ساده سازی و شبکه های عصبی.
به عنوان پادکست در DevOps Deflop گوش دهید - یک پادکست به زبان روسی درباره DevOps، و در زیر نسخه متنی آن است.
در اینجا و پایین او سوالاتی می پرسد مهندس از Express42.
درباره "فلانت"
- سلام دیما. شما مدیر فنی هستید"و همچنین بنیانگذار آن. لطفا به ما بگویید که شرکت چه می کند و آیا شما در آن هستید؟
دیمیتری: از بیرون به نظر می رسد که ما بچه هایی هستیم که به نصب Kubernetes برای همه می پردازیم و کاری با آن انجام می دهیم. اما این درست نیست. ما به عنوان یک شرکت با لینوکس شروع به کار کردیم، اما برای مدت طولانی فعالیت اصلی ما خدمات تولید و پروژه های کلید در دست پر بار بوده است. معمولاً ما کل زیرساخت را از ابتدا می سازیم و سپس برای مدت طولانی مسئول آن هستیم. بنابراین، اصلی ترین کاری که «فلانت» انجام می دهد و برای آن پول می گیرد، این است مسئولیت پذیری و اجرای تولید کلید در دست.
من به عنوان مدیر فنی و یکی از بنیانگذاران شرکت، تمام روز و شب را صرف تلاش برای کشف چگونگی افزایش دسترسی به تولید، ساده کردن عملیات آن، آسان‌تر کردن زندگی مدیران و خوشایندتر کردن زندگی توسعه‌دهندگان می‌کنم. .
درباره Kubernetes
- اخیراً گزارش‌های زیادی از فلانت و در مورد Kubernetes چگونه به آن رسیدید؟
دیمیتری: قبلاً بارها در این مورد صحبت کرده ام، اما اصلاً بدم نمی آید که آن را تکرار کنم. من فکر می کنم درست است که این موضوع را تکرار کنیم زیرا بین علت و معلول خلط وجود دارد.
ما واقعا به یک ابزار نیاز داشتیم. ما با مشکلات زیادی روبرو شدیم، مبارزه کردیم، با عصاهای مختلف بر آنها غلبه کردیم و نیاز به ابزار را احساس کردیم. ما گزینه های مختلف زیادی را پشت سر گذاشتیم، دوچرخه های خودمان را ساختیم و تجربه به دست آوردیم. به تدریج به نقطه ای رسیدیم که تقریباً به محض ظهور آن - در حدود سال 2013 - شروع به استفاده از Docker کردیم. در زمان ظهور آن، ما قبلاً تجربه زیادی با کانتینرها داشتیم، قبلاً یک آنالوگ از "Docker" نوشته بودیم - برخی از عصاهای خودمان در پایتون. با ظهور داکر، پرتاب عصا و استفاده از یک راه حل قابل اعتماد و پشتیبانی شده توسط جامعه امکان پذیر شد.
با Kubernetes داستان مشابه است. در زمانی که شروع به افزایش سرعت کرد - برای ما این نسخه 1.2 است - ما قبلاً یک دسته عصا در شل و سر آشپز داشتیم که به نوعی سعی کردیم آنها را با داکر هماهنگ کنیم. ما به طور جدی به دنبال راه حل های Rancher و راه حل های مختلف دیگر بودیم، اما پس از آن Kubernetes ظاهر شد، که در آن همه چیز دقیقاً همانطور که ما انجام می دادیم یا حتی بهتر از آن اجرا می شد. چیزی برای شکایت وجود ندارد.
بله، اینجا یک نوع نقص وجود دارد، یک نوع نقص وجود دارد - نقص های زیادی وجود دارد و 1.2 به طور کلی وحشتناک است، اما ... Kubernetes مانند یک ساختمان در حال ساخت است - شما به پروژه نگاه کنید و متوجه شوید. که باحال خواهد بود اگر ساختمان اکنون یک پایه و دو طبقه دارد، پس می‌دانید که بهتر است هنوز وارد خانه نشوید، اما چنین مشکلی در نرم‌افزار وجود ندارد - می‌توانید از قبل از آن استفاده کنید.
ما لحظه ای نداشتیم که فکر کنیم از Kubernetes استفاده کنیم یا نه. ما مدتها قبل از اینکه ظاهر شود منتظر آن بودیم و سعی کردیم خودمان آنالوگ ایجاد کنیم.
درباره Kubernetes
- آیا شما مستقیماً در توسعه خود Kubernetes مشارکت دارید؟
دیمیتری: متوسط بلکه در توسعه اکوسیستم مشارکت می کنیم. ما تعداد معینی درخواست کشش را ارسال می کنیم: به Prometheus، به اپراتورهای مختلف، به Helm - به اکوسیستم. متأسفانه، من نمی توانم تمام کارهایی که انجام می دهیم را پیگیری کنم و ممکن است اشتباه کنم، اما حتی یک استخر از ما به هسته اصلی وجود ندارد.
- در همان زمان، آیا بسیاری از ابزارهای خود را در اطراف Kubernetes توسعه می دهید؟
دیمیتری: استراتژی این است: ما می رویم و درخواست ها را به هر چیزی که از قبل وجود دارد می کشیم. اگر درخواست‌های کشش در آنجا پذیرفته نشد، ما خودمان آنها را فورک می‌کنیم و زندگی می‌کنیم تا زمانی که با ساخت‌هایمان پذیرفته شوند. سپس وقتی به upstream رسید، به نسخه upstream برمی گردیم.
به عنوان مثال، ما یک اپراتور Prometheus داریم که احتمالاً 5 بار قبلاً با آن به بالادست مونتاژ خود رفتیم و برگشتیم. ما به نوعی ویژگی نیاز داریم، یک درخواست کشش ارسال کردیم، باید فردا آن را عرضه کنیم، اما نمی‌خواهیم منتظر انتشار آن در بالادست باشیم. بر این اساس، ما برای خودمان مونتاژ می کنیم، مونتاژ خود را با ویژگی خود، که به دلایلی به آن نیاز داریم، در همه خوشه های خود پخش می کنیم. بعد مثلاً در بالادست آن را با این جمله به ما تحویل می‌دهند: «بچه‌ها، بیایید این کار را برای یک مورد کلی‌تر انجام دهیم»، ما یا شخص دیگری آن را تمام می‌کنیم و به مرور زمان دوباره ادغام می‌شود.
ما سعی می کنیم هر چیزی را که وجود دارد توسعه دهیم. بسیاری از عناصری که هنوز وجود ندارند، هنوز اختراع نشده اند، یا اختراع شده اند، اما زمان اجرای آن را نداشته اند - ما این کار را انجام می دهیم. و نه به این دلیل که ما فرآیند یا ساخت دوچرخه را به عنوان یک صنعت دوست داریم، بلکه صرفاً به این دلیل که به این ابزار نیاز داریم. اغلب این سوال مطرح می شود که چرا این یا آن کار را انجام دادیم؟ پاسخ ساده است - بله، زیرا ما مجبور بودیم جلوتر برویم، یک مشکل عملی را حل کنیم، و آن را با این تولا حل کردیم.
مسیر همیشه به این صورت است: ما با دقت جستجو می کنیم و اگر راه حلی در مورد چگونگی ساختن ترولی باس از یک قرص نان پیدا نکردیم، آنگاه نان خودمان و ترولیبوس خود را می سازیم.
ابزار فلانتا
- می دانم که Flant اکنون دارای اپراتورهای افزونه، اپراتورهای پوسته و ابزارهای dapp/werf است. همانطور که من متوجه شدم، این همان ابزار در تجسم های مختلف است. همچنین می‌دانم که ابزارهای مختلف بیشتری در Flaunt وجود دارد. درست است؟
دیمیتری: ما چیزهای بیشتری در GitHub داریم. از آنچه که اکنون به یاد دارم، ما یک وضعیت نقشه داریم - یک پانل برای Grafana که همه با آن برخورد کرده اند. تقریباً در هر دومین مقاله در مورد نظارت Kubernetes در Medium ذکر شده است. غیرممکن است که به طور خلاصه توضیح دهیم که نقشه وضعیت چیست - به یک مقاله جداگانه نیاز دارد، اما برای نظارت بر وضعیت در طول زمان بسیار مفید است، زیرا در Kubernetes اغلب نیاز داریم وضعیت را در طول زمان نشان دهیم. ما همچنین LogHouse داریم - این چیزی است که بر اساس ClickHouse و جادوی سیاه برای جمع آوری لاگ ها در Kubernetes است.
بسیاری از خدمات آب و برق! و حتی موارد بیشتری نیز وجود خواهد داشت، زیرا تعدادی از راه حل های داخلی امسال منتشر خواهند شد. از میان موارد بسیار بزرگ مبتنی بر اپراتور افزونه، تعداد زیادی افزونه برای Kubernetes وجود دارد، البته نحوه نصب صحیح sert manager - ابزاری برای مدیریت گواهینامه ها، نحوه نصب صحیح Prometheus با تعدادی لوازم جانبی - اینها حدود بیست مورد متفاوت هستند. باینری هایی که داده ها را صادر می کنند و چیزی را جمع آوری می کنند، به این Prometheus شگفت انگیزترین گرافیک ها و هشدارها را دارد. همه اینها فقط یک دسته از افزونه های Kubernetes هستند که در یک خوشه نصب می شوند و از ساده به سرد، پیچیده و خودکار تبدیل می شوند که بسیاری از مسائل قبلاً حل شده است. بله، ما خیلی کار می کنیم.
توسعه اکوسیستم
"به نظر من این کمک بزرگی به توسعه این ابزار و روش های استفاده از آن است." آیا می توانید تقریباً تخمین بزنید که چه کسی می تواند همین سهم را در توسعه اکوسیستم داشته باشد؟
دیمیتری: در روسیه، از شرکت هایی که در بازار ما فعالیت می کنند، هیچ کس حتی نزدیک نیست. البته، این یک بیانیه بلند است، زیرا بازیکنان بزرگی مانند Mail و Yandex وجود دارند - آنها نیز با Kubernetes کاری انجام می دهند، اما حتی به سهم شرکت هایی در کل جهان که خیلی بیشتر از ما انجام می دهند نزدیک نیستند. مقایسه فلانت که 80 نفر پرسنل دارد و رد هت که به تنهایی 300 مهندس در هر کوبرنت دارد، اگر اشتباه نکنم دشوار است. مقایسه کردنش سخته ما 6 نفر در بخش RnD داریم که از جمله من است که تمام ابزارهایمان را می بریم. 6 نفر در مقابل 300 مهندس کلاه قرمزی - مقایسه آن به نوعی دشوار است.
- با این حال، زمانی که حتی این 6 نفر می توانند کاری واقعا مفید و بیگانه انجام دهند، زمانی که با یک مشکل عملی مواجه می شوند و راه حل را به جامعه می دهند - یک مورد جالب. من درک می کنم که در شرکت های فناوری بزرگ، جایی که آنها تیم توسعه و پشتیبانی Kubernetes خود را دارند، در اصل، همان ابزارها را می توان توسعه داد. این نمونه ای است برای آنها از آنچه می توان توسعه داد و به جامعه داد و به کل جامعه ای که از Kubernetes استفاده می کند انگیزه داد.
دیمیتری: این احتمالاً یکی از ویژگی های یکپارچه کننده، ویژگی خاص آن است. ما پروژه های زیادی داریم و موقعیت های مختلفی را می بینیم. برای ما راه اصلی ایجاد ارزش افزوده، تجزیه و تحلیل این موارد، یافتن اشتراکات و ارزان‌ترین آنها برای خودمان است. ما فعالانه روی این موضوع کار می کنیم. صحبت کردن درباره روسیه و جهان برای من سخت است، اما ما حدود 40 مهندس DevOps در شرکت داریم که روی Kubernetes کار می کنند. من فکر نمی‌کنم شرکت‌های زیادی در روسیه با تعداد قابل مقایسه متخصصی که Kubernetes را درک می‌کنند، وجود نداشته باشد.
من همه چیز را در مورد عنوان شغل مهندس DevOps می دانم، همه همه چیز را می فهمند و عادت دارند مهندسان DevOps را مهندس DevOps بخوانند، ما در این مورد بحث نمی کنیم. همه این 40 مهندس DevOps شگفت‌انگیز هر روز با مشکلاتی روبرو می‌شوند و مشکلات را حل می‌کنند، ما فقط این تجربه را تجزیه و تحلیل می‌کنیم و سعی می‌کنیم تعمیم دهیم. ما درک می کنیم که اگر در درون ما بماند، پس از یک یا دو سال این ابزار بی فایده خواهد بود، زیرا در جایی در جامعه یک تولا آماده ظاهر می شود. انباشته کردن این تجربه به صورت داخلی فایده ای ندارد - صرفاً انرژی و زمان را در dev/null تخلیه می کند. و ما اصلاً برای آن متاسف نیستیم. ما همه چیز را با کمال میل منتشر می کنیم و درک می کنیم که باید منتشر شود، توسعه یابد، تبلیغ شود، تبلیغ شود، تا مردم از آن استفاده کنند و تجربه خود را اضافه کنند - سپس همه چیز رشد می کند و زندگی می کند. بعد از دو سال ساز به سطل زباله نمی رود. حیف نیست که به قدرت خود ادامه دهید، زیرا واضح است که کسی از ابزار شما استفاده می کند و بعد از دو سال همه از آن استفاده می کنند.
این بخشی از استراتژی بزرگ ما با dapp/werf است. یادم نیست از کی شروع به ساختش کردیم، انگار 3 سال پیش بود. در ابتدا، به طور کلی روی پوسته بود. این یک اثبات فوق العاده از مفهوم بود، ما برخی از مشکلات خاص خود را حل کردیم - کار کرد! اما در مورد پوسته مشکلاتی وجود دارد، نمی توان آن را بیشتر گسترش داد، برنامه نویسی روی پوسته کار دیگری است. ما عادت داشتیم به زبان روبی بنویسیم، بر این اساس، چیزی را در روبی بازسازی کردیم، توسعه دادیم، توسعه دادیم، توسعه دادیم، و به این واقعیت برخورد کردیم که جامعه، جمعیتی که نمی‌گویند «می‌خواهیم یا نمی‌خواهیم». دماغش را به روبی می زند، چقدر خنده دار است؟ ما متوجه شدیم که باید همه این موارد را در Go بنویسیم فقط برای رسیدن به اولین نکته در چک لیست: ابزار DevOps باید یک باینری ثابت باشد. رفتن یا نبودن چندان مهم نیست، اما یک باینری استاتیک که در Go نوشته شود بهتر است.
ما انرژی خود را صرف کردیم، dapp را در Go بازنویسی کردیم و آن را werf نامیدیم. Dapp دیگر پشتیبانی نمی‌شود، توسعه نمی‌یابد، در آخرین نسخه اجرا می‌شود، اما یک مسیر ارتقای مطلق به بالا وجود دارد و می‌توانید آن را دنبال کنید.
چرا dapp ایجاد شد؟
- می‌توانید به طور خلاصه به ما بگویید که چرا dapp ایجاد شد، چه مشکلاتی را حل می‌کند؟
دیمیتری: دلیل اول در مجلس است. در ابتدا، زمانی که داکر قابلیت های چند مرحله ای را نداشت، در ساخت با مشکلات جدی مواجه بودیم، بنابراین ما به تنهایی چند مرحله را ساختیم. سپس با تمیز کردن تصویر مشکلات زیادی داشتیم. هرکسی که CI/CD را انجام می دهد، زودتر با این مشکل مواجه می شود که تعداد زیادی عکس جمع آوری شده است، شما باید به نحوی مواردی را که لازم نیست پاک کنید و آنچه لازم است را رها کنید.
دلیل دوم استقرار است. بله، Helm وجود دارد، اما فقط برخی از مشکلات را حل می کند. به اندازه کافی خنده دار، نوشته شده است که "Helm مدیر بسته برای Kubernetes است." دقیقا همان چیزی است که "the". همچنین کلمات "Package Manager" وجود دارد - انتظارات معمول از یک Package Manager چیست؟ ما می گوییم: "Package Manager - بسته را نصب کنید!" و ما انتظار داریم که او به ما بگوید: "بسته تحویل داده شده است."
جالب است که می گوییم: "هلم، بسته را نصب کن" و وقتی او پاسخ می دهد که آن را نصب کرده است، معلوم می شود که او تازه نصب را شروع کرده است - به Kubernetes اشاره کرد: "این چیز را راه اندازی کنید!"، و اینکه آیا شروع شده است یا نه ، چه کار کند چه نباشد، هلم اصلا این موضوع را حل نمی کند.
به نظر می رسد که Helm فقط یک پیش پردازشگر متن است که داده ها را در Kubernetes بارگذاری می کند.
اما به عنوان بخشی از هر استقرار، می خواهیم بدانیم که آیا برنامه برای تولید منتشر شده است یا خیر؟ Roll out to prod به این معنی است که برنامه به آنجا منتقل شده است، نسخه جدید مستقر شده است و حداقل در آنجا خراب نمی شود و به درستی پاسخ می دهد. هلم به هیچ وجه این مشکل را حل نمی کند. برای حل آن، باید تلاش زیادی را صرف کنید، زیرا باید به کوبرنتس دستور دهید تا آنچه را که در آنجا اتفاق می‌افتد - اعم از اینکه مستقر شده باشد یا منتشر شده، نظارت کند. و همچنین بسیاری از وظایف مربوط به استقرار، تمیز کردن، و مونتاژ وجود دارد.
طرح
امسال توسعه محلی را آغاز خواهیم کرد. ما می‌خواهیم به آنچه قبلاً در 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 را تحویل داده ایم و کدام را ارائه نکرده ایم؟ هزاران سوال مطرح می شود و برای پاسخ به آنها باید 15 تا 20 سال در این صنعت سپری کنید.
من یک مثال اخیر در مورد این موضوع دارم که ممکن است معنای مشکل "آیا نگهداری Kubernetes دشوار است؟" چند وقت پیش به طور جدی به این فکر کردیم که آیا باید سعی کنیم Cilium را به عنوان یک شبکه در Kubernetes پیاده سازی کنیم.
اجازه بدهید توضیح دهم سیلیوم چیست. Kubernetes پیاده سازی های مختلفی از زیرسیستم شبکه دارد و یکی از آنها بسیار جالب است - Cilium. معنی آن چیست؟ در کرنل مدتی پیش امکان نوشتن قلاب هایی برای کرنل فراهم شد که به هر طریقی به زیرسیستم شبکه و زیرسیستم های مختلف دیگر حمله می کنند و به شما اجازه می دهند که تکه های بزرگ هسته را دور بزنید.
هسته لینوکس از لحاظ تاریخی دارای یک مسیر آی پی، یک فیلتر بیش از حد، پل ها و بسیاری از اجزای مختلف قدیمی است که 15، 20، 30 سال قدمت دارند. به طور کلی، آنها کار می کنند، همه چیز عالی است، اما اکنون ظروف روی هم انباشته کرده اند، و به نظر می رسد یک برج 15 آجری روی هم است، و شما روی یک پا روی آن می ایستید - احساس عجیبی است. این سیستم در طول تاریخ با تفاوت های ظریف مانند آپاندیس در بدن توسعه یافته است. برای مثال، در برخی شرایط، مشکلات عملکردی وجود دارد.
یک BPF فوق العاده و توانایی نوشتن قلاب برای هسته وجود دارد - بچه ها قلاب های خود را برای هسته نوشتند. بسته وارد هسته لینوکس می شود، آن را درست در ورودی خارج می کنند، آن را همانطور که باید بدون پل، بدون TCP، بدون پشته IP پردازش می کنند - به طور خلاصه، همه چیزهایی که در هسته لینوکس نوشته شده را دور می زنند و سپس تف می کنند. آن را در ظرف خارج کنید.
چی شد؟ عملکرد بسیار جالب، ویژگی های جالب - فقط جالب! اما ما به این نگاه می کنیم و می بینیم که در هر ماشین برنامه ای وجود دارد که به API Kubernetes متصل می شود و بر اساس داده هایی که از این API دریافت می کند، کد C تولید می کند و باینری هایی را کامپایل می کند که در هسته بارگذاری می شود تا این هوک ها کار کنند. در فضای هسته
اگر مشکلی پیش بیاید چه اتفاقی می افتد؟ ما نمی دانیم. برای درک این موضوع، باید تمام این کد را بخوانید، تمام منطق را درک کنید، و شگفت‌انگیز است که چقدر دشوار است. اما، از سوی دیگر، این پل‌ها، فیلترهای شبکه، مسیریابی آی‌پی وجود دارد - من کد منبع آنها را نخوانده‌ام، و همچنین 40 مهندس که در شرکت ما کار می‌کنند نیز چنین نیستند. شاید فقط تعداد کمی از بخش ها را درک کنند.
و چه تفاوتی دارد؟ به نظر می رسد که مسیر آی پی، هسته لینوکس وجود دارد، و یک ابزار جدید وجود دارد - چه فرقی می کند، ما یکی یا دیگری را نمی فهمیم. اما ما می ترسیم از چیز جدیدی استفاده کنیم - چرا؟ زیرا اگر ابزار 30 ساله باشد، پس از 30 سال تمام اشکالات پیدا شده است، همه اشتباهات روی آنها گذاشته شده است و شما نیازی به دانستن در مورد همه چیز ندارید - مانند یک جعبه سیاه کار می کند و همیشه کار می کند. همه می دانند که کدام پیچ گوشتی تشخیصی را در کدام مکان بچسبانند، کدام tcpdump را در چه لحظه ای اجرا کنند. همه ابزارهای تشخیصی را به خوبی می شناسند و می دانند که چگونه این مجموعه از مؤلفه ها در هسته لینوکس کار می کند - نه اینکه چگونه کار می کند، بلکه نحوه استفاده از آن.
و سیلیوم فوق‌العاده 30 ساله نیست، هنوز پیر نشده است. Kubernetes هم همین مشکل را دارد، کپی کنید. اینکه Cilium به خوبی نصب شده است، که Kubernetes به طور کامل نصب شده است، اما وقتی مشکلی در تولید پیش می‌آید، آیا می‌توانید سریعاً در یک موقعیت بحرانی بفهمید که چه اشتباهی رخ داده است؟
وقتی می گوییم آیا نگهداری از Kubernetes دشوار است - نه، بسیار آسان است، و بله، فوق العاده دشوار است. Kubernetes به تنهایی عالی عمل می کند، اما با یک میلیارد تفاوت.
درباره رویکرد "خوش شانس خواهم بود".
- آیا شرکت هایی وجود دارند که تقریباً تضمین شده است که این تفاوت های ظریف ظاهر شوند؟ فرض کنید Yandex به طور ناگهانی تمام خدمات را به Kubernetes منتقل می کند، بار زیادی در آنجا وجود خواهد داشت.
دیمیتری: نه، این یک گفتگو در مورد بار نیست، بلکه در مورد ساده ترین چیزها است. به عنوان مثال، ما Kubernetes را داریم، ما برنامه را در آنجا مستقر کردیم. چگونه می دانید که کار می کند؟ به سادگی هیچ ابزار آماده ای برای درک عدم خرابی برنامه وجود ندارد. هیچ سیستم آماده ای برای ارسال هشدار وجود ندارد؛ شما باید این هشدارها و هر زمان بندی را پیکربندی کنید. و ما در حال به روز رسانی Kubernetes هستیم.
من اوبونتو 16.04 دارم. می توان گفت که این یک نسخه قدیمی است، اما ما هنوز در آن هستیم زیرا LTS است. systemd وجود دارد که تفاوت آن این است که C-group ها را پاک نمی کند. Kubernetes پادها را راه‌اندازی می‌کند، گروه‌های C ایجاد می‌کند، سپس پادها را حذف می‌کند، و به نوعی معلوم می‌شود - من جزئیات را به خاطر ندارم، متأسفم - که برش‌های systemd باقی می‌مانند. این منجر به این واقعیت می شود که با گذشت زمان، هر خودرو به شدت شروع به کاهش سرعت می کند. این حتی یک سوال در مورد بارگذاری بالا نیست. اگر پادهای دائمی راه اندازی شوند، به عنوان مثال، اگر یک Cron Job وجود داشته باشد که دائماً پادها تولید می کند، دستگاه با اوبونتو 16.04 بعد از یک هفته شروع به کند شدن می کند. به دلیل این واقعیت که یک دسته از گروه های C ایجاد شده است، میانگین بار دائمی بالا خواهد بود. این مشکلی است که هر شخصی که به سادگی Ubuntu 16 و Kubernetes را در بالا نصب کند با آن مواجه خواهد شد.
بیایید بگوییم که او به نوعی سیستم یا چیز دیگری را به روز می کند، اما در هسته لینوکس تا 4.16 حتی خنده دارتر است - وقتی گروه های C را حذف می کنید، در هسته نشت می کنند و در واقع حذف نمی شوند. بنابراین، پس از یک ماه کار بر روی این دستگاه، مشاهده آمار حافظه برای اجاق ها غیرممکن خواهد بود. ما یک فایل را بیرون می آوریم، آن را در برنامه رول می کنیم، و یک فایل به مدت 15 ثانیه رول می شود، زیرا هسته زمان زیادی می برد تا یک میلیون گروه C را در خود حساب کند، که به نظر می رسد حذف شده اند، اما نه - آنها نشت می کنند. .
هنوز هم خیلی چیزهای کوچک اینجا و آنجا وجود دارد. این مسئله ای نیست که شرکت های غول پیکر ممکن است گاهی اوقات تحت بارهای بسیار سنگین با آن مواجه شوند - نه، این یک موضوع روزمره است. مردم می توانند ماه ها به این شکل زندگی کنند - آنها Kubernetes را نصب کردند، برنامه را مستقر کردند - به نظر می رسد کار می کند. برای بسیاری از مردم این طبیعی است. آنها حتی نمی دانند که این برنامه به دلایلی خراب می شود، آنها هشداری دریافت نمی کنند، اما برای آنها این هنجار است. قبلاً بدون نظارت بر روی ماشین های مجازی زندگی می کردیم ، اکنون به Kubernetes نقل مکان کردیم ، همچنین بدون نظارت - تفاوت چیست؟
سوال این است که وقتی روی یخ راه می‌رویم، هرگز ضخامت آن را نمی‌دانیم مگر اینکه از قبل آن را اندازه‌گیری کنیم. بسیاری از مردم راه می روند و نگران نیستند، زیرا قبلاً راه رفته اند.
از نظر من، نکته ظریف و پیچیدگی عملکرد هر سیستمی این است که اطمینان حاصل شود که ضخامت یخ دقیقاً برای حل مشکلات ما کافی است. این چیزی است که ما در مورد آن صحبت می کنیم.
در فناوری اطلاعات، به نظر من، رویکردهای "خوش شانس خواهم بود" بسیار زیاد است. بسیاری از افراد به این امید که خوش شانس باشند نرم افزار نصب می کنند و از کتابخانه های نرم افزاری استفاده می کنند. به طور کلی، بسیاری از افراد خوش شانس هستند. احتمالاً به همین دلیل است که کار می کند.
- از ارزیابی بدبینانه من، به نظر می رسد: هنگامی که خطرات بالا هستند و برنامه باید کار کند، پس از آن پشتیبانی از Flaunt، شاید از Red Hat، لازم است، یا شما نیاز به تیم داخلی خود دارید که به طور خاص به Kubernetes اختصاص داده شده است، که آماده است. برای کشیدن آن
دیمیتری: به طور عینی، این چنین است. ورود به داستان Kubernetes برای یک تیم کوچک به تنهایی شامل تعدادی از خطرات است.
آیا به کانتینر نیاز داریم؟
- آیا می توانید به ما بگویید که Kubernetes در روسیه چقدر گسترده است؟
دیمیتری: من این داده ها را ندارم و مطمئن نیستم که شخص دیگری آن را داشته باشد. ما می گوییم: "Kubernetes، Kubernetes"، اما نگاه دیگری به این موضوع وجود دارد. من همچنین نمی‌دانم کانتینرها چقدر گسترده هستند، اما آماری را از گزارش‌های موجود در اینترنت می‌دانم که نشان می‌دهد 70 درصد کانتینرها توسط Kubernetes تنظیم شده‌اند. این یک منبع قابل اعتماد برای نمونه نسبتاً بزرگی در سراسر جهان بود.
سپس یک سوال دیگر - آیا ما به ظروف نیاز داریم؟ احساس شخصی من و موضع کلی شرکت فلانت این است که Kubernetes یک استاندارد واقعی است.
چیزی جز Kubernetes وجود نخواهد داشت.
این یک تغییر مطلق بازی در زمینه مدیریت زیرساخت است. فقط مطلق - همین است، دیگر خبری از Ansible، آشپز، ماشین های مجازی، 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 نفره را به عملیات اختصاص دهید، زیرا در غیر این صورت هیچ فایده‌ای ندارد. قطعا برون سپاری این امر منطقی است.
درباره آمازون و گوگل
- آیا میزبانی از راه حلی از آمازون یا گوگل می تواند به عنوان برون سپاری در نظر گرفته شود؟
دیمیتری: بله، البته این یک سری مسائل را حل می کند. اما باز هم تفاوت های ظریف وجود دارد. هنوز باید نحوه استفاده از آن را بدانید. به عنوان مثال، هزاران چیز کوچک در کار آمازون AWS وجود دارد: Load Balancer باید گرم شود یا باید از قبل درخواستی نوشته شود که "بچه ها، ما ترافیک دریافت می کنیم، Load Balancer را برای ما گرم کنید!" شما باید این تفاوت های ظریف را بدانید.
وقتی به افرادی مراجعه می کنید که در این زمینه تخصص دارند، تقریباً همه چیزهای معمولی بسته می شوند. ما اکنون 40 مهندس داریم، تا پایان سال احتمالاً 60 نفر خواهند بود - ما قطعاً با همه این موارد روبرو شده ایم. حتی اگر در پروژه‌ای دوباره با این مشکل مواجه شویم، سریعاً از یکدیگر می‌پرسیم و می‌دانیم چگونه آن را حل کنیم.
احتمالاً پاسخ این است - البته، یک داستان میزبانی شده بخشی را آسان تر می کند. سوال اینجاست که آیا حاضرید به این هاست ها اعتماد کنید و آیا آنها مشکلات شما را حل خواهند کرد؟ آمازون و گوگل خوب عمل کرده اند. برای همه موارد ما - دقیقا. ما دیگر تجربه مثبتی نداریم. همه ابرهای دیگری که ما سعی کردیم با آنها کار کنیم مشکلات زیادی ایجاد می کنند - Ager و هر آنچه در روسیه وجود دارد و انواع OpenStack در پیاده سازی های مختلف: Headster، Overage - هر آنچه که می خواهید. همه آنها مشکلاتی را ایجاد می کنند که شما نمی خواهید آنها را حل کنید.
بنابراین، پاسخ مثبت است، اما، در واقع، راه حل های میزبان بالغ بسیار زیادی وجود ندارد.
چه کسی به Kubernetes نیاز دارد؟
- و با این حال، چه کسی به Kubernetes نیاز دارد؟ چه کسی باید قبلاً به Kubernetes سوئیچ کند، که مشتری معمولی Flaunt است که به طور خاص برای Kubernetes آمده است؟
دیمیتری: این یک سوال جالب است، زیرا در حال حاضر، در پی کوبرنتس، افراد زیادی به ما مراجعه می کنند: "بچه ها، ما می دانیم که شما دارید Kubernetes می کنید، این کار را برای ما انجام دهید!" ما به آنها پاسخ می دهیم: "آقایان، ما Kubernetes را انجام نمی دهیم، ما prod و هر چیزی که به آن مرتبط است انجام می دهیم." زیرا در حال حاضر ساختن یک محصول بدون انجام تمام CI/CD و کل این داستان غیرممکن است. همه از این تقسیم بندی دور شده اند که توسعه با توسعه داریم و بعد استثمار با استثمار.
مشتریان ما چیزهای مختلفی را انتظار دارند، اما همه انتظار دارند معجزه خوبی داشته باشند که مشکلات خاصی دارند، و اکنون - هاپ! - Kubernetes آنها را حل خواهد کرد. مردم به معجزه اعتقاد دارند. در ذهنشان می فهمند که معجزه ای وجود نخواهد داشت، اما در روحشان امیدوارند - چه می شود اگر این کوبرنتس اکنون همه چیز را برای ما حل کند، آنها اینقدر در مورد آن صحبت می کنند! ناگهان او در حال حاضر - عطسه! - و یک گلوله نقره ای، عطسه! - و ما 100٪ آپتایم داریم، همه توسعه دهندگان می توانند هر چیزی را که وارد تولید می شود 50 بار آزاد کنند، و خراب نمی شود. به طور کلی، یک معجزه!
وقتی چنین افرادی به ما مراجعه می کنند، می گوییم: "متاسفم، اما چیزی به نام معجزه وجود ندارد." برای سالم بودن باید خوب غذا بخورید و ورزش کنید. برای داشتن یک محصول قابل اعتماد، باید آن را با اطمینان ساخته شود. برای داشتن یک CI/CD مناسب، باید آن را به این صورت بسازید. این خیلی کار است که باید انجام شود.
در پاسخ به این سوال که چه کسی به Kubernetes نیاز دارد - هیچ کس به Kubernetes نیاز ندارد.
برخی افراد این تصور غلط را دارند که به Kubernetes نیاز دارند. مردم نیاز دارند، آنها نیاز عمیقی دارند که از فکر کردن، مطالعه کردن و علاقه مند شدن به تمام مشکلات زیرساختی و مشکلات اجرای برنامه های خود دست بکشند. آنها می خواهند برنامه ها فقط کار کنند و فقط مستقر شوند. برای آنها، Kubernetes این امید است که آنها از شنیدن داستان "ما آنجا دراز کشیده بودیم" یا "ما نمی توانیم بیرون بیاییم" یا چیز دیگری را متوقف کنند.
معمولا مدیر فنی پیش ما می آید. از او دو چیز می پرسند: از یک طرف به ما ویژگی بدهد، از طرف دیگر ثبات. پیشنهاد می کنیم این کار را به عهده بگیرید و انجام دهید. گلوله نقره یا بهتر است بگوییم روکش نقره این است که دیگر به این مشکلات فکر نمی کنید و زمان را تلف نمی کنید. شما افراد خاصی خواهید داشت که این موضوع را می بندند.
این جمله که ما یا هر شخص دیگری به Kubernetes نیاز داریم نادرست است.
ادمین ها واقعا به Kubernetes نیاز دارند، زیرا این یک اسباب بازی بسیار جالب است که می توانید با آن بازی کنید و با آن بازی کنید. بیایید صادق باشیم - همه اسباب بازی ها را دوست دارند. همه ما یک جایی بچه هستیم و وقتی یک جدید می بینیم می خواهیم آن را بازی کنیم. برای برخی، به عنوان مثال، در مدیریت، از این کار دلسرد شده است، زیرا آنها قبلاً به اندازه کافی بازی کرده اند و در حال حاضر به حدی خسته شده اند که به سادگی نمی خواهند. اما این به طور کامل برای کسی گم نشده است. به عنوان مثال، اگر مدت زیادی است که از اسباب‌بازی‌ها در زمینه مدیریت سیستم و DevOps خسته شده‌ام، هنوز هم اسباب‌بازی‌ها را دوست دارم، هنوز هم تعدادی اسباب‌بازی جدید می‌خرم. همه مردم، به هر شکلی، هنوز هم نوعی اسباب بازی می خواهند.
نیازی به بازی با تولید نیست. هر کاری که من قاطعانه توصیه می کنم انجام ندهم و آنچه اکنون به طور انبوه می بینم: "اوه، یک اسباب بازی جدید!" - دویدند تا آن را بخرند، خریدند و: "بیایید آن را به مدرسه ببریم و به همه دوستانمان نشان دهیم." این کار را نکن من عذرخواهی می کنم، بچه های من تازه بزرگ می شوند، من دائماً چیزی را در بچه ها می بینم، در خودم متوجه آن می شوم و بعد آن را به دیگران تعمیم می دهم.
پاسخ نهایی این است: شما به Kubernetes نیاز ندارید. شما باید مشکلات خود را حل کنید.
آنچه می توانید به دست آورید این است:
- prod نمی افتد;
- حتی اگر بخواهد سقوط کند، ما از قبل از آن مطلع هستیم و می توانیم چیزی در آن قرار دهیم.
- ما می‌توانیم آن را با سرعتی که کسب‌وکارمان به آن نیاز دارد تغییر دهیم، و می‌توانیم آن را به راحتی انجام دهیم؛ هیچ مشکلی برای ما ایجاد نمی‌کند.
دو نیاز واقعی وجود دارد: قابلیت اطمینان و پویایی/انعطاف پذیری عرضه. هرکسی که در حال حاضر نوعی پروژه فناوری اطلاعات را انجام می دهد، مهم نیست در چه نوع کسب و کاری - نرم برای سهولت در جهان، و کسانی که این را درک می کنند، باید این نیازها را حل کنند. Kubernetes با رویکرد درست، با درک درست و با تجربه کافی به شما امکان می دهد آنها را حل کنید.
درباره بدون سرور
- اگر کمی به آینده نگاه کنید، سپس سعی کنید مشکل عدم وجود سردرد را با زیرساخت حل کنید، با سرعت انتشار و سرعت تغییرات برنامه، راه حل های جدیدی ظاهر می شوند، به عنوان مثال، بدون سرور. آیا پتانسیلی در این جهت احساس می‌کنید و مثلاً خطری برای کوبرنتیس و راه‌حل‌های مشابه وجود دارد؟
دیمیتری: در اینجا لازم است دوباره تذکر دهیم که من بیننده نیستم که به جلو نگاه کنم و بگویم - اینطور می شود! اگرچه من همین کار را کردم. من به پاهایم نگاه می کنم و یک سری مشکلات را آنجا می بینم، مثلاً ترانزیستورها در رایانه چگونه کار می کنند. خنده دار است، درست است؟ ما با برخی از اشکالات در CPU مواجه هستیم.
بدون سرور را کاملا قابل اعتماد، ارزان، کارآمد و راحت کنید و همه مسائل اکوسیستم را حل کنید. در اینجا من با ایلان ماسک موافقم که یک سیاره دوم برای ایجاد تحمل خطا برای بشریت مورد نیاز است. اگرچه نمی‌دانم او چه می‌گوید، اما می‌دانم که خودم آماده نیستم به مریخ پرواز کنم و فردا این اتفاق نخواهد افتاد.
بدون سرور به وضوح مشخص است که این یک چیز درست ایدئولوژیک است، مانند تحمل خطا برای بشریت - داشتن دو سیاره بهتر از یک سیاره است. اما اکنون چگونه باید این کار را انجام داد؟ اگر تلاش خود را روی آن متمرکز کنید، ارسال یک اکسپدیشن مشکلی نیست. به نظر من فرستادن چندین اکسپدیشن و اسکان چندین هزار نفر در آنجا نیز واقع بینانه است. اما اکنون به نظر من غیرممکن می‌آید که آن را کاملاً عیب‌پذیر کنم تا نیمی از بشریت در آنجا زندگی کنند.
بدون سرور یک به یک: چیز جالبی است، اما با مشکلات سال 2019 فاصله زیادی دارد. نزدیک به 2030 - بیایید زندگی کنیم تا آن را ببینیم. من شک ندارم که ما زندگی خواهیم کرد، ما قطعا زندگی خواهیم کرد (قبل از خواب تکرار کنید) اما اکنون باید مشکلات دیگری را حل کنیم. مثل باور به تسویه حساب پریان رنگین کمان است. بله، یکی دو درصد موارد حل می شوند و کاملاً حل می شوند، اما از نظر ذهنی، بدون سرور یک رنگین کمان است... برای من این موضوع بسیار دور و نامفهوم است. من حاضر نیستم حرف بزنم در سال 2019 نمی توانید یک برنامه کاربردی بدون سرور بنویسید.
چگونه Kubernetes تکامل خواهد یافت
- همانطور که به سمت این آینده دور بالقوه شگفت انگیز حرکت می کنیم، فکر می کنید Kubernetes و اکوسیستم اطراف آن چگونه توسعه می یابند؟
دیمیتری: من خیلی به این موضوع فکر کرده ام و پاسخ روشنی دارم. اولین مورد دارای دولت است - بالاخره انجام بدون تابعیت آسان تر است. Kubernetes در ابتدا بیشتر روی این سرمایه گذاری کرد، همه چیز با آن شروع شد. بدون ملیت تقریباً در Kubernetes کار می کند، فقط چیزی برای شکایت وجود ندارد. هنوز مشکلات زیادی وجود دارد، یا بهتر است بگوییم، تفاوت های ظریف. همه چیز در آنجا برای ما عالی کار می کند، اما این ما هستیم. حداقل یکی دو سال دیگر طول می کشد تا این برای همه کار کند. این یک شاخص حساب شده نیست، بلکه احساس من از سر من است.
به طور خلاصه، statefull باید - و خواهد - بسیار قوی توسعه یابد، زیرا همه برنامه‌های ما وضعیت را ذخیره می‌کنند؛ هیچ برنامه‌ای بدون تابعیت وجود ندارد. این یک توهم است؛ شما همیشه به نوعی پایگاه داده و چیز دیگری نیاز دارید. Statefull درباره درست کردن همه چیزهایی است که ممکن است، رفع همه اشکالات، بهبود همه مشکلاتی که در حال حاضر با آن مواجه هستند - اجازه دهید آن را پذیرش بنامیم.
سطح ناشناخته، سطح مشکلات حل نشده، سطح احتمال مواجهه با چیزی به طور قابل توجهی کاهش می یابد. این یک داستان مهم است. و اپراتورها - همه چیز مربوط به کدنویسی منطق مدیریت، منطق کنترل برای به دست آوردن یک سرویس آسان: سرویس آسان MySQL، سرویس آسان RabbitMQ، سرویس آسان Memcache - به طور کلی، همه این مؤلفه هایی که ما باید تضمین شوند تا از آنها استفاده کنیم. جعبه. این فقط مشکلی را برطرف می کند که ما یک پایگاه داده می خواهیم، اما نمی خواهیم آن را مدیریت کنیم، یا ما Kubernetes را می خواهیم، اما نمی خواهیم آن را مدیریت کنیم.
این داستان توسعه اپراتور به هر شکلی در چند سال آینده مهم خواهد بود.
من فکر می کنم سهولت استفاده باید بسیار افزایش یابد - جعبه با دستگیره های ساده تر و بیشتر سیاه و قابل اطمینان تر می شود.
من یک بار به یک مصاحبه قدیمی با اسحاق آسیموف مربوط به دهه 80 در YouTube در شنبه شب زنده گوش دادم - برنامه ای مانند Urgant که فقط جالب بود. از او در مورد آینده کامپیوتر پرسیدند. گفت آینده در سادگی است، درست مثل رادیو. گیرنده رادیویی در اصل چیز پیچیده ای بود. برای گرفتن یک موج، باید دستگیره ها را به مدت 15 دقیقه بچرخانید، سیخ ها را بچرخانید و به طور کلی بدانید که همه چیز چگونه کار می کند، فیزیک انتقال امواج رادیویی را درک کنید. در نتیجه فقط یک دکمه در رادیو باقی مانده بود.
حالا در سال 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 را سال آزمایش های جدی و اندیشیده شده و نه بازی های در حال تولید اعلام کنیم. احتمالا اینطور است.
- بسیار از شما متشکرم!
دیمیتری: متشکرم، ویتالی، هم برای وقت و هم برای مصاحبه. خوانندگان عزیز، اگر به طور ناگهانی به این نقطه رسیدید، بسیار سپاسگزارم. امیدوارم حداقل یکی دو تا فکر برای شما آورده باشیم.
در مصاحبه ، دیمیتری به موضوع ورف اشاره کرد. اکنون این یک چاقوی سوئیسی جهانی است که تقریباً همه مشکلات را حل می کند. اما همیشه چنین نیست. بر در جشنواره دیمیتری استولیاروف در مورد این ابزار به طور مفصل به شما خواهد گفت. در گزارش همه چیز وجود خواهد داشت: مشکلات و تفاوت های ظریف پنهان Kubernetes، گزینه هایی برای حل این مشکلات و اجرای فعلی werf با جزئیات. در 27 و 28 می به ما بپیوندید، ما ابزارهای عالی را ایجاد خواهیم کرد.
منبع: www.habr.com