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

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

Kubernetes

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

Kubernetes

etcd

Observability

• دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
• مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
• خودکارش کن، مشکلاتت حل می‌شه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.
• در مسیر دواپس این‌بار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
• در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
• در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
• در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
• در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویس‌هامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
• در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
• در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
• در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیس‌ها و تجربیات خودم رو گفتم.
• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.
• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.
• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.
• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.
• > معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپن‌تله‌متری دادیم.

• 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 در کوبرنتیز بررسی و راه‌حل‌های عملی ارائه می‌شود.&amp;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”&gt;گزینه‌های طراحی کلاستر Kubernetes با HA</p>

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

  =”rtl”>
  1. توپولوژی Control Plane با etcd استک‌شده (Stacked etcd Topology)
  2. توپولوژی Control Plane با etcd خارجی (External etcd Topology)&lt;/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 محدودیتی برای این انتخاب‌ها ایجاد نمی‌کند!

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

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

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

  

  </div></div>