Kubernetes یک مشکل بهینه سازی هزینه (نه) است

به نظر می رسد همه موافق هستند که Kubernetes برای اجرا بسیار گران است. مشکل در نحوه ساخت اپلیکیشن هاست.

• چرا Kubernetes اینقدر هزینه دارد
• هزینه قابلیت اطمینان کانتینر
• کارهای جانبی مصرف کنندگان منابع هستند
• «کنترل هزینه» نباید فقط یک افزونه باشد< /li>
• کارکرد کانتینرها گران است
• بدون سرور و WebAssembly پاسخی ارائه می دهند
• ذخیره با Kubernetes

Kubernetes تبدیل به روشی واقعی برای زمان‌بندی و مدیریت خدمات در شرکت‌های متوسط ​​و بزرگ شده است. همراه با الگوی طراحی microservice، ثابت کرده است که ابزار مفیدی برای مدیریت همه چیز از وب‌سایت‌ها گرفته تا خطوط لوله پردازش داده است. اما اکوسیستم در کل موافق است که Kubernetes مشکل هزینه دارد. متأسفانه، روش غالب برای کاهش هزینه ها خود یک تعهد است.

مشکل Kubernetes نیست. مشکل در نحوه ساخت برنامه هاست.

چرا Kubernetes اینقدر هزینه دارد

من از همان روزهای اولیه در اطراف جامعه Kubernetes بودم و یکی از مزایای اولیه Kubernetes صرفه جویی در هزینه بود. ما معتقد بودیم که در حال ساختن سیستمی هستیم که با کاهش تعداد ماشین‌های مجازی مورد استفاده به مدیریت هزینه کمک می‌کند. ما قطعاً در این فرض درست بودیم … اما به طور بالقوه نادرست بودیم که این امر در دراز مدت منجر به صرفه جویی در هزینه می شود. در واقع، نگرش غالب این روزها این است که اجرای Kubernetes در واقع بسیار گران است.

مشکلی پیش آمد؟

پاسخ کوتاه این است که، نه، هیچ مشکلی پیش نیامده است. در واقع، روش Kubernetes برای دیدن جهان آنقدر موفق بوده است که طرز فکر ما را در مورد استقرار و نگهداری برنامه ها تغییر داده است. و خود Kubernetes بسیار پیچیده تر از آن روزهای اولیه شد. به همین ترتیب، الگوی طراحی میکروسرویس به طور گسترده ای به کار گرفته شد – به طوری که بیشتر اوقات ما حتی به این واقعیت فکر نمی کنیم که اکنون به جای برنامه های فوق العاده یکپارچه که قبل از کانتینرها محبوب بودند، سرویس های کوچک را به طور پیش فرض می نویسیم.

منصفانه است که بگوییم صرفه جویی در هزینه همیشه یک “مزای جانبی” Kubernetes بود، نه یک هدف طراحی. اگر این روایت از بین رفت، به این دلیل نیست که کوبرنتیس یک هدف را رها کرده است. دلیلش این است که با تکامل و بلوغ کامل مدل پشت کوبرنتس، ثابت شد که درست نیست.

این جایی است که می‌توانیم درباره چرا Kubernetes از «ارزان‌تر» به «بسیار گران‌تر» تبدیل شد، صحبت کنیم.

Kubernetes ارزان‌تر از اجرای سیستمی در نظر گرفته می‌شد که در آن هر میکروسرویس با VM خود کار می‌کرد. و شاید با توجه به اقتصاد آن زمان، چنین بود. اما این نوع تنظیم دیگر مقایسه مفیدی نیست. زیرا Kubernetes پلتفرم‌ها را سیستماتیک کرده است و این امر اقتصاد رایانش ابری را تغییر می‌دهد.

هزینه قابلیت اطمینان کانتینر

در اوایل، Kubernetes ایده Replication Controller را معرفی کرد که بعداً به Deployments و ReplicaSets تبدیل شد. همه این انتزاع‌ها برای رسیدگی به کمبود کانتینرها و ماشین‌های مجازی طراحی شده‌اند: کانتینرها و ماشین‌های مجازی دیر شروع می‌شوند. و این باعث می‌شود که آنها در طول سناریوهای شکست (زمانی که یک گره از بین می‌رود) یا رویدادهای افزایش‌یافته (زمانی که ترافیک آنقدر بالا می‌رود که نمونه‌های فعلی نتوانند بار را مدیریت کنند) بدهی داشته باشند.

