دیزاین کلاستر (قسمت سیزدهم)

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

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
• مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
• خودکارش کن، مشکلاتت حل می‌شه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.
• در مسیر دواپس این‌بار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
• در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
• در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
• در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
• در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویس‌هامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
• در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
• در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
• در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیس‌ها و تجربیات خودم رو گفتم.
• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.
• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.
• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.
• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.
• مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپن‌تله‌متری دادیم.
• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.
• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.
• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.
• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.
• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.
• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.
• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.
• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.
• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.
• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.
• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.
• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

طراحی کلاستر Kubernetes با قابلیت High Availability (HA)

کوبرنتیز به عنوان یکی از محبوب‌ترین ابزارهای Orchestration کانتینرها شناخته می‌شود که مزایای بی‌شماری برای مقیاس‌پذیری، پایداری و خودبهبودی سیستم‌ها ارائه می‌دهد. با این حال، برای سازمان‌ها و کسب‌وکارهای مهم، قابلیت دسترسی بالا (High Availability) یک الزام اساسی محسوب می‌شود. در این مقاله، گزینه‌های مختلف برای طراحی یک کلاستر HA در کوبرنتیز بررسی و راه‌حل‌های عملی ارائه می‌شود.

گزینه‌های طراحی کلاستر Kubernetes با HA

دو مسیر اصلی برای طراحی کلاستر High Available در Kubernetes وجود دارد:

1. توپولوژی Control Plane با etcd استک‌شده (Stacked etcd Topology)
2. توپولوژی Control Plane با etcd خارجی (External etcd Topology)

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

1. توپولوژی Stacked etcd

در توپولوژی استک‌شده، سرویس ذخیره‌سازی توزیع‌شده etcd بر روی همان نودهایی که Control Plane کوبرنتیز اجرا می‌شود، قرار می‌گیرد.

• هر نود Control Plane، شامل سرویس‌های kube-apiserver، kube-scheduler و kube-controller-manager است.
• هر نود یک کپی محلی از etcd را اجرا می‌کند و تنها با kube-apiserver محلی خود ارتباط دارد.
• برای بارگذاری درخواست‌ها به kube-apiserver از یک لود بالانسر بیرونی استفاده می‌شود.

مزایا:

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

معایب:

• وابستگی به Control Plane و etcd روی یک نود؛ اگر یک نود از دسترس خارج شود، هم etcd و هم Control Plane تحت تاثیر قرار می‌گیرد.
• نیاز به حداقل 3 نود Control Plane برای ایجاد یک ساختار HA پایدار.

نکته: این توپولوژی به صورت پیش‌فرض در kubeadm اجرا می‌شود. متداول‌ترین روش پیاده‌سازی کوبرنتیز به صورت HA می‌باشد و معمولا از این روش استفاده می‌شود.

2. توپولوژی External etcd:

در این توپولوژی، سرویس etcd از نودهای Control Plane جدا شده و روی نودهای اختصاصی اجرا می‌شود:

• هر نود Control Plane مانند توپولوژی استک‌شده سرویس‌های kube-apiserver، kube-scheduler و kube-controller-manager را اجرا می‌کند.
• نودهای etcd به صورت جداگانه اجرا شده و با kube-apiserver هر نود Control Plane ارتباط برقرار می‌کنند. یعنی apiserver با آنها ارتباط برقرار می‌کنه.

مزایا:

• جداسازی Control Plane و etcd باعث کاهش وابستگی می‌شود.
• از بین رفتن یک نود Control Plane یا etcd تاثیر کمتری روی پایداری کلاستر دارد.

معایب:

• نیاز به تعداد بیشتری از نودها (حداقل 3 نود Control Plane و 3 نود etcd).
• پیچیدگی بیشتر در پیاده‌سازی و نگهداری.

معمولا جاهایی که دوست داریم نودهای مستر خودمون رو stateless کنیم از این ساختار استفاده می‌کنیم که باعث می‌شه بتونیم تنها کامپوننتی که state داره رو بیرون از نودهای مستر ستاپ کنیم. در اسکیل‌های بزرگ هم توجیه داره که این کار رو انجام بدیم.

انتخاب تعداد کلاسترهای Kubernetes: چند کلاستر بهتر است یا یک کلاستر بزرگ؟

اگر از Kubernetes به عنوان پلتفرم عملیاتی برای برنامه‌های خود استفاده می‌کنید، احتمالاً با پرسش‌هایی اساسی مواجه خواهید شد:

• چند کلاستر باید داشته باشیم؟
• کلاسترها چقدر بزرگ باشند؟
• چه چیزی باید در هر کلاستر قرار بگیرد؟

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

تصویر بالا مزایا و معایب استفاده از هرکدوم از رویکردهای انتخاب تعداد بیشتر یا کمتری کلاستر رو نشون میده.

به عنوان یک توسعه‌دهنده نرم‌افزار، معمولاً چندین برنامه را طراحی و اجرا می‌کنید. این برنامه‌ها ممکن است در محیط‌های مختلفی مانند dev و test و production اجرا شوند.

این وضعیت به نوعی ماتریس برنامه‌ها و محیط‌ها منجر می‌شود. به عنوان مثال، اگر 3 برنامه و 3 محیط داشته باشید، در مجموع 9 نمونه برنامه (Application Instance) خواهید داشت.

سوال اینجاست که:

• آیا همه نمونه‌های برنامه را در یک کلاستر واحد اجرا کنید؟
• یا برای هر نمونه از برنامه یک کلاستر جداگانه داشته باشید؟
• یا ترکیبی از این دو روش؟

همه این گزینه‌ها قابل‌قبول هستند و Kubernetes محدودیتی برای این انتخاب‌ها ایجاد نمی‌کند!

در ادامه، گزینه‌های موجود را بررسی می‌کنیم:

1. یک کلاستر بزرگ و اشتراکی
2. کلاسترهای کوچک تک‌منظوره
3. کلاستر به ازای هر برنامه
4. کلاستر به ازای هر محیط

به‌طور کلی، می‌توان گفت یک کلاستر زمانی "بزرگ‌تر" از کلاستر دیگر است که مجموع بیشتری از نودها و پادها را داشته باشد — برای مثال، کلاستری با ۱۰ نود و ۱۰۰ پاد از کلاستری با ۱ نود و ۱۰ پاد بزرگ‌تر است.

۱. یک کلاستر بزرگ و اشتراکی

در این روش، تمام ورک‌لودها در یک کلاستر Kubernetes اجرا می‌شوند و از طریق Namespaceهای جداگانه از هم تفکیک می‌شوند.

✅ مزایا:

1. استفاده بهینه از منابع: تنها یک نسخه از منابع مدیریتی مانند نودهای کنترل، لاگینگ، مانیتورینگ و ... نیاز است.
2. کاهش هزینه‌ها: هزینه کمتری برای مدیریت کلاستر و زیرساخت‌ها پرداخت می‌شود.
3. مدیریت ساده‌تر: به‌روزرسانی‌ها و تنظیمات کلاستر فقط یک بار انجام می‌شوند.

❌ معایب:

1. مشکل Single Point Of Failure: خرابی کلاستر کل بار کاری را متوقف می‌کند.
2. نبود ایزوله‌سازی کامل: برنامه‌ها از منابع مشترک استفاده می‌کنند و ریسک امنیتی ایجاد می‌شود.
3. مقیاس‌پذیری محدود: کلاسترهای Kubernetes نمی‌توانند به‌صورت بی‌نهایت بزرگ شوند.

۲. کلاسترهای کوچک تک‌منظوره

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

✅ مزایا:

1. کاهش دامنه خرابی: خرابی هر کلاستر فقط روی بار کاری همان کلاستر تأثیر می‌گذارد.
2. ایزوله‌سازی کامل: منابع سخت‌افزاری، شبکه و سرویس‌ها بین کلاسترها کاملاً جدا هستند.
3. دسترسی محدودتر: تعداد افراد دارای دسترسی به هر کلاستر کمتر است.

❌ معایب:

1. مصرف غیربهینه منابع: هر کلاستر نیاز به نودهای مدیریتی و منابع اختصاصی دارد.
2. هزینه بالا: اجرای چندین کلاستر هزینه بیشتری در پی دارد.
3. مدیریت پیچیده‌تر: نیاز به فرآیندهای خودکار برای مدیریت به‌روزرسانی‌ها و تنظیمات چند کلاستر.

۳. کلاستر به ازای هر برنامه

در این رویکرد، برای هر برنامه یک کلاستر جداگانه ایجاد می‌شود که تمام نمونه‌های برنامه (مانند نسخه Dev و Prod) در همان کلاستر اجرا می‌شوند.

✅ مزایا:

1. سفارشی‌سازی کلاستر برای برنامه: هر کلاستر می‌تواند بر اساس نیازهای برنامه خاص، مانند نودهای GPU یا پلاگین‌های CNI، تنظیم شود.

❌ معایب:

1. اختلاط محیط‌ها: نسخه‌های Dev و Prod یک برنامه در همان کلاستر اجرا می‌شوند و خرابی نسخه توسعه می‌تواند نسخه تولید را تحت تأثیر قرار دهد.

۴. کلاستر به ازای هر محیط

در این روش، به‌ازای هر محیط (مانند Dev، Test و Prod) یک کلاستر جداگانه ایجاد می‌شود که تمام برنامه‌های آن محیط در کلاستر مربوطه اجرا می‌شوند.

✅ مزایا:

1. ایزوله‌سازی محیط تولید: محیط تولید از مشکلات محیط‌های دیگر جداست و پایدارتر عمل می‌کند.
2. سفارشی‌سازی محیط: می‌توان کلاسترها را بر اساس نیازهای هر محیط بهینه کرد.
3. کنترل دسترسی به محیط تولید: می‌توان دسترسی به محیط تولید را محدود یا حتی حذف کرد.

❌ معایب:

1. نبود ایزوله‌سازی بین برنامه‌ها: برنامه‌های غیرمرتبط از منابع مشترک استفاده می‌کنند.
2. عدم تمرکز نیازهای ویژه: اگر یک برنامه نیاز خاصی مانند GPU داشته باشد، تمام کلاسترها باید این نیاز را تأمین کنند.

نتیجه‌گیری

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

انتخاب بهترین رویکرد به نیازهای شما بستگی دارد:

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

با توجه به سناریوهای بالا، می‌توانید مناسب‌ترین ترکیب را برای کسب‌وکار خود انتخاب کنید.

در بلاگ پست‌های بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد می‌گیریم.

مراقب خودتون باشید. 🌹🐳🌹

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

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