Kubernetes چیست؟ – بخش دوم

اجزای سازنده کوبرنتیز و کارکردهای آنان

در حالی که برای راه‌اندازی برنامه‎‌ها و سرویس‎‌ها در Container، Kubernetes Cluster مکانیسم پیش فرض ما است، با این حال Kubernetes در لایه‌‎ی بالاتر این امکان را فراهم می‎کند که کاربر مدیریت بیشتر، در مقیاس پذیر بودن و انعطاف پذیر بودن کلاستر داشته باشد. به جای دسترسی مستقیم به Container جهت مدیریت، کاربر با اجزای مختلفی ارتباط برقرار می‎کند که در ابتدا توسط Kubernetes فعال می‎‌شود.

مفهوم پاد (Pods) در کوبرنتیز (Kubernetes) و عملکرد آن

ساده‌‎ترین واحدی که در Kubernetes با آن روبرو می‎‌شویم Podها هستند. در واقع Container به خود ماشین (سرور) تعلق ندارد، بلکه یک یا چند Container در یک Pod قرار دارند. در دید کلی یک Pod شامل یک یا چند Container است.

یک Pod یک یا چند Container را نشان می‎‌دهد که به عنوان یک اپلیکیشن یا سرویس شناخته می‎‌شوند. Podها شامل Containerهایی هستند که با یکدیگر کار می‎‌کنند و یک چرخه‎‌ی حیات دارند. همچنین همیشه آن‌ها باید در یک Node قرار بگیرند.

Podها به عنوان یک واحد، مدیریت می‌‎شوند و فضا، منابع و IP را با هم به اشتراک می‎‌گذارند. معمولا Podها شامل یک یا چند Container هستند که هدفشان این است که یک وظیفه را به خوبی انجام دهند و دیگر Containerها در صورت نیاز وظیفه‎‌ خود را انجام می‎دهند. سرویس و برنامه‎‌ها زمانی کار می‎کنند که Podها در حال اجرا باشند. به عنوان مثال در یک Pod ممکن است یک Container سرویس اصلی را اجرا کند و Container دیگر در Database تغییرات را اعمال و همچنین زمانی که منابع خارجی متصل می‎‌شوند، آن را شناسایی می‎کند.

نحوه‎ استفاده کاربر از پاد

مقیاس پذیری و گسترش توسط Podها در کلاستر به صورت افقی انجام نمی‎‌شود، زیرا در سطح بالاتر ابزارهای مناسب‎تری برای این کار وجود دارد.

کاربر نباید خودِ Pod را مدیریت کند زیرا در این صورت برخی از قابلیت‎هایی که به ما کمک فراوانی می‎کند مانند: مدیریت پیشرفته چرخه‎ حیات ، گسترش دادن و دسترسی پذیری بالا، فراهم نمی‎‌شود. در عوض کاربر باید از اجزای سطح بالاتر استفاده کند و قابلیت مورد نیاز خود را اضافه کند.

واحد کنترلر پادها (Replication Set) در کوبرنتیز

هنگامی که با Kubernetes کار می‎کنیم به جای مدیریت مستقیم و تکی Podها، ما گروه‎هایی از Podها را مدیریت می‎کنیم که شامل Podهای کپی شده هستند. ما از قالب آماده‎ی Podها استفاده می‎کنیم و Podها را به صورت افقی در Nodeهای کلاستر توزیع می‎کنیم (کپی می‎کنیم) که اینکار توسط Replication Controller و Replication Set انجام می‎شود.

Replication Controller ابزاری برای تعریف Pod است که کپی، توزیع یکسان، افزایش و کاهش Podهای در حال اجرا را بر عهده دارد. این یک راه آسان برای Load Balancing، افزایش و کاهش Podها در صورت افزایش حجم کاری در Kubernetes است. Replication Controller می‎داند که چگونه Podهای مورد نیاز را ایجاد کند؛ زیرا در پیکربندی خود یک template کپی شده از یک Pod دارد.