روزی روزگاری، در روزهای قبل از Kubernetes، ما این کار را با از قبل ارائه سرورها یا ماشین‌های مجازی و سپس چرخاندن آن‌ها در داخل و خارج از تولید انجام می‌دادیم. تکرار Kubernetes این امکان را فراهم کرد که به راحتی اعلام کنیم “I need three instance” یا “I need five instance”، و هواپیمای کنترل Kubernetes همه اینها را به طور خودکار مدیریت می کند – آنها را سالم نگه می دارد، پس از شکست بهبود می یابد، و به خوبی استقرارها را مدیریت می کند. p>

اما این اولین جایی است که Kubernetes شروع به گران شدن کرد. برای مدیریت مقیاس‌بندی و شکست، Kubernetes N نمونه‌های یک برنامه را اجرا کرد، که در آن N حداقل سه، اما اغلب پنج یا بیشتر است. و یک جنبه کلیدی این تکرار این است که برنامه ها باید در چندین گره خوشه پخش شوند. این به این دلیل است که:

• اگر یک گره بمیرد، راه‌اندازی مجدد شود یا دیگر پاسخ ندهد، هر کانتینری که در آن گره برنامه‌ریزی شده است در دسترس نخواهد بود. بنابراین Kubernetes ترافیک را به نمونه های کانتینری در گره های دیگر هدایت می کند.
• با افزایش ترافیک، بار (تا حدودی) به طور مساوی بین تمام نمونه های در حال اجرا توزیع می شود. بنابراین هیچ کانتینری نباید زیر بار کمانش کند در حالی که دیگران بیکار بنشینند.

این به این معنی است که در هر زمان، شما برای اجرای سه، پنج یا چند نمونه از برنامه خود هزینه پرداخت می کنید. حتی اگر بار واقعاً کم باشد و خرابی ها نادر باشد، باید برای افزایش ناگهانی ترافیک یا قطعی غیرمنتظره آماده باشید. و این بدان معنی است که همیشه ظرفیت اضافی را آنلاین نگه دارید. به این overprovisioning می‌گویند.

Autoscalers که کمی بعد در وجود Kubernetes معرفی شدند، وضعیت را بهبود بخشیدند. مقیاس‌کننده‌های خودکار مواردی مانند افزایش استفاده از شبکه یا CPU را دنبال می‌کنند و به‌طور خودکار ظرفیت را افزایش می‌دهند. یک Autoscaler Horizontal Pod (محبوب‌ترین مقیاس‌کننده خودکار Kubernetes) به سادگی نسخه‌های بیشتری از برنامه شما را با بالا رفتن بار شروع می‌کند.

با این حال، از آنجایی که کانتینرها دیر شروع می‌شوند (ثانیه یا دقیقه طول می‌کشد) و از آنجا که بار به طور طبیعی غیرقابل پیش‌بینی است، مقیاس‌کننده‌های خودکار باید نسبتاً زود فعال شوند و ظرفیت اضافی را نسبتاً دیر خاتمه دهند. آیا آنها صرفه جویی در هزینه هستند؟ اغلب بله. آیا آنها نوشدارویی هستند؟ خیر. همانطور که نمودار بالا نشان می‌دهد، حتی زمانی که مقیاس‌کننده‌های خودکار افزایش ترافیک را پیش‌بینی می‌کنند، هدر رفت هم هنگام راه‌اندازی و هم پس از کاهش بار رخ می‌دهد.

کارهای جانبی مصرف کنندگان منابع هستند

اما کپی‌ها تنها چیزی نیستند که Kubernetes را گران می‌کنند. الگوی ماشین کناری نیز در این امر نقش دارد. یک غلاف ممکن است چندین کانتینر در حال اجرا داشته باشد. به طور معمول، یکی برنامه اصلی است، و ظروف دیگر کمکی هستند. یک میکروسرویس ممکن است برای سرویس‌های داده، برای جمع‌آوری معیارها، مقیاس‌گذاری و غیره دارای فرعی جداگانه باشد. و هر یک از این سایدکارها به حافظه، CPU، فضای ذخیره سازی و غیره خاص خود نیاز دارند.

باز هم، ما نباید لزوماً به این موضوع به عنوان چیزی بد نگاه کنیم. این نوع پیکربندی نشان می دهد که Kubernetes چقدر قدرتمند است. یک پاکت عملیاتی کامل را می توان به شکل سایدکار دور یک برنامه پیچیده کرد. اما شایان ذکر است که در حال حاضر یک میکروسرویس می‌تواند چهار یا پنج سایدکار داشته باشد، به این معنی که وقتی شما پنج نسخه مشابه را اجرا می‌کنید، اکنون حدود ۲۵ یا ۳۰ کانتینر را اجرا می‌کنید.

