
Kubernetes چیست؟ – بخش دوم
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 با هم کار میکنند، میتوانید شروع به طراحی سیستمهایی کنید که به طور کامل قابلیتهای پلتفرم را اجرا و مدیریت کند و چگونه در مقیاس بزرگتر به طور کامل عملیاتی شود.