نحوه کارکرد Replication Controller

Replication Controller مطمئن می‎شود که تعداد Podهایی که در Node باید قرار بگیرد با تعداد Podهایی که در تنظیمات خودش است منطبق باشد. اگر Host یا Podهای در آن از بین برود، جهت جبران، Controller شروع به ساختن Podهای جایگزین می‎کند. اگر تعداد کپی‎‌ها در پیکربندی Controller تغییر کند، Controller بلافاصله شروع به اعمال تغییرات می‎کند (تعداد Podهای کپی شده را تغییر می‎دهد) مانند اضافه یا حذف کردن Podها. Replication Controller همچنین می‎تواند Podها را نیز به نسخه‎ جدید خود بروزرسانی کند.

Replication Set جهت جایگزین کردن با Replicatin Controller ایجاد می‌شود.

Replication Set برخلاف Replication Controller قابلیت Rolling Update، چرخه‌ی بروزرسانی Podها را ندارد، در عوض Replication Set درسطح بالاتر این ویژگی‌ها را فراهم می‎کند.

چرا به بخش دیپلویمنت (Deployment) نیاز داریم؟ – شباهت‎‌ها و تفاوت‎‌ها

Deployment یکی از رایج‌‎ترین و پرکاربردترین اشیاء برای مدیریت در کلاستر است. Deployment با استفاده از Replication Set، ساختن Blockها، مدیریت چرخه‎ حیات و انعطاف پذیری را برای ما به ارمغان می‎‌آورد.

به نظر می‎‌رسد Deployment و Replication Set عملکرد تکراری مشابه Replication Controller داشته باشند اما Deployments مشکلاتی را که در Rolling Update وجود داشت را حل کرده است. هنگام بروزرسانی Application توسط Replication Controller، کاربر باید یک template برای Replication Controller ایجاد کند تا Replication Controller جدید جایگزین Controller جاری شود. هنگام استفاده از Replication Controller انجام کارهایی نظیر بررسی تاریخچه، جستجو در شبکه جهت بروزرسانی، دریافت تغییرات مثبت، دریافت خطا، دریافت تغییرات منفی و مخرب و همچنین  بازگردانی آنها با Replication Controller بسیار دشوار و حتی غیرممکن است.

مفهوم کلی دیپلویمنت (Deployment)

Deployment یک شیء سطح بالاست که به منظور تسهیل مدیریت چرخه‎ حیات برای Podهای کپی شده در کلاستر طراحی شده است. پیکربندی Deployment را به راحتی می‎‌توان تغییر داد و تعداد Replica Setها را تنظیم کرد. به دلیل وجود این ویژگی‏‎‌ها Deployment ابزار بسیار پرکاربردی است که در Kubernetes با آن اغلب کار می‎‌کنید.

کرون جاب‎‌ها (Cron Jobs) – چند کار در یک زمان

مواردی که ما تاکنون توصیف کردیم، همه چرخه‎ حیات طولانی‌مدت برنامه‎‌ها را شامل می‎‌شد. Kubernetes با استفاده از یک شیء به نام Job (یک ویژگی که بیشتر  task-based است) Containerهای در حال اجرا را پس از پایان کار با موفقیت خارج می‎‌کند. اگر شما نیاز به انجام یک‌باره‎ کارها داشته باشید به جای یک بار اجرا از Job استفاده می‎‌کنید.

Jobs از روی Cron Jobs ایجاد می‎‌شود، مانند اسکریپت‎‌های اجرایی Cron در سیستم عامل لینوکس. Kubernets جهت برنامه‌ریزی  Cron Jobs رابطی را برای آن ارائه می‎دهد که می‌تواند برای زمان‌بندی Jobs جهت اجرا در آینده یا به صورت منظم استفاده شود. Kubernetes Cron Jobs اساسا یک پیاده‌سازی از Cron کلاسیک است که بسیار برای ما سودمند و پرکاربرد است.