این باعث می‌شود که مهندسان پلتفرم نه تنها به کوچک‌سازی خوشه‌های خود (افزودن گره‌های بیشتر)، بلکه به افزایش ظرفیت حافظه و CPU گره‌های موجود نیاز داشته باشند.

«کنترل هزینه» نباید فقط یک افزونه باشد

وقتی ابر برای اولین بار جای خود را پیدا کرد، اقتصاد جهان به خوبی در مسیر بهبود از رکود ۲۰۰۷ بود. در سال ۲۰۱۵، زمانی که Kubernetes به وجود آمد، فناوری در یک دوره رونق بود. تا اواخر سال ۲۰۲۲ بود که فشارهای اقتصادی واقعاً شروع به کاهش هزینه ابر کرد. Cloud در زمانی بالغ شد که بهینه سازی هزینه اولویت بالایی نداشت.

تا سال ۲۰۲۲، الگوهای فعلی طراحی ابری ما مستحکم شده بود. ما “گران” را به نفع “محکم” و “تحمل خطا” پذیرفته بودیم. سپس اقتصاد دچار افت شد. و زمان آن فرا رسیده بود که الگوهای مخارج ابری خود را تنظیم کنیم.

جای تعجب نیست که یک صنعت حول این مشکل تکامل یافته است. حداقل ده ها ابزار بهینه سازی هزینه برای Kubernetes وجود دارد. و آنها از این ایده حمایت می کنند که هزینه را می توان با (الف) حقوق دادن به خوشه، و (ب) خرید محاسبات ارزان در صورت امکان کنترل کرد.

یک قیاس مناسب ممکن است خودروی پر از بنزین باشد. برای کنترل هزینه، ممکن است (الف) باک را فقط تا نیمه پر کنیم و بدانیم که در حال حاضر به باک پر نیاز نداریم و (ب) هر زمان که قیمت پمپ بنزین را به اندازه کافی پایین می بینیم، بنزین ارزان تر بخریم.

من پیشنهاد نمی‌کنم که این یک استراتژی بد برای “ماشین” امروزی است. اگر ابر در زمان فشار اقتصادی بیشتر رشد می‌کرد، کوبرنتس احتمالاً این ویژگی‌ها را در هسته هواپیمای کنترلی قرار می‌داد، همانطور که خودروهای بنزینی امروزی نسبت به خودروهایی که در زمان پایین بودن قیمت بنزین ساخته می‌شوند، مصرف سوخت بیشتری دارند.

اما برای گسترش استعاره، شاید بهترین راه حل تغییر از یک موتور بنزینی به یک EV باشد. در مورد Kubernetes، این به صورت تغییر از یک زمان اجرا کاملاً مبتنی بر کانتینر به استفاده از چیز دیگری ظاهر می‌شود.

کارکرد کانتینرها گران است

ما بسیاری از زیرساخت‌های خود را بر روی کانتینرها ساخته‌ایم، و خود کانتینرها برای کارکردن گران هستند. سه عامل ترکیبی وجود دارد که آن را چنین می کند:

1. کانتینرها دیر شروع می شوند.
2. کانتینرها همیشه منابع را مصرف می کنند (حتی زمانی که زیر بار نیستند).
3. به عنوان یک قالب، کانتینرها حجیم‌تر از برنامه‌های کاربردی هستند.

آهسته شروع: یک ظرف چندین ثانیه یا شاید یک دقیقه طول می کشد تا کاملاً آنلاین شود. برخی از این موارد سربار زمان اجرا کانتینر سطح پایین است. برخی فقط هزینه راه اندازی و راه اندازی یک سرور طولانی مدت است. اما این به اندازه ای کند است که یک سیستم نتواند به نیازهای مقیاس بندی واکنش نشان دهد. باید فعال باشد. یعنی باید در انتظار بار بزرگ شود، نه در نتیجه بار.

مصرف منابع: از آنجایی که کانتینرها دیر شروع می‌شوند، نسخه‌ای از معماری میکروسرویس که در Kubernetes وجود داشت نشان می‌دهد که هر ظرف مدت زمان طولانی (ساعت‌ها تا چند روز یا چند ساعت) را در خود نگه می‌دارد. حتی ماه ها) سرور نرم افزاری (معروف به دیمون) که به طور مداوم اجرا می شود و چندین درخواست همزمان را مدیریت می کند. در نتیجه، آن سرور طولانی مدت همیشه منابع را مصرف می کند، حتی زمانی که بار را مدیریت نمی کند.

