در پایان ماه مه یک جلسه آنلاین در مورد این موضوع برگزار کرد . در اصل در مورد کانتینرها، Kubernetes و ارکستراسیون، معیارهای انتخاب زیرساخت و موارد دیگر صحبت کردیم. شرکت کنندگان مواردی را از تمرین خود به اشتراک گذاشتند.
شركت كنندگان:
- اوگنی پوتاپوف، مدیر عامل ITSumma. بیش از نیمی از مشتریان آن یا در حال نقل مکان هستند یا می‌خواهند به Kubernetes سوئیچ کنند.
- دیمیتری استولیاروف، مدیر ارشد فناوری "فلانت". دارای بیش از 10 سال سابقه کار با سیستم های کانتینری.
- دنیس رمچوکوف (با نام مستعار اریک اولدمن)، مدیر ارشد اجرایی argotech.io، سابق RAO UES. او قول داد در مورد موارد در شرکت "خونین" صحبت کند.
- آندری فدوروفسکی، CTO "News360.com"پس از خرید شرکت توسط بازیکن دیگر، او مسئولیت تعدادی از پروژه ها و زیرساخت های ML و AI را بر عهده دارد.
- ایوان کروگلوف، مهندس سیستم، سابق Booking.com.همان فردی که با دستان خود کارهای زیادی با کوبرنتس انجام داد.
موضوعات:
- بینش شرکت کنندگان در مورد کانتینرها و ارکستراسیون (Docker، Kubernetes، و غیره)؛ آنچه در عمل امتحان شده یا تحلیل شده است.
- مورد: این شرکت برای سال ها در حال ایجاد یک طرح توسعه زیرساخت است. تصمیم گیری در مورد ساخت (یا انتقال زیرساخت فعلی) به کانتینرها و کوبر چگونه گرفته می شود؟
- مشکلات در دنیای ابری بومی، آنچه گم شده است، بیایید تصور کنیم فردا چه خواهد شد.
بحث جالبی شکل گرفت، نظرات شرکت کنندگان به قدری متفاوت بود و باعث نظرات زیادی شد که می خواهم آنها را با شما به اشتراک بگذارم. بخور ، و در زیر خلاصه ای از بحث آمده است.
آیا Kubernetes در حال حاضر یک بازاریابی استاندارد یا عالی است؟
ما به آن (Kubernetes. - Ed.) رسیدیم که هنوز کسی از آن خبر نداشت. حتی زمانی که او نبود به سراغش آمدیم. ما قبلاً آن را می خواستیم" - دیمیتری استولیاروف
عکس از Reddit.com
5-10 سال پیش تعداد زیادی ابزار وجود داشت و هیچ استاندارد واحدی وجود نداشت. هر شش ماه یک محصول جدید یا حتی بیش از یک محصول جدید ظاهر می شود. ابتدا ولگرد، سپس نمک، سرآشپز، عروسک،... «و هر شش ماه یک بار زیرساخت های خود را بازسازی می کنید. آندری فدوروفسکی به یاد می آورد که شما پنج مدیر دارید که دائما مشغول بازنویسی تنظیمات هستند. او معتقد است که Docker و Kubernetes بقیه را "ازدحام کرده اند". داکر در پنج سال گذشته و Kubernetes در دو سال گذشته به یک استاندارد تبدیل شده است. و این برای صنعت خوب است..
دیمیتری استولیاروف و تیمش عاشق کوبر هستند. آنها چنین ابزاری را قبل از ظهور می خواستند و زمانی که هیچ کس از آن خبر نداشت به سراغش آمدند. در حال حاضر، به دلایل راحتی، اگر متوجه شوند که Kubernetes را با او پیاده نمی کنند، مشتری را قبول نمی کنند. در همان زمان، به گفته دیمیتری، این شرکت "داستان های موفقیت غول پیکر زیادی در مورد بازسازی میراث وحشتناک دارد."
Kubernetes نه تنها ارکستراسیون کانتینر است، بلکه یک سیستم مدیریت پیکربندی با یک API توسعه یافته، یک جزء شبکه، متعادل کننده L3 و کنترل کننده های ورودی است که مدیریت منابع، مقیاس و انتزاع از لایه های زیرین زیرساخت را نسبتاً آسان می کند.
متأسفانه، در زندگی ما باید برای همه چیز هزینه کنیم. و این مالیات بزرگ است، به خصوص اگر همانطور که ایوان کروگلوف معتقد است، در مورد انتقال به Kubernetes یک شرکت با زیرساخت توسعه یافته صحبت کنیم. او می توانست آزادانه هم در شرکتی با زیرساخت سنتی و هم با کوبر کار کند. نکته اصلی درک ویژگی های شرکت و بازار است. اما، برای مثال، برای اوگنی پوتاپوف، که کوبرنتس را به هر ابزار ارکستراسیون کانتینری تعمیم می دهد، چنین سوالی مطرح نمی شود.
Evgeniy قیاسی با وضعیت دهه 1990 ترسیم کرد، زمانی که برنامه نویسی شی گرا به عنوان راهی برای برنامه نویسی برنامه های کاربردی پیچیده ظاهر شد. در آن زمان، بحث ادامه یافت و ابزارهای جدیدی برای پشتیبانی از OOP ظاهر شدند. سپس میکروسرویس ها به عنوان راهی برای دور شدن از مفهوم یکپارچه ظاهر شدند. این به نوبه خود منجر به ظهور کانتینرها و ابزارهای مدیریت کانتینر شد. او معتقد است: "من فکر می کنم به زودی به زمانی خواهیم رسید که هیچ سوالی در مورد ارزش نوشتن یک برنامه میکروسرویس کوچک وجود نداشته باشد، به طور پیش فرض به عنوان یک میکروسرویس نوشته می شود." به همین ترتیب، Docker و Kubernetes در نهایت بدون نیاز به انتخاب به راه حل استاندارد تبدیل خواهند شد.
مشکل پایگاه های داده در افراد بدون تابعیت
عکس
امروزه دستور العمل های زیادی برای اجرای پایگاه های داده در Kubernetes وجود دارد. حتی نحوه جداسازی بخشی که با دیسک ورودی/خروجی کار می‌کند، به صورت مشروط، از بخش کاربردی پایگاه داده. آیا ممکن است در آینده بانک های اطلاعاتی آنقدر تغییر کنند که در یک جعبه تحویل داده شوند که یک قسمت از طریق داکر و کوبرنتس تنظیم شود و در قسمت دیگر زیرساخت از طریق نرم افزار جداگانه قسمت ذخیره سازی ارائه شود. ? آیا پایه ها به عنوان یک محصول تغییر می کنند؟
آندری معتقد است که این توصیف مشابه مدیریت صف است، اما الزامات برای قابلیت اطمینان و هماهنگ سازی اطلاعات در پایگاه های داده سنتی بسیار بالاتر است. نسبت ضربه کش در پایگاه داده های معمولی 99 درصد باقی می ماند. اگر یک کارگر پایین بیاید، یک مورد جدید راه اندازی می شود و حافظه پنهان از ابتدا "گرم می شود". تا زمانی که حافظه پنهان گرم نشود، کارگر به کندی کار می کند، به این معنی که نمی توان آن را با بار کاربر بارگیری کرد. در حالی که بار کاربر وجود ندارد، حافظه پنهان گرم نمی شود. این یک دور باطل است.
دیمیتری اساساً مخالف است - حد نصاب ها و اشتراک گذاری مشکل را حل می کند. اما آندری اصرار دارد که راه حل برای همه مناسب نیست. در برخی شرایط، حد نصاب مناسب است، اما بار اضافی را بر روی شبکه وارد می کند. پایگاه داده NoSQL در همه موارد مناسب نیست.
شرکت کنندگان در جلسه به دو کمپ تقسیم شدند.
دنیس و آندری استدلال می کنند که هر چیزی که روی دیسک نوشته می شود - پایگاه داده ها و غیره - در اکوسیستم فعلی کوبر غیرممکن است. حفظ یکپارچگی و سازگاری داده های تولید در Kubernetes غیرممکن است. این یک ویژگی اساسی است. راه حل: زیرساخت های ترکیبی.
حتی پایگاه‌های داده بومی ابری مدرن مانند MongoDB و Cassandra یا صف‌های پیام مانند Kafka یا RabbitMQ به ذخیره‌سازی داده‌های دائمی خارج از Kubernetes نیاز دارند.
اوگنی مخالفت می‌کند: «پایگاه‌های کوبرا یک آسیب نزدیک به روسیه یا نزدیک به سازمان هستند، که با این واقعیت مرتبط است که در روسیه پذیرش ابری وجود ندارد.» شرکت های کوچک یا متوسط در غرب Cloud هستند. استفاده از پایگاه داده‌های RDS آمازون آسان‌تر از دستکاری با Kubernetes است. در روسیه آنها از کوبر "در محل" استفاده می کنند و زمانی که می خواهند از باغ وحش خلاص شوند، پایگاه ها را به آن منتقل می کنند.
دیمیتری همچنین با این بیانیه که هیچ پایگاه داده ای را نمی توان در Kubernetes نگهداری کرد، مخالف بود: "پایه با پایگاه متفاوت است. و اگر یک پایگاه داده رابطه ای غول پیکر را فشار دهید، تحت هیچ شرایطی. اگر چیزی کوچک و ابری را فشار دهید که از نظر ذهنی برای زندگی نیمه زودگذر آماده است، همه چیز خوب خواهد بود. دیمیتری همچنین اشاره کرد که ابزارهای مدیریت پایگاه داده برای Docker یا Kuber آماده نیستند، بنابراین مشکلات بزرگی ایجاد می شود.
ایوان به نوبه خود مطمئن است که حتی اگر از مفاهیم دولتی و بدون دولت انتزاع بگیریم، اکوسیستم راه حل های سازمانی در Kubernetes هنوز آماده نیست. با کوبر، حفظ الزامات قانونی و نظارتی دشوار است. به عنوان مثال، ایجاد یک راه حل ارائه هویت در جایی که ضمانت های شناسایی دقیق سرور مورد نیاز است، دقیقاً تا سخت افزاری که در سرورها قرار داده می شود، غیرممکن است. این منطقه در حال توسعه است، اما هنوز راه حلی وجود ندارد.
شرکت کنندگان نتوانستند به توافق برسند، بنابراین هیچ نتیجه ای در این بخش گرفته نخواهد شد. بیایید چند مثال کاربردی بزنیم.
مورد 1. امنیت سایبری یک "مگا تنظیم کننده" با پایگاه های خارج از Kubera
در مورد یک سیستم امنیت سایبری توسعه یافته، استفاده از کانتینرها و ارکستراسیون، مبارزه با حملات و نفوذها را ممکن می سازد. به عنوان مثال، در یک رگولاتور بزرگ، دنیس و تیمش ترکیبی از یک ارکستراتور را با یک سرویس SIEM آموزش دیده اجرا کردند که لاگ ها را در زمان واقعی تجزیه و تحلیل می کند و روند حمله، هک یا شکست را تعیین می کند. در صورت حمله، تلاش برای قرار دادن چیزی، یا در صورت تهاجم ویروس باج‌افزار، از طریق ارکستراتور، کانتینرهای دارای برنامه‌ها را سریع‌تر از آلوده شدن یا سریع‌تر از حمله مهاجم به آنها برمی‌دارد.
مورد 2. انتقال جزئی پایگاه های داده Booking.com به Kubernetes
در Booking.com، پایگاه داده اصلی MySQL با تکرار ناهمزمان است - یک استاد و یک سلسله مراتب کامل از بردگان وجود دارد. زمانی که ایوان شرکت را ترک کرد، پروژه ای برای انتقال بردگانی راه اندازی شد که می توانستند با آسیب خاصی "شلیک" شوند.
علاوه بر پایه اصلی، یک چیدمان کاساندرا با ارکستراسیون خودنویس وجود دارد که حتی قبل از ورود کوبر به جریان اصلی نوشته شده است. هیچ مشکلی در این زمینه وجود ندارد، اما روی SSD های محلی پایدار است. ذخیره سازی از راه دور، حتی در همان مرکز داده، به دلیل مشکل تأخیر بالا استفاده نمی شود.
دسته سوم پایگاه های داده سرویس جستجوی Booking.com است که هر گره سرویس یک پایگاه داده است. تلاش برای انتقال سرویس جستجو به Kuber ناموفق بود، زیرا هر گره دارای 60-80 گیگابایت فضای ذخیره سازی محلی است که "بلند کردن" و "گرم کردن" آن دشوار است.
در نتیجه، موتور جستجو به Kubernetes منتقل نشد و ایوان فکر نمی کند که در آینده نزدیک تلاش های جدیدی انجام شود. پایگاه داده MySQL به نصف منتقل شد: فقط Slaves که از "شلیک شدن" نمی ترسند. کاساندرا کاملاً جا افتاده است.
انتخاب زیرساخت به عنوان یک کار بدون راه حل کلی
عکس
فرض کنید یک شرکت جدید داریم یا شرکتی که بخشی از زیرساخت ها به روش قدیمی ساخته شده است. برای سالها یک طرح توسعه زیرساختی ایجاد می کند. تصمیم گیری برای ساخت زیرساخت روی کانتینر و کوبر چگونه است؟
شرکت هایی که برای نانوثانیه ها می جنگند از بحث حذف می شوند. محافظه کاری سالم از نظر قابلیت اطمینان نتیجه می دهد، اما هنوز شرکت هایی هستند که باید رویکردهای جدیدی را در نظر بگیرند.
ایوان: «الان قطعاً شرکتی را در فضای ابری راه‌اندازی می‌کنم، فقط به این دلیل که سریع‌تر است،» اگرچه لزوماً ارزان‌تر نیست. با توسعه سرمایه‌داری خطرپذیر، استارت‌آپ‌ها مشکل بزرگی با پول ندارند و وظیفه اصلی تسخیر بازار است.
ایوان بر این عقیده است که توسعه زیرساخت فعلی یک معیار انتخاب است. اگر در گذشته سرمایه‌گذاری جدی صورت گرفته و کار می‌کند، انجام مجدد آن فایده‌ای ندارد. اگر زیرساخت توسعه نیافته باشد و مشکلاتی در زمینه ابزار، امنیت و نظارت وجود داشته باشد، منطقی است که به زیرساخت های توزیع شده نگاه کنیم.
در هر صورت باید مالیات پرداخت شود و ایوان مالیاتی را که به او اجازه داد در آینده کمتر بپردازد، پرداخت خواهد کرد. "زیرا صرفاً به دلیل این واقعیت که من سوار قطاری هستم که دیگران در حال حرکت آن هستند، بسیار بیشتر از این سفر خواهم کرد که در قطار دیگری بنشینم که باید خودم در آن سوخت بگذارم.ایوان می گوید. وقتی شرکت جدید است، و الزامات تأخیر ده‌ها میلی‌ثانیه است، ایوان به دنبال «اپراتورهایی» است که پایگاه‌های داده کلاسیک امروزی در آنها «پیچیده» شده‌اند. آنها یک زنجیره تکرار را بالا می برند که در صورت شکست و غیره خود را سوئیچ می کند ...
آندری می گوید برای یک شرکت کوچک با چند سرور، Kubera معنی ندارد. اما اگر قصد دارد به صدها سرور یا بیشتر برسد، به اتوماسیون و یک سیستم مدیریت منابع نیاز دارد. 90 درصد موارد ارزش هزینه را دارد. علاوه بر این، صرف نظر از سطح بار و منابع. منطقی است که همه، از استارتاپ ها گرفته تا شرکت های بزرگ با میلیون ها مخاطب، به تدریج به سمت محصولات ارکستراسیون کانتینر نگاه کنند. آندری مطمئن است: "بله، این واقعا آینده است."
دنیس دو معیار اصلی را مشخص کرد - مقیاس پذیری و پایداری عملیات او ابزارهایی را انتخاب می کند که برای این کار مناسب هستند. «این می تواند یک نام بدون نام باشد که روی زانوهای شما مونتاژ شده است، و نسخه انجمن Nutanix را روی آن دارد. این می تواند یک خط دوم به شکل یک برنامه کاربردی در Kuber با یک پایگاه داده در باطن باشد، که تکرار شده و پارامترهای RTO و RPO را مشخص کرده است" (هدف های زمان/نقطه بازیابی - تقریبا).
اوگنی مشکل احتمالی پرسنل را شناسایی کرد. در حال حاضر، متخصصان بسیار ماهر زیادی در بازار وجود ندارند که "جرات" را درک کنند. در واقع، اگر فناوری انتخاب شده قدیمی باشد، استخدام کسی به جز افراد میانسال که از زندگی خسته و بی حوصله هستند دشوار است. اگرچه سایر شرکت کنندگان معتقدند که این موضوع مربوط به آموزش پرسنل است.
اگر سوال انتخابی را مطرح کنیم: راه اندازی یک شرکت کوچک در Public Cloud با پایگاه داده در Amazon RDS یا "در فرض" با پایگاه داده در Kubernetes، با وجود برخی کاستی ها، Amazon RDS به انتخاب شرکت کنندگان تبدیل شد.
از آنجایی که اکثر شنوندگان ملاقات از شرکت "خونین" نیستند، پس راه حل های توزیع شده چیزی است که ما باید برای آن تلاش کنیم. سیستم‌های ذخیره‌سازی داده‌ها باید توزیع شده، قابل اعتماد باشند و تأخیر ایجاد کنند که در واحدهای میلی‌ثانیه و حداکثر ده‌ها اندازه‌گیری می‌شود.آندری خلاصه کرد.
ارزیابی استفاده از Kubernetes
شنونده آنتون ژبانکوف یک سوال تله ای از معذرت خواهان Kubernetes پرسید: چگونه یک مطالعه امکان سنجی را انتخاب و انجام دادید؟ چرا Kubernetes، چرا ماشین های مجازی، مثلا نه؟
عکس
دیمیتری و ایوان به آن پاسخ دادند. در هر دو مورد، از طریق آزمون و خطا، دنباله ای از تصمیمات گرفته شد که در نتیجه هر دو شرکت کننده به Kubernetes رسیدند. اکنون کسب‌وکارها شروع به توسعه مستقل نرم‌افزاری کرده‌اند که انتقال آن به Kuber منطقی است. ما در مورد سیستم های شخص ثالث کلاسیک مانند 1C صحبت نمی کنیم. Kubernetes در مواقعی که توسعه دهندگان نیاز به انتشار سریع دارند، با بهبود مستمر بدون وقفه کمک می کند.
تیم آندری تلاش کرد تا یک خوشه مقیاس پذیر بر اساس ماشین های مجازی ایجاد کند. گره ها مانند دومینو سقوط می کردند که گاهی منجر به فروپاشی خوشه می شد. از نظر تئوری، شما می توانید آن را تمام کنید و با دستان خود از آن حمایت کنید، اما خسته کننده است. و اگر راه حلی در بازار وجود دارد که به شما امکان می دهد خارج از جعبه کار کنید، ما خوشحالیم که آن را دنبال می کنیم. آندری می گوید و در نتیجه تغییر کردیم.
استانداردهایی برای چنین تجزیه و تحلیل و محاسباتی وجود دارد، اما هیچ کس نمی تواند بگوید که آنها در سخت افزار واقعی در حال کار چقدر دقیق هستند. برای محاسبات، درک هر ابزار و اکوسیستم نیز مهم است، اما این امکان پذیر نیست.
آنچه در انتظار ماست
عکس
همانطور که تکنولوژی تکامل می‌یابد، قطعات ناهمگون بیشتر و بیشتر ظاهر می‌شوند، و سپس یک انتقال فاز اتفاق می‌افتد، فروشنده‌ای ظاهر می‌شود که به اندازه کافی خمیر را کشته است تا همه چیز در یک ابزار واحد جمع شود.
آیا فکر می کنید زمانی فرا می رسد که ابزاری مانند اوبونتو برای دنیای لینوکس وجود خواهد داشت؟ شاید یک ابزار منفرد و ارکستراسیون شامل Kuber باشد. ساخت ابرهای داخلی را آسان می کند.
پاسخ توسط ایوان داده شد: "Google اکنون در حال ساخت Anthos است - این پیشنهاد بسته بندی شده آنها است که ابر را مستقر می کند و شامل Kuber، Service Mesh، نظارت است - تمام سخت افزارهای مورد نیاز برای میکروسرویس های داخلی." ما تقریباً در آینده هستیم."
دنیس همچنین به Nutanix و VMWare با محصول vRealize Suite اشاره کرد که می‌توانند با کار مشابه بدون کانتینری‌سازی کنار بیایند.
دیمیتری عقیده خود را به اشتراک گذاشت که کاهش "درد" و کاهش مالیات دو حوزه ای هستند که می توانیم انتظار پیشرفت را داشته باشیم.
برای خلاصه کردن بحث، مشکلات زیر زیرساخت مدرن را برجسته می کنیم:
- سه شرکت‌کننده فوراً مشکلی را با حالت حالت شناسایی کردند.
- مشکلات مختلف پشتیبانی امنیتی، از جمله احتمال اینکه Docker به نسخه‌های متعدد پایتون، سرورهای برنامه و مؤلفه‌ها ختم شود.
مازاد بر خرج کردن که بهتر است در یک جلسه جداگانه در مورد آن صحبت شود.
چالش یادگیری به عنوان ارکستراسیون یک اکوسیستم پیچیده است.
یک مشکل رایج در صنعت استفاده نادرست از ابزار است.بقیه نتیجه گیری به عهده شماست. هنوز این احساس وجود دارد که تبدیل شدن به بخش "مرکزی" سیستم برای ترکیب Docker+Kubernetes آسان نیست. به عنوان مثال، سیستم عامل ها ابتدا روی سخت افزار نصب می شوند که در مورد کانتینرها و ارکستراسیون نمی توان گفت. شاید در آینده سیستم عامل ها و کانتینرها با نرم افزار مدیریت ابری ادغام شوند.
عکسمن می خواهم از این فرصت استفاده کنم و به مادرم سلام کنم و یادآوری کنم که ما یک گروه فیس بوک داریم ، کانال با انتشارات جالب از وبلاگ های فناوری مختلف. و کانال من ، جایی که من در مورد مدیریت توسعه در شرکت های محصول صحبت می کنم.
منبع: www.habr.com