دیگر اجزای Kubernetes

ما در کلاستر بیشتر از این می توانیم مانور دهیم و از قابلیت‌های بی‌نظیر آن استفاده کنیم. Kubernetes امکانات بیشتری برای ما دارد تا برنامه‌ها، شبکه و پایداری کلاستر را مدیریت و کنترل کنیم. ما برخی از موارد را ذکر خواهیم کرد.

مفهومی دیگر بر اصطلاح Services – کارکرد Services چیست؟

تا الان ما اصطلاح “Service” را در معنای پرکاربرد خود و در سیستم عامل Unix، برای نشان دادن فرایندهای طولانی مدت، فرایندهای اجرایی در شبکه که پاسخگوی کاربر برای درخواست‎ها هستند می‎شناسیم. با این حال در Service ،Kubernetes جزئی است که Load Balancer اولیه‎ی داخلی را در مسیر درست به Pod مورد نظر هدایت می‎کند. یک سرویس شامل گروه‎هایی منطقی از Podها هستند که با هم یک عملکرد را دارند. به عنوان مثال: Web Service، Mail Service.

Service به شما اجازه می‎دهد تا مسیر مناسب برای رسیدن به Container مناسب فراهم گردد. در داخل کلاستر تنها نیاز است نقطه پایدار ارائه شده­ را به سرویس بدهیم. در عین حال Service به شما اجازه‎ی گسترش یا جایگزینی را در Backend در صورت نیاز می‎دهد. یک Service’s IP بدون در نظر گرفتن تغییرات در Podها مسیریابی آن را انجام می‎دهد. با اجرا و عملیاتی سازی Service، شما به راحتی می‎توانید ساختار Containerها را تغییر دهید.

چه زمانی باید Service را پیکربندی کرد؟

هر زمان ما و Client نیاز به دسترسی به Podها از خارج کلاستر را داشته باشیم، لازم است که Service را پیکربندی کنیم. به عنوان مثال اگر ما Podهایی داریم که سرویس NGINX بر روی آن‎ها در حال اجرا است و نیاز داریم که از اینترنت قابل دسترسی باشد، Service این امکان را برای ما فراهم می‎کند. به همین ترتیب اگر Web Service ما نیاز داشته باشد که از یک Database اطلاعاتی را بخواند یا بنویسد، ما باید یک “Internal Service” را پیکربندی کنیم تا Web Service ما دسترسی لازم را داشته باشد.

علاوه‌ بر اینکه سرویس‎‌ها به صورت پیش‌فرض تنها از داخل با یک آدرس IP مسیریابی می‎شوند و در دسترس هستند، همچنین ما می‎توانیم با اجرای چند استراتژی از بیرون کلاستر، این دسترسی را فراهم کنیم. پیکربندی Node Port که به صورت استاتیک Port را برای ارتباط خارج کلاستر باز می‎کند، ترافیک مورد نظر به port خارجی توسط IP آدرس اختصاص داده شده به صورت اتوماتیک به Pod مورد نظر هدایت می‎شود.

سرویس Load Balancer نوعی از سرویس است که وظیفه‎ی Load Balancing خارجی را جهت هدایت به سرویس با استفاده از Load Balancer شرکت ارائه دهنده‎ی خدمات ابری بر عهده دارد. Cloud Controller Manager منابع مناسب را ایجاد و پیکربندی می‎کند.

نحوه مدیریت فایل‎‌ها و فضای ذخیره سازی در کوبرنتیز – Persistent Volumes

