وقتی صحبت از اجرای اپلیکیشن‌های امروزی می‌شود، کوبرنتیز در حال تبدیل شدن به استانداردی طلایی است. با این حال، در سال‌های اخیر، شرکت‌هایی به دلیل پیچیدگی و چالش‌هایی که کوبرنتیز ایجاد می‌کند، تصمیم گرفته‌اند از آن فاصله بگیرند.
در این مطلب، می‌خواهم سه داستان از این دست را به اشتراک بگذارم. یادگیری از تجربیات دیگران راهی عالی برای جلوگیری از اشتباهات بزرگ در مدیریت زیرساخت است.
نگاهی به چنین تجربیاتی می‌تواند به شما در انتخاب‌های طراحی بهتر هنگام کار با کوبرنتیز کمک کند.
۱. داستان گیت‌پاد (Gitpod )
گیت‌پاد (Gitpod ) یک محیط توسعه مبتنی بر ابر است که فضاهای کاری از پیش پیکربندی شده و آماده کدنویسی را برای توسعه‌دهندگان فراهم می‌کند و به کاربران اجازه می‌دهد تا در عرض چند ثانیه یک محیط توسعه راه‌اندازی کنند.
گیت‌پاد با کوبرنتیز به عنوان ستون فقرات محیط‌های توسعه مبتنی بر ابر خود شروع به کار کرد.
مانند بسیاری دیگر، آنها معتقد بودند که مقیاس‌پذیری، اتوماسیون و ارکستراسیون کوبرنتیز برای مدیریت روزانه هزاران محیط توسعه عالی خواهد بود.
اما همان طور که رشد کردند، با چالش‌های غیرمنتظره‌ای روبرو شدند. آنها با نیازهای منحصر به فرد محیط‌های توسعه، که بسیار حالت‌پذیر (stateful) و تعاملی (interactive) هستند، دست و پنجه نرم می‌کردند.
اینجا جایی است که همه چیز شروع به خراب شدن کرد:
- انفجار CPU – توسعه‌دهندگان به قدرت پردازش فوری نیاز دارند، اما زمان‌بندی کوبرنتیز (Kubernetes scheduling) به اندازه کافی سریع نبود و باعث تاخیرهای ناامیدکننده می‌شد.
- مدیریت حافظه – رم گران است، بنابراین آنها سعی کردند آن را بیش از حد رزرو کنند (k8s این امکان را از طریق درخواست‌ها و محدودیت‌ها فراهم می‌کند. اما بدون فضای swap مناسب، Kubernetes وقتی حافظه تمام می‌شد، فرآیندها را از بین می‌برد. – قاتل OOM (حافظه تمام شده).
- عملکرد ذخیره‌سازی – SSD های سریع عملکرد را بهبود می‌بخشیدند، اما به گره‌های خاصی وابسته بودند. ذخیره‌سازی پایدار (PVCs) باید کمک می‌کرد، اما کند و غیرقابل اعتماد بود.
- امنیت و ایزولاسیون – توسعه‌دهندگان برای نصب بسته‌ها و پیکربندی محیط‌های خود به دسترسی root-likeنیاز داشتند، اما این با مدل امنیتی سختگیرانه Kubernetes در تضاد بود.
- پیچیدگی شبکه – هر محیط باید برای امنیت ایزوله می‌شد، اما همچنین به دسترسی انعطاف‌پذیر برای توسعه‌دهندگان نیاز داشت.
بنابراین آنها Gitpod Flex، یک صفحه کنترل الهام گرفته از Kubernetes اما ساده شده را ساختند.
این برنامه اکثر مشکلات را با موارد زیر حل می‌کند:
- حذف سربار (overhead ) کوبرنتیز در حالی که API های اعلانی را حفظ می‌کند.
- ارائه امنیت، عملکرد و سهولت استقرار بهتر.
- پشتیبانی از self-hosting در کمتر از ۳ دقیقه با انطباق بهتر.
نکته کلیدی: کوبرنتیز برای حجم کاری پروداکشن عالی است، اما همیشه بهترین گزینه برای محیط‌های توسعه‌دهنده نیست. گیت‌پاد این را به سختی آموخت و یک جایگزین کم‌حجم‌تر و کارآمدتر ساخت.
۲. داستان جاست‌پی (Juspay)
Juspay یک backend پردازش پرداخت به نام Hyperswitch دارد.
برای Hyperswitch، Kafka نقش مهمی در جریان‌سازی رویدادها ایفا می‌کند و جریان روان داده‌ها بین سرورهای برنامه و فضای ذخیره‌سازی را تضمین می‌کند.
در ابتدا، Kubernetes انتخاب اصلی برای هماهنگی کانتینرها بود و محیطی مدیریت‌شده برای مقیاس‌بندی گره‌های Kafka فراهم می‌کرد.
با این حال، با افزایش حجم کار، چندین چالش غیرمنتظره پیش آمد که Kafka را روی کوبرنتیز ناکارآمد و پرهزینه کرد.
در ادامه سه نکته‌ی مشکل‌ساز آمده است.
- ناکارآمدی تخصیص منابع: مدیریت منابع Kubernetes اغلب منابع کافی را در اختیار ندارد و منجر به هدر رفتن CPU و حافظه می‌شود. در مقیاس بزرگ، این امر منجر به هزینه‌های بسیار بالاتر از حد انتظار می‌شود.
- مشکلات مقیاس‌پذیری خودکار: کافکا stateful است، اما مقیاس‌پذیری خودکار Kubernetes برای برنامه‌های stateless طراحی شده است. این امر منجر به تاخیر ۱۵ ثانیه‌ای در پردازش پیام و افزایش تاخیر در هنگام افزایش مقیاس شد.
- پیچیدگی عملیاتی با Strimzi: مدیریت کلاسترهای کافکا با Strimzi (اپراتور اجرای آپاچی کافکا روی k8s) به یک فرآیند دستی و مستعد خطا تبدیل شد. اضافه کردن گره‌های جدید اغلب با شکست مواجه می‌شد و نیاز به مداخلات مکرر داشت.
برای کاهش هزینه‌ها و بهبود عملکرد کافکا، Hyperswitch از کوبرنتیز به EC2 مهاجرت کرد.
نتایج به شرح زیر است:
- ۲۸٪ کاهش هزینه، از ۱۸۰ دلار در ماه به ازای هر نمونه در کوبرنتیز به ۱۳۰ دلار در ماه در EC2.
- مقیاس‌پذیری عمودی آسان، ارتقاء از نمونه‌های کلاس T به کلاس C بدون اختلال.
- کنترل بیشتر بر عملکرد، تضمین عملیات پایدار در بارهای اوج.
نکته کلیدی: همه حجم‌های کاری برای کوبرنتیز ایده‌آل نیستند.در حالی که کوبرنتیز در برنامه‌های stateless و بسیار پویا عالی عمل می‌کند، سیستم‌های stateful مانند کافکا اغلب به کنترل بیشتری بر منابع و مقیاس‌پذیری نیاز دارند.
۳. داستان Threekit
Threekit یک پلتفرم تجسم سه‌بعدی و واقعیت افزوده (AR) در سطح سازمانی است که به کسب‌وکارها امکان می‌دهد تجربیات تعاملی برای تجارت الکترونیک، خرده‌فروشی و غیره ایجاد کنند.
در سال ۲۰۱۸، تیم Threekit به دنبال یک راه‌حل محاسباتی کاملا مدیریت‌شده بود.
این سیستم برای مدیریت کارآمد rendering در مقیاس بزرگ، تبدیل داده‌ها و تولید محتوا، به پردازش دسته‌ای (batch processing) نیاز داشت.
کوبرنتیز به تازگی به عنوان استاندارد صنعت ظهور کرده و در آن زمان به انتخاب واضح تبدیل شده بود.
کوبرنتیز خیلی زود موارد زیر را آشکار کرد.
- هزینه‌های بالا: اجرای یک کلاستر به دلیل مقیاس‌پذیری خودکار آهسته، نیاز به گره‌های مدیریتی اضافی و تامین بیش از حد داشت که منجر به اتلاف منابع می‌شد.
- مشکلات مقیاس‌پذیری: مدیریت حجم بالای کار چالش برانگیز بود و راه‌حل‌هایی مانند ArgoCD پیچیدگی بیشتری ایجاد می‌کردند.
- سربار عملیاتی: حتی وظایف ساده نیز به تخصص عمیق کوبرنتیز نیاز داشتند و بار DevOps را افزایش می‌دادند. نگهداری از کلاستر نیازمند مهندسان اختصاصی کوبرنتیز بود.
- تله Lock-In: کلاسترهای کوبرنتیز وابستگی‌هایی ایجاد می‌کردند که ادغام منابع خارجی یا مهاجرت به یک مجموعه متفاوت را دشوار می‌کرد.
در حالی که کوبرنتیز مشکلات مدیریت سخت‌افزار را حل می‌کرد، اما زیرساخت‌ها را پیچیده‌تر و نگهداری آنها را پرهزینه‌تر می‌کرد.
برای کاهش پیچیدگی، آنها Google Cloud Run را به کار گرفتند.
- Cloud Run به صفر می‌رسد، به این معنی که هزینه‌ها فقط بر اساس میزان استفاده واقعی محاسبه می‌شوند، برخلاف Kubernetes که نیاز به پرداخت هزینه برای منابع بیکار داشت.
- در حالی که مقیاس‌پذیری Kubernetes چند دقیقه طول می‌کشید، Cloud Run در عرض چند ثانیه مقیاس‌پذیر می‌شود و مدیریت یکپارچه افزایش ناگهانی ترافیک را تضمین می‌کند.
- Cloud Run که بر اساس Borg گوگل ساخته شده است، نیاز به نگهداری کلاستر کوبرنتیز را از بین می‌برد و استقرارها را ساده می‌کند.
- Cloud Run Tasks با امکان تکرار داخلی، امکان انجام حداکثر ۱۰۰۰۰ کار در هر batch را فراهم می‌کرد و نیاز به زیرساخت زمان‌بندی کار سفارشی را از بین می‌برد.
نکته کلیدی: برای شرکت‌هایی که حجم کاری بسیار پویا را مدیریت می‌کنند، Kubernetes هنوز هم می‌تواند مفید باشد. با این حال، برای شرکت‌هایی که بر روی راه‌حل‌های ساده‌تر، مقرون‌به‌صرفه و مقیاس‌پذیر متمرکز هستند، راه‌حل‌هایی مانند Cloud Run یک جایگزین قانع‌کننده ارائه می‌دهند که هزینه‌های سربار زیرساخت را حذف می‌کند و در عین حال عملکرد را به خطر نمی‌اندازد.
نتیجه‌گیری
برای کسانی که از سیستم‌های قدیمی به ماشین‌های مجازی و سپس به Kubernetes منتقل شده‌اند، واضح است که Kubernetes همیشه بهترین گزینه برای هر حجم کاری نیست.
معمولا مشکلات زمانی شروع می‌شوند که شما شروع به کار در مقیاس بزرگ، هزینه‌های سربار نگهداری، هزینه و غیره می‌کنید.
اگر به دنبال یک راهکار میزبانی قدرتمند هستید، سرور مجازی پارسدو با امکان انتخاب سیستم‌عامل دلخواه و تحویل آنی در ایران، ترکیه، آلمان، هلند و آمریکا، انتخابی هوشمندانه است.
آیا به این معنی است که Kubernetes پلتفرم ایده‌آلی برای برنامه‌ها نیست؟
به هیچ وجه! Kubernetes با پذیرش سریع در صنایع مختلف، از جمله بارهای کاری هوش مصنوعی، یادگیری ماشین، برنامه‌های بومی ابری و معماری‌های میکروسرویس در مقیاس بزرگ، بیش از هر زمان دیگری محبوب شده است.
با این حال، این یک راه‌حل یکسان برای همه نیست. در حالی که Kubernetes در بسیاری از زمینه‌ها عالی است، موارد استفاده خاصی وجود دارد که ممکن است بهترین انتخاب نباشد.
