توجه داشته باشید. ترجمه: این مطلب از یک پروژه آموزشی است پاسخ به یک سوال رایج هنگام طراحی زیرساخت مبتنی بر Kubernetes است. ما امیدواریم که توضیحات نسبتاً دقیق از مزایا و معایب هر گزینه به شما کمک کند تا بهترین انتخاب را برای پروژه خود داشته باشید.
TL؛ DR: مجموعه یکسانی از بارهای کاری را می توان بر روی چندین خوشه بزرگ (هر خوشه دارای تعداد زیادی بار کاری خواهد بود) یا روی بسیاری از موارد کوچک (با تعداد بارهای کمی در هر خوشه) اجرا کرد.
در زیر جدولی وجود دارد که مزایا و معایب هر رویکرد را ارزیابی می کند:
هنگام استفاده از Kubernetes به عنوان یک پلتفرم برای اجرای برنامه‌ها، چندین سؤال اساسی اغلب در مورد پیچیدگی‌های راه‌اندازی خوشه‌ها مطرح می‌شود:
- از چند کلاستر باید استفاده کنم؟
- چقدر باید آنها را بزرگ کنم؟
- هر خوشه باید شامل چه مواردی باشد؟
در این مقاله سعی می کنم با تحلیل مزایا و معایب هر رویکرد به همه این سوالات پاسخ دهم.
بیان یک سوال
به‌عنوان یک توسعه‌دهنده نرم‌افزار، احتمالاً بسیاری از برنامه‌ها را همزمان توسعه داده و اجرا می‌کنید.
علاوه بر این، بسیاری از نمونه‌های این برنامه‌ها احتمالاً در محیط‌های مختلف اجرا می‌شوند - برای مثال، ممکن است چنین باشند توسعه تمدن, آزمون и تولید کننده.
نتیجه یک ماتریس کامل از برنامه ها و محیط ها است:
برنامه ها و محیط ها
مثال بالا 3 برنامه و 3 محیط را نشان می دهد که در مجموع 9 گزینه ممکن به دست می آید.
هر نمونه برنامه یک واحد استقرار مستقل است که می توان با آن مستقل از دیگران کار کرد.
لطفا توجه داشته باشید که نمونه برنامه ممکن است از تعداد زیادی تشکیل شود اجزاءمانند frontend، backend، پایگاه داده و غیره. در مورد یک برنامه میکروسرویس، نمونه شامل تمام ریزسرویس ها می شود.
در نتیجه، کاربران Kubernetes چندین سوال دارند:
- آیا همه نمونه های برنامه باید در یک کلاستر قرار گیرند؟
- آیا ارزش داشتن یک کلاستر جداگانه برای هر نمونه برنامه را دارد؟
- یا شاید ترکیبی از رویکردهای فوق باید استفاده شود؟
همه این گزینه‌ها کاملاً قابل اجرا هستند، زیرا Kubernetes یک سیستم انعطاف‌پذیر است که توانایی‌های کاربر را محدود نمی‌کند.
در اینجا برخی از راه های ممکن وجود دارد:
- یک خوشه مشترک بزرگ؛
- بسیاری از خوشه های کوچک بسیار تخصصی؛
- یک خوشه در هر برنامه؛
- یک خوشه در هر محیط
همانطور که در زیر نشان داده شده است، دو رویکرد اول در انتهای مخالف مقیاس گزینه ها قرار دارند:
از چند خوشه بزرگ (چپ) تا تعداد زیادی خوشه کوچک (راست)
به طور کلی، یک خوشه در صورتی که دارای مجموع گره ها و غلاف های بیشتری باشد، «بزرگتر» از دیگری در نظر گرفته می شود. برای مثال، خوشه ای با 10 گره و 100 غلاف بزرگتر از خوشه ای با 1 گره و 10 غلاف است.
خوب، بیایید شروع کنیم!
1. یک خوشه مشترک بزرگ
اولین گزینه این است که همه بارهای کاری را در یک کلاستر قرار دهید:
یک خوشه بزرگ
در این رویکرد، خوشه به عنوان یک جهانی استفاده می شود پلت فرم زیرساخت - شما به سادگی هر آنچه را که نیاز دارید در یک خوشه Kubernetes موجود مستقر می کنید.
Kubernetes اجازه می دهد تا بخش هایی از خوشه به طور منطقی از یکدیگر جدا شوند، به طوری که هر نمونه برنامه می تواند فضای نام خود را داشته باشد.
بیایید به مزایا و معایب این روش نگاه کنیم.
+ استفاده کارآمد از منابع
با یک کلاستر، شما فقط به یک کپی از تمام منابع مورد نیاز برای اجرا و مدیریت خوشه Kubernetes نیاز دارید.
به عنوان مثال، این برای گره های اصلی صادق است. به طور معمول، هر خوشه Kubernetes دارای 3 گره اصلی است، بنابراین برای یک خوشه واحد تعداد آنها به همین صورت باقی می ماند (برای مقایسه، 10 خوشه به 30 گره اصلی نیاز دارند).
ظرافت فوق در مورد سایر سرویس‌هایی که در کل خوشه کار می‌کنند، مانند متعادل‌کننده‌های بار، کنترل‌کننده‌های ورودی، احراز هویت، ورود به سیستم و سیستم‌های نظارت نیز اعمال می‌شود.
در یک خوشه واحد، همه این خدمات را می توان به طور همزمان برای همه بارهای کاری استفاده کرد (نیازی به ایجاد کپی از آنها نیست، همانطور که در مورد خوشه های متعدد وجود دارد).
+ ارزان
در نتیجه موارد فوق، خوشه های کمتر معمولا ارزان تر هستند زیرا هزینه های سربار وجود ندارد.
این امر به ویژه در مورد گره های اصلی صادق است، که می توانند هزینه قابل توجهی صرف نظر از نحوه میزبانی آنها (در محل یا در فضای ابری) داشته باشند.
برخی از خدمات Kubernetes مدیریت شده، مانند یا ، لایه کنترل را به صورت رایگان ارائه دهید. در این صورت مسئله هزینه کمتر حاد است.
همچنین خدمات مدیریت شده ای وجود دارد که هزینه ثابتی را برای عملکرد هر خوشه Kubernetes دریافت می کند (به عنوان مثال، ).
+ مدیریت کارآمد
مدیریت یک خوشه آسان تر از مدیریت چندین خوشه است.
مدیریت ممکن است شامل وظایف زیر باشد:
- به روز رسانی نسخه Kubernetes.
- راه اندازی خط لوله CI/CD.
- نصب پلاگین CNI؛
- راه اندازی یک سیستم احراز هویت کاربر؛
- نصب یک کنترل کننده دسترسی؛
و خیلی های دیگر…
در مورد یک خوشه، شما باید تمام این کارها را فقط یک بار انجام دهید.
برای بسیاری از خوشه‌ها، عملیات باید چندین بار تکرار شوند، که احتمالاً نیازمند اتوماسیون فرآیندها و ابزارها برای اطمینان از ثبات و ثبات در فرآیند است.
و اکنون چند کلمه در مورد معایب.
- نقطه شکست
در صورت امتناع تنها خوشه فوراً کار نخواهد کرد همه حجم کار!
راه های زیادی وجود دارد که ممکن است همه چیز اشتباه شود:
- به روز رسانی Kubernetes منجر به عوارض جانبی غیرمنتظره می شود.
- یک جزء کلستر (مثلاً یک پلاگین CNI) همانطور که انتظار می رود کار نمی کند.
- یکی از اجزای خوشه به درستی پیکربندی نشده است.
- شکست در زیرساخت های اساسی
یکی از این رویدادها می‌تواند به همه بارهای کاری میزبانی شده در یک خوشه مشترک آسیب جدی وارد کند.
- بدون عایق سفت و سخت
اجرای در یک خوشه مشترک به این معنی است که برنامه ها سخت افزار، قابلیت های شبکه و سیستم عامل را در گره های خوشه به اشتراک می گذارند.
به یک معنا، دو کانتینر با دو برنامه مختلف که روی یک گره اجرا می‌شوند، مانند دو پردازش هستند که روی یک ماشین اجرا می‌شوند و هسته سیستم‌عامل یکسانی را اجرا می‌کنند.
کانتینرهای لینوکس نوعی انزوا را ارائه می دهند، اما تقریباً به اندازه آنچه که مثلاً توسط ماشین های مجازی ارائه می شود، قوی نیست. در اصل، یک فرآیند در یک کانتینر همان فرآیندی است که در سیستم عامل میزبان اجرا می شود.
این می تواند یک مسئله امنیتی باشد: این ترتیب از نظر تئوری به برنامه های غیر مرتبط اجازه می دهد تا با یکدیگر ارتباط برقرار کنند (اعم از عمدی یا تصادفی).
علاوه بر این، همه بارهای کاری در یک خوشه Kubernetes برخی از سرویس‌های کلستری مانند - این به برنامه ها اجازه می دهد تا خدمات سایر برنامه های کاربردی را در خوشه پیدا کنند.
همه نکات بالا بسته به الزامات امنیتی برنامه ممکن است معانی مختلفی داشته باشند.
Kubernetes ابزارهای مختلفی را برای جلوگیری از مسائل امنیتی مانند и . با این حال، تنظیم صحیح آنها نیاز به تجربه دارد؛ علاوه بر این، آنها قادر به بستن مطلق حفره های امنیتی نیستند.
این مهم است که همیشه به یاد داشته باشید که Kubernetes در ابتدا برای آن طراحی شده بود اشتراک گذاری، نه برای انزوا و ایمنی.
- فقدان چند اجاره ای سخت
با توجه به فراوانی منابع مشترک در یک خوشه Kubernetes، راه های زیادی وجود دارد که برنامه های مختلف می توانند روی انگشتان یکدیگر قدم بگذارند.
به عنوان مثال، یک برنامه کاربردی ممکن است یک منبع مشترک (مانند CPU یا حافظه) را در انحصار خود درآورد و از دسترسی سایر برنامه‌های در حال اجرا در همان گره به آن جلوگیری کند.
Kubernetes مکانیسم های مختلفی را برای کنترل این رفتار ارائه می دهد، مانند (همچنین به مقاله "" - تقریبا ترجمه.), и . با این حال، همانطور که در مورد امنیت، پیکربندی آنها کاملاً بی اهمیت است و نمی توانند کاملاً از همه عوارض جانبی پیش بینی نشده جلوگیری کنند.
- تعداد کاربران زیاد
در مورد یک خوشه، شما باید دسترسی به آن را برای افراد زیادی باز کنید. و هرچه تعداد آنها بیشتر باشد، خطر "شکستن" چیزی بیشتر است.
در داخل خوشه می توانید کنترل کنید که چه کسی می تواند با استفاده از چه کاری انجام دهد (به مقاله مراجعه کنید" - تقریبا ترجمه.). با این حال، کاربران را از "شکستن" چیزی در محدوده محدوده مسئولیت خود باز نمی دارد.
- خوشه ها نمی توانند به طور نامحدود رشد کنند
خوشه ای که برای همه بارهای کاری استفاده می شود احتمالاً بسیار بزرگ خواهد بود (از نظر تعداد گره ها و پادها).
اما در اینجا مشکل دیگری پیش می آید: خوشه ها در Kubernetes نمی توانند به طور نامحدود رشد کنند.
یک محدودیت نظری در اندازه خوشه وجود دارد. در Kubernetes تقریباً است .
با این حال، در زندگی واقعی، مشکلات می توانند خیلی زودتر شروع شوند - به عنوان مثال، فقط با .
واقعیت این است که خوشه های بزرگ بار زیادی را روی لایه کنترل Kubernetes قرار می دهند. به عبارت دیگر، راه‌اندازی و اجرای کارآمد خوشه مستلزم تنظیم دقیق است.
این موضوع در یک مقاله مرتبط در وبلاگ اصلی به نام "'.
اما بیایید رویکرد مخالف را در نظر بگیریم: بسیاری از خوشه های کوچک.
2. بسیاری از خوشه های کوچک و تخصصی
با این رویکرد، برای هر عنصری که مستقر می کنید، از یک خوشه مجزا استفاده می کنید:
بسیاری از خوشه های کوچک
برای اهداف این مقاله، تحت عنصر قابل استقرار به نمونه ای از یک برنامه - برای مثال، نسخه توسعه دهنده یک برنامه کاربردی جداگانه اشاره دارد.
این استراتژی از Kubernetes به عنوان یک متخصص استفاده می کند زمان اجرا برای نمونه های کاربردی فردی
بیایید به مزایا و معایب این روش نگاه کنیم.
+ "شعاع انفجار" محدود
هنگامی که یک خوشه شکست می خورد، پیامدهای منفی فقط به آن دسته از بارهای کاری محدود می شود که در آن خوشه مستقر شده اند. همه بارهای کاری دیگر دست نخورده باقی می مانند.
+ عایق
بارهای کاری میزبانی شده در کلاسترهای جداگانه منابعی مانند پردازنده، حافظه، سیستم عامل، شبکه یا سایر خدمات را به اشتراک نمی گذارند.
نتیجه جداسازی شدید بین برنامه های غیر مرتبط است که می تواند برای امنیت آنها مفید باشد.
+ تعداد کمی از کاربران
با توجه به اینکه هر خوشه فقط شامل مجموعه محدودی از بارهای کاری است، تعداد کاربرانی که به آن دسترسی دارند کاهش می یابد.
هرچه افراد کمتری به خوشه دسترسی داشته باشند، خطر "شکستن" چیزی کمتر می شود.
بیایید به معایب نگاه کنیم.
- استفاده ناکارآمد از منابع
همانطور که قبلا ذکر شد، هر خوشه Kubernetes به مجموعه خاصی از منابع مدیریتی نیاز دارد: گره های اصلی، اجزای لایه کنترل، راه حل های نظارت و گزارش.
در مورد تعداد زیاد خوشه های کوچک، سهم بیشتری از منابع باید به مدیریت اختصاص یابد.
- گران است
استفاده ناکارآمد از منابع به طور خودکار هزینه های بالایی را به دنبال دارد.
به عنوان مثال، حفظ 30 گره اصلی به جای سه گره با قدرت محاسباتی یکسان، لزوماً بر هزینه ها تأثیر می گذارد.
- مشکلات در اداره
مدیریت چند خوشه Kubernetes بسیار دشوارتر از مدیریت تنها یک خوشه است.
به عنوان مثال، شما باید احراز هویت و مجوز را برای هر خوشه پیکربندی کنید. نسخه Kubernetes نیز باید چندین بار به روز شود.
احتمالاً برای کارآمدتر کردن همه این وظایف، باید از اتوماسیون استفاده کنید.
حال بیایید به سناریوهای کمتر افراطی نگاه کنیم.
3. یک خوشه در هر برنامه
در این رویکرد، شما یک کلاستر مجزا برای تمام نمونه های یک برنامه خاص ایجاد می کنید:
خوشه در هر برنامه
این مسیر را می توان تعمیم این اصل دانست.خوشه جداگانه در هر تیم"، زیرا معمولاً تیمی از مهندسان در حال توسعه یک یا چند برنامه هستند.
بیایید به مزایا و معایب این روش نگاه کنیم.
+ خوشه را می توان با برنامه تنظیم کرد
اگر برنامه ای نیازهای ویژه ای داشته باشد، می توان آنها را در یک خوشه بدون تأثیر بر خوشه های دیگر پیاده سازی کرد.
چنین نیازهایی ممکن است شامل کارگران GPU، پلاگین‌های خاص CNI، مش سرویس یا برخی خدمات دیگر باشد.
هر خوشه را می‌توان برای برنامه‌ای که در آن اجرا می‌شود تنظیم کرد تا فقط شامل موارد مورد نیاز باشد.
- محیط های مختلف در یک خوشه
نقطه ضعف این رویکرد این است که نمونه های کاربردی از محیط های مختلف در یک خوشه همزیستی دارند.
به عنوان مثال، نسخه prod برنامه در همان کلاستر با نسخه توسعه دهنده اجرا می شود. این همچنین به این معنی است که توسعه دهندگان در همان خوشه ای کار می کنند که نسخه تولیدی برنامه در آن اجرا می شود.
اگر به دلیل اقدامات توسعه‌دهندگان یا اشکالاتی در نسخه توسعه‌دهنده، شکستی در خوشه رخ دهد، نسخه prod نیز به طور بالقوه ممکن است آسیب ببیند - یک اشکال بزرگ در این رویکرد.
و در نهایت، آخرین سناریو در لیست ما.
4. یک خوشه در هر محیط
این سناریو شامل تخصیص یک خوشه جداگانه برای هر محیط است:
یک خوشه در هر محیط
به عنوان مثال، شما ممکن است خوشه هایی داشته باشید توسعه تمدن, آزمون и تولید کننده، که در آن تمام نمونه های برنامه اختصاص داده شده به یک محیط خاص را اجرا خواهید کرد.
در اینجا مزایا و معایب این روش آورده شده است.
+ ایزوله سازی محیط پرود
در این رویکرد، همه محیط ها از یکدیگر جدا می شوند. با این حال، در عمل این امر به ویژه در یک محیط تولیدی مهم است.
نسخه های تولیدی برنامه اکنون مستقل از آنچه در خوشه ها و محیط های دیگر اتفاق می افتد است.
به این ترتیب، اگر به طور ناگهانی مشکلی در خوشه توسعه دهنده پیش بیاید، نسخه های prod برنامه ها به کار خود ادامه می دهند انگار هیچ اتفاقی نیفتاده است.
+ خوشه را می توان با محیط تنظیم کرد
هر خوشه را می توان با محیط خود تنظیم کرد. به عنوان مثال، شما می توانید:
- نصب ابزارهای توسعه و اشکال زدایی در خوشه توسعه.
- چارچوب ها و ابزارهای تست را در خوشه نصب کنید آزمون;
- از سخت افزار قوی تر و کانال های شبکه در خوشه استفاده کنید تولید کننده.
این به شما امکان می دهد تا کارایی توسعه و عملکرد برنامه را افزایش دهید.
+ محدود کردن دسترسی به خوشه تولید
نیاز به کار مستقیم با یک خوشه پرود به ندرت ایجاد می شود، بنابراین می توانید دایره افرادی را که به آن دسترسی دارند به طور قابل توجهی محدود کنید.
شما می توانید حتی فراتر رفته و دسترسی افراد را به این خوشه به طور کلی منع کنید و همه استقرارها را با استفاده از ابزار خودکار CI/CD انجام دهید. چنین رویکردی خطر خطاهای انسانی را دقیقاً در جایی که بیشتر مرتبط است به حداقل می رساند.
و اکنون چند کلمه در مورد معایب.
- بدون جداسازی بین برنامه ها
نقطه ضعف اصلی این رویکرد فقدان جداسازی سخت افزار و منابع بین برنامه ها است.
برنامه های نامرتبط منابع خوشه ای را به اشتراک می گذارند: هسته سیستم، پردازنده، حافظه و برخی خدمات دیگر.
همانطور که گفته شد، این می تواند بالقوه خطرناک باشد.
- ناتوانی در بومی سازی وابستگی های برنامه
اگر یک برنامه دارای الزامات خاصی باشد، باید در همه خوشه ها برآورده شود.
به عنوان مثال، اگر یک برنامه به یک GPU نیاز دارد، هر خوشه باید حداقل دارای یک کارگر با یک GPU باشد (حتی اگر فقط توسط آن برنامه استفاده شود).
در نتیجه، هزینه های بالاتر و استفاده ناکارآمد از منابع را در معرض خطر قرار می دهیم.
نتیجه
اگر مجموعه خاصی از برنامه‌ها دارید، می‌توان آنها را در چندین خوشه بزرگ یا تعداد زیادی کوچک قرار داد.
این مقاله مزایا و معایب رویکردهای مختلف را مورد بحث قرار می‌دهد، از یک خوشه جهانی گرفته تا چندین رویکرد کوچک و بسیار تخصصی:
- یک خوشه کلی بزرگ؛
- بسیاری از خوشه های کوچک بسیار تخصصی؛
- یک خوشه در هر برنامه؛
- یک خوشه در هر محیط
پس کدام رویکرد را باید در پیش بگیرید؟
مثل همیشه، پاسخ به مورد استفاده بستگی دارد: باید جوانب مثبت و منفی رویکردهای مختلف را بسنجید و بهینه ترین گزینه را انتخاب کنید.
با این حال، انتخاب به مثال های بالا محدود نمی شود - می توانید از هر ترکیبی از آنها استفاده کنید!
به عنوان مثال، می توانید برای هر تیم چند خوشه سازماندهی کنید: یک خوشه توسعه (که در آن محیط هایی وجود خواهد داشت. توسعه تمدن и آزمون) و خوشه برای تولید (محل تولید در آن قرار خواهد گرفت).
بر اساس اطلاعات این مقاله، می‌توانید مزایا و معایب آن را برای یک سناریوی خاص بهینه کنید. موفق باشید!
PS
در وبلاگ ما نیز بخوانید:
- «"؛
- «"؛
- «"؛
- «'.
منبع: www.habr.com