قالب حجیم: به یک معنا، حجیم بودن در چشم بیننده است. مطمئناً یک ظرف در مقایسه با یک تصویر VM چند گیگابایتی کوچک است. اما وقتی میکروسرویس ۲ مگابایتی شما در یک تصویر پایه ۲۵ مگابایتی بسته بندی می شود، آن تصویر هنگام جابجایی، شروع به کار و در حال اجرا هزینه بیشتری را متحمل می شود.

اگر بتوانیم این سه مشکل را کاهش دهیم یا حذف کنیم، می‌توانیم هزینه اجرای Kubernetes را کاهش دهیم. و ما می‌توانیم به سطوح بازدهی برسیم که هیچ پوشش کنترلی هزینه‌ای نمی‌تواند به آن امیدوار باشد.

بدون سرور و WebAssembly پاسخی ارائه می دهند

این جایی است که مفهوم محاسبات بدون سرور مطرح می‌شود. وقتی در مورد محاسبات بدون سرور صحبت می‌کنم، منظورم این است که هیچ سرور نرم‌افزاری (بدون فرآیند دیمون) همیشه در حال اجرا نیست. درعوض، یک برنامه بدون سرور هنگامی که درخواستی وارد می‌شود راه‌اندازی می‌شود و به‌محض رسیدگی به درخواست خاموش می‌شود. گاهی اوقات چنین سیستمی پردازش مبتنی بر رویداد نامیده می‌شود، زیرا یک رویداد (مانند درخواست HTTP) فرآیندی را شروع می‌کند که تنها وظیفه آن مدیریت آن رویداد است.

سیستم‌های موجود که به این صورت (تقریباً) اجرا می‌شوند عبارتند از: AWS Lambda، OpenWhisk، Azure Functions و Google Cloud Functions. هر یک از این سیستم ها نقاط قوت و ضعف خود را دارند، اما هیچکدام به سرعت WebAssembly نیستند و اکثر آنها نمی توانند در داخل Kubernetes اجرا شوند. بیایید نگاهی بیندازیم به آنچه که یک سیستم بدون سرور برای خوب کار کردن و مقرون به صرفه بودن نیاز دارد.

وقتی یک خوشه یک درخواست را برای یک برنامه پردازش می‌کند، چرخه حیات به این شکل است:

• نمونه‌ای از برنامه شروع شده و درخواست داده می‌شود.
• نمونه تا زمانی که پاسخی را برگرداند اجرا می شود.
• نمونه خاموش می شود و منابع آزاد می شوند.

برنامه های بدون سرور طولانی مدت نیستند. همچنین یک برنامه چندین درخواست را در هر نمونه انجام نمی دهد. اگر ۴۳۲۱ درخواست همزمان وارد شود، ۴۳۲۱ نمونه از برنامه ایجاد می شود تا هر نمونه بتواند دقیقاً یک درخواست را انجام دهد. هیچ فرآیندی نباید بیش از چند دقیقه (و در حالت ایده آل کمتر از نیم ثانیه) اجرا شود.

سه مشخصه بسیار مهم می‌شوند:

• سرعت راه اندازی باید مافوق صوت باشد! یک برنامه باید در چند میلی ثانیه یا کمتر شروع شود.
• مصرف منابع باید حداقل باشد. یک برنامه باید از حافظه، CPU، و حتی GPU به مقدار کم استفاده کند و منابع را برای حداقل زمان قفل کند.
• فرمت باینری باید تا حد امکان کوچک باشد. در حالت ایده‌آل، باینری فقط شامل کد برنامه و فایل‌هایی است که مستقیماً به آنها نیاز دارد.

با این حال، سه موردی که برای یک پلتفرم بدون سرور ایده آل باید صادق باشد، نقاط ضعف کانتینرها هستند. ما به قالبی متفاوت از ظرف نیاز داریم.

WebAssembly این نوع نمایه را فراهم می کند. بیایید به یک مثال موجود نگاه کنیم. Spin یک ابزار متن باز برای ایجاد و اجرای برنامه های WebAssembly در بدون سرور (یا رویداد- رانده) سبک. سرما در کمتر از یک میلی‌ثانیه شروع می‌شود (در مقایسه با چند ده ثانیه یا بیشتر که طول می‌کشد تا یک ظرف روشن شود). از حداقل منابع سیستم استفاده می کند، و اغلب می تواند به طور موثری دسترسی به آن منابع را برش زمانی انجام دهد.

