XaaS Cloud Computing Loading ...
X
درخواست شما ثبت شد

درخواست شما با موفقیت ثبت شد. گروه پشتیبانی ما درخواست شما را بررسی و در اسرع وقت با شما تماس خواهند گرفت

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

Kubernetes چیست؟

Kubernetes Objects and Workloads

در حالی که برای راه اندازی برنامه ها و سرویس ها در Kubernetes کلاستر، Container مکانیسم پیش فرض ما است، با این حال 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 Controller and 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 مطمئن می شود که تعداد Pod هایی که درNode باید قرار بگیرد با تعداد Pod هایی که در تنظیمات خودش است منطبق باشد. اگر Host یا Pod های در آن از بین برود جهت جبران، Controller شروع به ساختنPod های جایگزین می کند. اگر تعداد کپی ها در پیکربندی Controller تغییر کند Controller بلافاصله شروع به اعمال تغییرات می کند( تعداد Pod های کپی شده را تغییر می دهد) نظیر: اضافه یا حذف کردن Pod ها. Replication Controller همچنین می تواند Pod ها را نیز به نسخه ی جدید خود بروزرسانی کند.

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

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

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





Deployments

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

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

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



Jobs and Cron Jobs

مواردی که ما تا کنون توصیف کردیم، همه چرخه ی حیات طولانی مدت، برنامه ها را شامل می شد. Kubernetes با استفاده از یک شئ به نام Jobs یک ویژگی بیشترکهtask-based است،Container های در حال اجرا را پس از پایان کار با موفقیت خارج می کند. اگر شما نیاز به انجام یکباره ی کارها را داشته باشید به جای یک بار اجرا از jobs استفاده می کنید.

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


دیگر اجزای Kubernetes

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


Services

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

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

هر زمان ما و 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 منابع مناسب را ایجاد و پیکربندی می کند.


Volumes and Persistent Volume

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

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




Label’s and Annotation

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

Labels ها دارای جفت کلید ساده ای هستند. هر شئ می تواند بیش از یک Label’s داشته باشد اما هر شئ می تواند تنها یک ورودی برای کلید باشد. معمولا یک کلید"name" به عنوان شناسایی شئ قرار می گیرد، اما ما می توانیم اشیا را با دیگر معیار ها نظیر: deployment stage, public accessibility, application version و etc شناسایی کنیم.

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



نتیجه گیری

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




پایان بخش دوم