Common Concepts in Kubernetes
Pic. No. 1 - Kubernetes Architecture |
در این پست به معرفی اجمالی تعدادی از اصطلاحات رایج در kubernetes می‌پردازم:
Node
Pod
Service
Replication Controller
Deployment(+Replica Set)
Selector
Job
ThirdPartyResource
ConfigMap
Pod
مجموعه‌ای از { یک یا بیشتر container (مثلا docker container) + حافظه مشترک برای اون‌ها + گزینه‌هایی در مورد چگونگی اجرا شدنشون } است. میتونیم بهش به شکل یک «logical host» با کاربرد خاص منظوره نگاه کرد - که شامل یک یا چند application container هست که به هم وابسته هستند و اگه جدا از دنیای containerها میخواستیم اجراشون کنیم، باید روی یک سیستم فیزیکی یا روی یک ماشین مجازی اجرا میشدن.
Containerهای داخل یک pod، در یک آدرس IP و یک فضای port یکسان مشترکند و میتونن به همدیگه از طریق localhost دسترسی داشته باشن. همچنین میتونن از طریق IPC یا Inter-process communication (مثل POSIX Shared Memory) با هم ارتباط داشته باشن. Containerهایی که تو pod های مختلف هستند، IP مجزا دارند و به همین خاطر نمی‌تونن از این طریق با هم در ارتباط باشن.
پادها در واقع واحد‌های deployment، horizontal scaling و replication هستند.
نکته دیگه اینکه co-scheduling، shared fate، coordinated replication، resource sharing، و dependency management برای containerهای داخل یک pod به صورت اتوماتیک هندل میشه.
Service
همونطور که گفتیم به هر پاد یک آی‌پی نسبت داده میشه که بقیه پادها از اون طریق باهاش صحبت می‌کنن. از اون‌جایی که Podها موجودات فانی هستند، وقتی بمیرن، حتی اگه دوباره زنده بشن(توسط replication controllerها که بعدا توضیح میدم) تضمینی نیست که آی‌پی قبلیش بهش داده بشه. بدتر از اون، در طول حیاتش هم معلوم نیست که همیشه یه آی‌پی ثابت داشته باشه! پس بقیه پادها چجوری میتونن آدرسش رو پیدا کنن؟
اینجاست که نقش سرویس‌ها نمایان میشه! سرویس مفهومی هست که یک logical set از podها و سیاست دسترسی بهشون رو تعریف میکنه- که گاهی بهش microservice هم گفته میشه.
مجموعه پادهایی که مورد هدف یک سرویس هستند با Label Selector مشخص میشن.
Node
نود‌ها در واقع worker machineها در یک کلاستر هستند. یک نود ممکنه یک ماشین مجازی یا فیزیکی باشه(بسته به کلاستر). هر نود سرویس‌های مورد نیاز برای اجرای پاد‌های داخلش رو داره. سرویس‌های روی یک نود عبارتند از : Docker، kubelet، kube-proxy
Kubelet : کار مدیریت پادها و containerها، imageها ، volumeها و ...شون رو به عهده داره.
Kube-proxy: هر نود یک network proxy ساده و یک load balancer رو در خودش داره.
Replication Controller(rc)
میتونیم به وسیله rcها مطمئن شیم که همیشه یه تعداد مشخص(که ما تعیین میکنیم) از podها در حال اجرا هستند. و مثلا اگه یکی بمیره، یکی دیگه رو جایگزینش میکنه به صورت خودکار!
Replica Set(rs)
میشه گفت نسل بعدی rcها هستند که تنها تفاوتشون اینه که rs، از new set-based selector requirements پشتیبانی میکنه اما rc فقط equality-based selector requirements رو!
Rsها خودشون هویت مستقل هم دارند اما معمولا امروزه توسط deployment به عنوان مکانیزمی برای هماهنگی و مدیریت ایجاد، حذف و تغییر پادها استفاده می‌شود.
Deployment
در نسخه‌های جدید از deployment برای مدیریت آپدیت‌ها و پادها از طریق Replica Set (به جای استفاده مستقیم از rcها )استفاده می‌شود. همچنین به کمک آن می‌توان عملیات roll back به deployment قبلی را در صورت unstable بودن استقرار کنونی، انجام داد.
Selector
برخلاف name و UID، برچسب‌ها (Labelها) یکتایی ندارند. برعکس، معمولا انتظار داریم که تعدادی object، یک برچسب یکسان داشته باشند.
به کمک Label Selector، هر client/user میتونه مجموعه‌ای از objectها رو identify کنه. در واقع ابزار اصلی گروه‌بندی objectها، selector است.
در حال حاضر دو نوع Selector پشتیبانی میشه : equality-based و set-based
Job
یک Job، یک یا چند پاد ایجاد میکنه و اطمینان ایجاد میکنه که یه تعداد مشخص از اون‌ها حتما خاتمه پیدا کنند. وقتی اون تعداد معلوم از پادها تکمیل بشه کارشون، کار job هم تموم شده. حذف کردن یک Job، پادهایی که اون بوجود آورده رو پاک میکنه.
(ThirdPartyResources(TPR
میشه بهشون به چشم شمای جدول پایگاه داده (database table schema) نگاه کرد؛ وقتی که جدول رو ایجاد کنید، از اون به بعد میتونید row بهش اضافه کنید.
به طرز مشابه وقتی TPRها ساخته‌میشن، میتونن مثل data model پشت کنترلر‌ها و یا automation programs رفتار کنند.
خود kubernetes ، یه سری API برای استفاده در اختیار میذاره. ولی خیلی وقت‌ها دقیقا اون چیزی نیست که شما میخواید. TPR objectها راهی برای بسط دادن APIهای Kubernetes به یک API Object Type جدید و مورد‌نظر هستند.
ConfigMap
در خیلی از کاربرد‌ها نیاز به configuration (پیکربندی) به کمک config fileها، آرگومان‌های command line، و متغیر‌های محیطی است. این ابزار‌های کانفیگ کردن باید به صورت جدا از container imageها استفاده بشن که ایمیح‌ها بتونن به صورت portable استفاده بشن. در همین راستا ConfigMap API مکانیزم‌هایی برای اعمال کردن پیکربندی به داده‌های container ارائه میکنه که در عین حال اون رو به kubernetes وابسته نکنه.