به عنوان مثال، Spin فقط زمانی که یک درخواست در حال رسیدگی است، CPU، GPU و حافظه را مصرف می کند. سپس منابع بلافاصله برای استفاده از یک برنامه دیگر آزاد می شوند. و فرمت باینری WebAssembly نرم و فشرده است. یک برنامه ۲ مگابایتی در WebAssembly حدود ۲ مگابایت است. سربار زیادی مانند کانتینرها اضافه نمی شود.

بنابراین می‌توانیم از تکنیکی به نام underprovisioning استفاده کنیم که در آن منابع کمتری را به هر گره نسبت به آنچه برای اجرای همزمان همه برنامه‌ها با ظرفیت کامل نیاز داریم اختصاص می‌دهیم. این کار می کند زیرا ما می دانیم که هرگز اینطور نخواهد بود که همه برنامه ها با ظرفیت کامل اجرا شوند.

این جایی است که ما شروع می کنیم به دیدن اینکه چگونه طراحی بدون سرور به خودی خود ذاتا مقرون به صرفه تر است.

مقیاس‌های ظرفیت را همگام با تقاضا محاسبه کنید، زیرا هر برنامه بدون سرور دقیقاً به موقع برای رسیدگی به یک درخواست فراخوانی می‌شود و سپس فوراً خاموش می‌شود. با استفاده از یک فناوری واقعاً بدون سرور مانند Spin و WebAssembly، می‌توانیم با بهینه‌سازی خودکار تخصیص منابع، پول زیادی در داخل خوشه‌های Kubernetes خود ذخیره کنیم.

دستیابی به این وضعیت با کمی کار همراه است. به جای فرآیندهای دیمون طولانی مدت، باید توابع بدون سرور بنویسیم که هرکدام کار یک میکروسرویس را انجام دهند. یک برنامه بدون سرور (به عنوان مثال یک برنامه Spin) ممکن است چندین عملکرد را پیاده سازی کند که هر تابع یک WebAssembly باینری است. یعنی ممکن است در واقع خدمات کوچکتری نسبت به معماری میکروسرویس داشته باشیم. اما این باعث می‌شود که اجرا کردن آن‌ها حتی ارزان‌تر و حتی نگهداری آسان‌تر باشد!

استفاده از این الگو سریع‌ترین مسیر برای به حداکثر رساندن کارایی خوشه‌تان و در عین حال به حداقل رساندن هزینه است.

ذخیره با Kubernetes

برخی از بارهای کاری ابری وجود دارند که برای بدون سرور مناسب نیستند. به طور معمول، پایگاه های داده در کانتینرها بهتر کار می کنند. آنها در فرآیندهای طولانی مدت که در آن داده ها می توانند در حافظه پنهان شوند، کارآمدتر عمل می کنند. شروع و توقف یک پایگاه داده برای هر درخواست می تواند جریمه های عملکرد سختی را در پی داشته باشد. سرویس‌هایی مانند Redis (صف‌های pub/sub و ذخیره‌سازی کلید/مقدار) نیز در فرآیندهای طولانی‌مدت بهتر مدیریت می‌شوند.

اما برنامه‌های کاربردی وب، خطوط لوله پردازش داده، سرویس‌های REST، ربات‌های چت، وب‌سایت‌ها، سیستم‌های CMS و حتی استنتاج هوش مصنوعی برای ایجاد و عملکرد به عنوان برنامه‌های بدون سرور ارزان‌تر هستند. بنابراین، اجرای آنها در داخل Kubernetes با Spin باعث صرفه جویی در دراز مدت می شود.

WebAssembly جایگزینی برای کانتینرها ارائه می دهد که به همان سطوح از قابلیت اطمینان و استحکام دست می یابد، اما با کسری از هزینه. با استفاده از یک الگوی برنامه کاربردی بدون سرور، می‌توانیم منابع خوشه‌ای را کم‌تأمین کنیم، و آخرین قطره‌های کارایی را از گره‌های Kubernetes خارج کنیم.

مت قصاب یکی از بنیانگذاران و مدیرعامل Fermyon، WebAssembly بدون سرور در شرکت ابری. او یکی از سازندگان اصلی Helm، Brigade، CNAB، OAM، Glide و Krustlet است. او کتاب‌های بسیاری از جمله «هدف یادگیری» و «به تمرین برو». او یکی از خالقان مجموعه «راهنمای مصور کودکان برای مجموعه Kubernetes» است. این روزها او بیشتر روی پروژه های WebAssembly مانند Spin، Fermyon Cloud و Bartholomew کار می کند. او دارای مدرک دکتری است. در فلسفه او در کلرادو زندگی می‌کند، جایی که مقدار زیادی قهوه می‌نوشد.

—

انجمن فناوری جدید مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.