پایداری، قابل اعتماد بودن داده‎ها، اشتراک گذاری داده‎ها و اطمینان از قابل دسترسی بودن در زمانی که Containerها restart می‎شوند، چالش بسیار مهمی است. زمان‌بندی اجرای Containerها جهت اتصال دائمی یا موقت Storage، مکانیزم‎‌هایی دارد، اما معمولا در پیاده سازی انعطاف لازم را ندارد. پاسخ Kubernetes این است که از فضایی استفاده می‎‌کند که تمام Containerهای درون Podها اطلاعات خود را در آن ذخیره و به اشتراک بگذارند. این به این معنی است که Podهایی که با هم در ارتباط هستند می‎‌توانند به راحتی و بدون مکانیزم‎‌های خارجی، فایل‎‌ها و داده‎‌های خود را به اشتراک بگذارند. هنگامی که Container همراه با Pod از بین می‎رود، دیگر امکان دسترسی به فایل‎‌ها وجود ندارد. در واقع زمانی که یک Pod از بین می‎رود دیتای او نیز از بین می‎‌رود؛ بنابراین این یک راه‌حل مناسب جهت نگهداری فایل‌‎ها به صورت مداوم نیست.

Persistent Volumes یک مکانیزم برای تخصیص فضای ذخیره سازی پایدار است که به چرخه‎ حیات Pod وابسته نیست. در عوض این امکان به کاربر اجازه می‎دهد که فضای ذخیره سازی را طوری پیکربندی کند که Podهای در حال اجرا به آن دسترسی داشته باشند و دیتا را به صورت دائمی در آن ذخیره کنند. هنگامی که یک Pod با یک Persistent Volumes ادغام می‎شود، سیاست نگهداری دیتا تعیین می‎کند که تا چه زمانی دیتا نگهداری یا به صورت خودکار حذف شود. همچنین برای داده‎‌های مهم و دائمی می‎توانیم از فضاهای ذخیره سازی Local برای ذخیره‌سازی نیز استفاده کنیم.

برچسب گذاری (Labeling) در کوبرنتیز به چه معناست؟

در Kubernetes مفهومی به نام Labeling وجود دارد. یک Label در Kubernetes به این معنا است که می‎تواند اشیاء Kubernetes را به صورت گروهی یا تکی انتخاب کند. بعد از انتخاب این اشیاء می‎توانیم جهت اهداف مدیریتی و تغییرات از آن استفاده کنیم. به عنوان مثال هر Controller در Kubernetes برای انجام عملیات بر روی Podها از Labels استفاده می‎کند. Serviceها برای شناسایی و مسیریابی به Podها در backend از Labels استفاده می‎کند.

Labelها دارای جفت کلید ساده‎ای هستند. هر شیء می‎تواند بیش از یک Label داشته باشد اما هر شیء می‎‌تواند تنها یک ورودی برای کلید باشد. معمولا یک کلید “name” به عنوان شناسایی شیء قرار می‎گیرد، اما ما می‎توانیم اشیا را با دیگر معیارها نظیر: deployment stage ,public accessibility ,application version و etc شناسایی کنیم.

Annotation یک مکانیزم مشابه است که به شما اجازه می‎دهد تا key-value (اطلاعات دلخواه) را به یک شیء اضافه کنید. در حالی که Label’sها باید برای اطلاعات درست که برای Podها است استفاده شوند. Annotation آزادی بیشتری در انتخاب در ساختار Kubernetes دارد.

نتیجه ‎گیری

Kubernetes یک پروژه ی فوق العاده و هیجان‌انگیز است که به کاربر اجازه می‌دهد تا حجم بالایی از فرایندهای container را در یک پلتفرم بسیار پایدار اجرا کند. معماری Kubernetes و اجزای داخلی آن می‎تواند در ابتدا دشوار به نظر برسد، اما قدرت انعطاف پذیری و ویژگی‎های موجود در Kubernetes بی نظیر هستند. با درک این که چگونه اجزای Kubernetes با هم کار می‎کنند، می‎توانید شروع به طراحی سیستم‎هایی کنید که به طور کامل قابلیت‎های پلتفرم را اجرا و مدیریت کند و چگونه در مقیاس بزرگتر به طور کامل عملیاتی شود.