تو قسمت سیزدهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم کنترل دسترسی تا اینکه ببینیم چجوری به کلاستر متصل میشیم و چه فرآیندی طی میشه.
-
s=”md-block-header-three direction-rtl” dir=”rtl”>طراحی کلاستر Kubernetes با قابلیت High Availability (HA)
ass=”md-block-unstyled direction-rtl” dir=”rtl”>کوبرنتیز به عنوان یکی از محبوب‌ترین ابزارهای Orchestration کانتینرها شناخته می‌شود که مزایای بی‌شماری برای مقیاس‌پذیری، پایداری و خودبهبودی سیستم‌ها ارائه می‌دهد. با این حال، برای سازمان‌ها و کسب‌وکارهای مهم، قابلیت دسترسی بالا (High Availability) یک الزام اساسی محسوب می‌شود. در این مقاله، گزینه‌های مختلف برای طراحی یک کلاستر HA در کوبرنتیز بررسی و راه‌حل‌های عملی ارائه می‌شود.&lt;/p></p>
s=”yoast-text-mark”>ss=”md-blo
ass=”yoast-text-mark”>ass=”md-block-unstyled direction-rtl” dir=”rtl”>ck-header-four direction-rtl” dir=”rtl”>گزینه‌های طراحی کلاستر Kubernetes با HA</p>
دو مسیر اصلی برای طراحی کلاستر High Available در Kubernetes وجود دارد:
- =”rtl”>
- توپولوژی Control Plane با etcd استک‌شده (Stacked etcd Topology)
- توپولوژی Control Plane با etcd خارجی (External etcd Topology)</strong></strong>
<p class=”md-block-unstyled direction-rtl” dir=”rtl”>هر کدام از این گزینه‌ها مزایا و معایب خاص خود را دارند که باید با دقت بررسی شوند.
۱. توپولوژی Stacked etcd</h4>
ass=”md-block-unstyled direction-rtl” dir=”rtl”>در توپولوژی استک‌شده، سرویس ذخیره‌سازی توزیع‌شده etcd بر روی همان نودهایی که Control Plane کوبرنتیز اجرا می‌شود، قرار می‌گیرد.
<figure class=”md-block-image is-position-relative”>
اگر از Kubernetes به عنوان پلتفرم عملیاتی برای برنامه‌های خود استفاده می‌کنید، احتمالاً با پرسش‌هایی اساسی مواجه خواهید شد:
- چند کلاستر باید داشته باشیم؟
- کلاسترها چقدر بزرگ باشند؟
- چه چیزی باید در هر کلاستر قرار بگیرد؟
در این مقاله به بررسی این پرسش‌ها می‌پردازیم و مزایا و معایب گزینه‌های مختلف را تحلیل می‌کنیم.
تصویر بالا مزایا و معایب استفاده از هرکدوم از رویکردهای انتخاب تعداد بیشتر یا کمتری کلاستر رو نشون میده.
به عنوان یک توسعه‌دهنده نرم‌افزار، معمولاً چندین برنامه را طراحی و اجرا می‌کنید. این برنامه‌ها ممکن است در محیط‌های مختلفی مانند dev و test و production اجرا شوند.
این وضعیت به نوعی ماتریس برنامه‌ها و محیط‌ها منجر می‌شود. به عنوان مثال، اگر ۳ برنامه و ۳ محیط داشته باشید، در مجموع ۹ نمونه برنامه (Application Instance) خواهید داشت.
سوال اینجاست که:
- آیا همه نمونه‌های برنامه را در یک کلاستر واحد اجرا کنید؟
- </li>
lass=”md-block-unstyled direction-rtl” dir=”rtl”>یا برای هر نمونه از برنامه یک کلاستر جداگانه داشته باشید؟
- یا ترکیبی از این دو روش؟
همه این گزینه‌ها قابل‌قبول هستند و Kubernetes محدودیتی برای این انتخاب‌ها ایجاد نمی‌کند!
در ادامه، گزینه‌های موجود را بررسی می‌کنیم:
- یک کلاستر بزرگ و اشتراکی
- کلاسترهای کوچک تک‌منظوره
- کلاستر به ازای هر برنامه
- کلاستر به ازای هر محیط
به‌طور کلی، می‌توان گفت یک کلاستر زمانی “بزرگ‌تر” از کلاستر دیگر است که مجموع بیشتری از نودها و پادها را داشته باشد — برای مثال، کلاستری با ۱۰ نود و ۱۰۰ پاد از کلاستری با ۱ نود و ۱۰ پاد بزرگ‌تر است.
</div></div>
</figcaption></figure> ۱. یک کلاستر بزرگ و اشتراکی
در این روش، تمام ورک‌لودها در یک کلاستر Kubernetes اجرا می‌شوند و از طریق Namespaceهای جداگانه از هم تفکیک می‌شوند.
✅ مزایا:
- استفاده بهینه از منابع: تنها یک نسخه از منابع مدیریتی مانند نودهای کنترل، لاگینگ، مانیتورینگ و … نیاز است.
- کاهش هزینه‌ها: هزینه کمتری برای مدیریت کلاستر و زیرساخت‌ها پرداخت می‌شود.
- مدیریت ساده‌تر: به‌روزرسانی‌ها و تنظیمات کلاستر فقط یک بار انجام می‌شوند.
❌ معایب:
- ass=”md-block-ordered-list-item direction-rtl” dir=”rtl”>
- مشکل Single Point Of Failure: خرابی کلاستر کل بار کاری را متوقف می‌کند.
- نبود ایزوله‌سازی کامل: برنامه‌ها از منابع مشترک استفاده می‌کنند و ریسک امنیتی ایجاد می‌شود.
- مقیاس‌پذیری محدود: کلاسترهای Kubernetes نمی‌توانند به‌صورت بی‌نهایت بزرگ شوند.
۲. کلاسترهای کوچک تک‌منظوره
در این روش، برای هر نمونه از برنامه یک کلاستر Kubernetes جداگانه اجرا می‌شود.
Kubernetes
✅ مزایا:
- کاهش دامنه خرابی: خرابی هر کلاستر فقط روی بار کاری همان کلاستر تأثیر می‌گذارد.
- ایزوله‌سازی کامل: منابع سخت‌افزاری، شبکه و سرویس‌ها بین کلاسترها کاملاً جدا هستند.
- دسترسی محدودتر: تعداد افراد دارای دسترسی به هر کلاستر کمتر است.
❌ معایب:
- مصرف غیربهینه منابع: هر کلاستر نیاز به نودهای مدیریتی و منابع اختصاصی دارد.
- هزینه بالا: اجرای چندین کلاستر هزینه بیشتری در پی دارد.
- مدیریت پیچیده‌تر: نیاز به فرآیندهای خودکار برای مدیریت به‌روزرسانی‌ها و تنظیمات چند کلاستر.
۳. کلاستر به ازای هر برنامه
در این رویکرد، برای هر برنامه یک کلاستر جداگانه ایجاد می‌شود که تمام نمونه‌های برنامه (مانند نسخه Dev و Prod) در همان اجرا می‌شوند.
Kubernetes
Observability
✅ مزایا:
- سفارشی‌سازی کلاستر برای برنامه: هر کلاستر می‌تواند بر اساس نیازهای برنامه خاص، مانند نودهای GPU یا پلاگین‌های CNI، تنظیم شود.
❌ معایب:
- اختلاط محیط‌ها: نسخه‌های Dev و Prod یک برنامه در همان کلاستر اجرا می‌شوند و خرابی نسخه توسعه می‌تواند نسخه تولید را تحت تأثیر قرار دهد.
۴. کلاستر به ازای هر محیط
در این روش، به‌ازای هر محیط (مانند Dev، Test و Prod) یک کلاستر جداگانه ایجاد می‌شود که تمام برنامه‌های آن محیط در کلاسترمربوطه اجرا می‌شوند.
✅ مزایا:
- ایزوله‌سازی محیط تولید: محیط تولید از مشکلات محیط‌های دیگر جداست و پایدارتر عمل می‌کند.
- سفارشی‌سازی محیط: می‌توان کلاسترها را بر اساس نیازهای هر محیط بهینه کرد.
- کنترل دسترسی به محیط تولید: می‌توان دسترسی به محیط تولید را محدود یا حتی حذف کرد.
❌ معایب:
- نبود ایزوله‌سازی بین برنامه‌ها: برنامه‌های غیرمرتبط از منابع مشترک استفاده می‌کنند.
- عدم تمرکز نیازهای ویژه: اگر یک برنامه نیاز خاصی مانند GPU داشته باشد، تمام کلاسترها باید این نیاز را تأمین کنند.
نتیجه‌گیری
در مجموع، می‌توانید از تعداد کمی کلاستر بزرگ یا تعداد زیادی کوچک استفاده کنید. هرکدام از این روش‌ها مزایا و معایب خود را دارند.
انتخاب بهترین رویکرد به نیازهای شما بستگی دارد:
- اگر به صرفه‌جویی در هزینه و مدیریت ساده‌تر اهمیت می‌دهید، یک کلاستر بزرگ گزینه مناسبی است.
- اگر ایزوله‌سازی و کاهش دامنه خرابی برایتان مهم است، استفاده از کلاسترهای کوچک‌تر بهتر خواهد بود.
- می‌توانید ترکیبی از این رویکردها را نیز استفاده کنید؛ برای مثال، می‌توانید دو کلاستر به ازای هر تیم داشته باشید: یک کلاستر برای توسعه و آزمایش و یکی برای تولید.
با توجه به سناریوهای بالا، می‌توانید مناسب‌ترین ترکیب را برای کسب‌وکار خود انتخاب کنید.
در بلاگ پست‌های بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد می‌گیریم.
مراقب خودتون باشید. 🌹🐳🌹
-
دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.
-
مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.
-
هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.
-
سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.
</div></div>
