معرفی اجزاء و معماری کوبرنتیز

معرفی اجزاء و معماری کوبرنتیز

کوبرنتیز (Kubernetes) یک پلت فرم متن باز برای استقرار و مدیریت کانتینرها است. این نرم افزار برای ما نقش هماهنگ کننده کانتینر، ایجاد محیط Runtime برای کانتینر، هماهنگ سازی زیرساخت کانتینر محور، تعادل کننده بار، مکانیسم‌های خود ترمیمی و کشف خدمات را ارائه می‌دهد. به کمک کوبرنتیز می‌توانید عملیات ترکیب، مقیاس پذیری، استقرار و مدیریت کانتینرها و برنامه‌های کاربردی را در سراسر کلاستر‌ها انجام دهید. 

اجزای اصلی یک زیرساخت مبتنی بر کوبرنتیز شامل موارد زیر است: control plane  (قسمت مدیریتی کوبرنتیز)، یک سیستم ذخیره سازی key-value توزیع شده برای ثابت نگه داشتن حالت کلاستر (etcd) که در حقیقت نقش بانک اطلاعاتی برای ثبت کلیه اطلاعات و وضعیت کلاسترها را برعهده دارد و نهایتا نودهای کلاستر که به آنها نودهای کارگر (worker nodes) می گویند 

کلاستر کوبرنتیز شکلی از معماری نرم افزار کوبرنتیز است. معماری پایه کوبرنتیز دو بخش دارد: نودهای مدیریتی و نود‌ها یا ماشین های محاسباتی. هر نود می‌تواند یک ماشین فیزیکی یا مجازی باشد که داری محیط مجزا برای لینوکس خودش داشته باشد. هر نود پادهایی (PODs) را اجرا می‌کند که از کانتینرها تشکیل شده‌ است. درواقع پاد، کوچکترین مولفه اجرایی در دنیای کوبرنتیز محسوب می شود.

بخش مدیریتی (Control Plane) از چندین جزء متفاوت تشکیل شده است که عملیات مهم و مدیریتی کلاستر کوبرنتیز را دربر می گیرند. اجزای این بخش عبارتند از : سرور اصلی کوبرنتیز API، سرور زمانبندی کوبرنتیز scheduler، سرور کنترل کننده controller manager و سرور بانک اطلاعاتی etcd است. در بخش نودهای اجرایی، می توانیم اجزایی از قبیل موتور اجراکننده کانتینر (CRE) یا داکر، یک اجنت برای ارتباط با سرور اصلی کوبرنتیز با نام Kubelet را مشاهده کنیم و همچنین سرویس مدیریت شبکه و پراکسی که بنام kube_proxy از آن یاد می شود.

در ادامه بصورت اجمالی تر به معرفی بخش های مختلف کوبرنتیز خواهیم پرداخت:

بخش مدیریتی (Control Plane)

بخش مدیریتی، مغز فرماندهی و تصمیم گیری کوبرنتیز هست که اجزای معماری کلاستر کوبرنتیز را در خود جای داده و کلاستر را مدیریت و کنترل می‌کند. این بخش همچنین یک رکورد داده از پیکربندی‌ها و وضعیت تمام اشیاء کلاستر کوبرنتیز، نگهداری می‌کند. این بخش دائما در تماس با ماشین‌های محاسباتی است تا اطمینان حاصل شود که کلاستر طبق پیکربندی انجام شده، اجرا می‌شود. این بخش به تغییرات کلاستر پاسخ می‌دهند تا وضعیت‌ اشیاء را مدیریت و وضعیت واقعی، مشاهده شده یا وضعیت فعلی اشیاء سیستم را برای مطابقت با وضعیت یا مشخصات مورد نظر هدایت کنند. 

چندین مؤلفه اصلی در این قسمت کنترل می‌شود: سرور API، زمانبند‌ها، controller-manager، و etcd. این اجزای اصلی تضمین می‌کنند که کانتینرها با منابع لازم به تعداد کافی کار می‌کنند. همه این اجزا می‌توانند روی یک گره اصلی اجرا شوند، اما با توجه اهمیت تحمل پذیری خطا، آنها در چندین نود تکرار می‌شوند تا دسترسی بالایی داشته باشند. لذا طراحی و پیاده سازی معماری صحیح و توزیع پذیر و پایدار از control plane بسیار حائز اهمیت می باشد.

• سرور API کوبرنتیز 

این قسمت بخش ابتدایی در control plane کوبرنتیز است، سرور API از به روز رسانی‌ها، مقیاس بندی‌ها، و انواع دیگر هماهنگ سازی چرخه حیات مولفه‌ها مطلع است و نقش رابط ارتباطی تمام زیرسرویس ها را برعهده دارد.؛ کلاینت‌ها باید بتوانند از خارج از کلاستر به سرور API دسترسی داشته باشند، این بخش به عنوان دروازه عمل می‌کند و هماهنگی چرخه حیات را در هر مرحله پشتیبانی می‌کند. کلاینت‌ها از سرور API به عنوان تونلی برای ارتباط با پادها، سرویس‌ها و نود‌ها استفاده می‌کنند. همچنین آن‌ها به کمک همین بخش برای دسترسی به منابع مورد نیاز در کلاستر احراز هویت می‌شوند.

• زمانبند کوبرنتیز

زمانبند کوبرنتیز میزان استفاده از منابع برای هر گره محاسباتی را تعیین می‌کند و تعیین می‌کند که آیا کانتینرهای جدید باید مستقر شوند و اگر چنین است، کجا باید قرار گیرند. این بخش سلامت کلاستر را به طور کلی در کنار میزان درخواست استفاده از منابع، مانند CPU یا حافظه، قرار می‌دهد. سپس یک نود محاسباتی مناسب را انتخاب می‌کند و سپس پاد یا سرویس را با در نظر گرفتن محدودیت‌ها یا تضمین‌های منابع، محل داده‌ها، کیفیت خدمات مورد نیاز، مشخصات anti-affinity  - وابستگی، و سایر فاکتورهای مورد نیاز؛ برنامه‌ریزی و اجرا می‌کند. 

• Controller Manager

کنترل‌کننده‌های مختلفی در اکوسیستم کوبرنتیز وجود دارند که وضعیت نقاط پایانی endpoint (شامل پاد و سرویس‌ها)، توکن‌ها و حساب‌های سرویس (شامل namespace)، نود‌ها و نسخه‌های تکثیر شده replication (که به کمک مقیاس‌سازی خودکار autoscaling ایجاد شده‌اند) را هدایت می‌کنند. Controller manager - که گاهی اوقات کنترلر نامیده می‌شود یک نسخه daemon است که کلاستر کوبرنتیز را با استفاده از چندین عملکرد کنترل کننده اجرا می‌کند.

کنترلر اشیایی را که در کلاستر مدیریت می‌کند، در حین اجرای حلقه های کنترلی اصلی نظارت می‌کند. از طریق سرور API وضعیت مورد نظر و وضعیت فعلی آنها را مشاهده می‌کند؛ اگر وضعیت فعلی و مورد نظر اشیاء مدیریت شده مطابقت نداشته باشند، کنترلر اقدامات اصلاحی را انجام می‌دهد تا وضعیت اشیاء را به سمت وضعیت مطلوب هدایت کند. کنترلر کوبرنتیز همچنین عملکرد چرخه حیات اصلی را انجام می‌دهد.

• ETCD

etcd یک پایگاه‌داده توزیع‌شده، تحمل‌پذیر در مقابل خطا و متن باز است، داده‌ها بصورت key-value در داخل دیتابیس ذخیره می‌شوند، این داده‌های ذخیره شده مربوط به پیکربندی‌ها و اطلاعات مربوط به وضعیت کلاستر است. etcd ممکن است به صورت خارجی پیکربندی شود، اگرچه اغلب به‌صورت بخشی از control plane در کلاستر کوبرنتیز نصب و راه اندازی می‌شود.

etcd وضعیت کلاستر را بر اساس الگوریتم اجماع Raft ذخیره می‌کند، به کمک این روش با مشکلی رایج که در حالت تکراری (replicated state) بر روی ماشین‌ها ایجاد می‌شود، مقابله می‌شود و منجر می‌شود که چندین سرور بر روی مقادیر مشترک توافق می‌کنند. مدلRaft  سه نقش مختلف را تعریف می‌کند: رهبر، نامزد و پیرو، که با انتخاب رهبر به اجماع می‌رسد. به این ترتیب etcd به عنوان منبع یکتا حقیقی (single source of truth (SSOT)) برای همه اجزای کلاستر کوبرنتیز عمل می‌کند، به پرسش‌های قسمت control plane پاسخ می‌دهد و پارامترهای مختلف وضعیت کانتینرها، نود‌ها و پادها را بازیابی می‌کند. etcd همچنین برای ذخیره جزئیات پیکربندی مانند ConfigMaps، subnets و Secrets به همراه داده‌های وضعیت کلاستر استفاده می‌شود. 

معماری کلاستر کوبرنتیز

نودهای کلاستر که توسط بخش control plane مدیریت می‌شوند، ماشین‌هایی هستند که کانتینرها را اجرا می‌کنند. هر نود یک عامل (agent) را برای برقراری ارتباط با قسمت مدیریتی اجرا می‌کند، kubelet - کنترل کننده اولیه کوبرنتیز است. هر نود همچنین یک موتور اجرا کانتینری (CRE) مانند داکر یا rkt را اجرا می‌کند. یک نود همچنین اجزای اضافی را برای نظارت، ثبت گزارش، کشف سرویس و موارد اضافی اختیاری اجرا می‌کند.

در ادامه بخش ورکر نودها را نیز مورد بررسی قرار خواهیم داد:

• نودها

یک کلاستر کوبرنتیز باید حداقل یک نود محاسباتی داشته باشد، اگرچه بسته به نیاز به ظرفیت ممکن است تعداد زیادی نود وجود داشته باشد. پادها، هماهنگ و برنامه ریزی می‌شوند تا بر روی نودها اجرا شوند، بنابراین نودهای بیشتری برای افزایش ظرفیت کلاستر مورد نیاز است. نودها کارهای یک کلاستر کوبرنتیز را انجام می‌دهند. آنها برنامه‌ها و شبکه، منابع محاسباتی و ذخیره سازی را به یکدیگر متصل می‌کنند. نودها ممکن است ماشین‌های مجازی بومی ابری (VM) یا سرورهای فیزکی مجزا (bare metal) واقع در مراکز داده باشند.

• CRE

هر نود محاسباتی چرخه‌ عمر کانتینر را با استفاده از یک موتور اجرا کانتینر مدیریت و شروع می‌کند. کوبرنتیز از موتور اجرای کانتینر سازگار با Open Container Initiative مانند Docker، CRI-O و rkt پشتیبانی می‌کند.

• سرویسKubelet 

هر نود محاسباتی شامل یک kubelet است، عاملی که با control plane ارتباط برقرار می‌کند تا اطمینان حاصل شود که کانتینرهای یک پاد در حال اجرا هستند. هنگامی که control plane نیاز به انجام یک عمل خاص در یک نود داشته باشد، kubelet مشخصات پاد را از طریق سرور API دریافت کرده و عملیات را اجرا می‌کند. سپس تضمین می‌کند که کانتینترهای مرتبط سالم و در حال اجرا هستند.

• سرویس Kube-proxy 

هر نود محاسباتی دارای یک پروکسی شبکه به نام kube-proxy است که خدمات شبکه در کوبرنتیز را تسهیل می‌کند. این سرویس می‌تواند خودش ترافیک را ارسال کند یا به کمک لایه فیلتر سیستم عامل مدیریت ارتباطات شبکه را در خارج و داخل کلاستر مدیریت کند. 

Kube-proxy بر روی هر نود اجرا می‌شود تا اطمینان حاصل شود که سرویس‌ها برای طرف‌های خارجی در دسترس هستند و با زیرشبکه میزبان جداگانه در ارتباط است. این سرویس به عنوان یک پروکسی شبکه و متعادل کننده بار سرویس در داخل نود عمل و مسیریابی شبکه را برای بسته‌های UDP و TCP مدیریت می‌کند. در واقع، kube-proxy ترافیک را برای تمام نقاط پایانی سرویس هدایت می‌کند.

• پادها

تاکنون مفاهیمی را ارائه شده که داخلی و زیرساختی هستند. در مقابل، پادها برای کوبرنتیز اهمیت زیادی دارد زیرا ساختار اصلی هستند که توسعه دهندگان مستقیم با آن‌ها تعامل دارند. یک پاد یک نمونه از یک برنامه کاربردی و ساده ترین واحد را در اجزای کوبرنتیز دارد. با این حال، پادها برای کوبرنتیز مرکزی و حیاتی هستند. هر پاد از یک یا چند کانتینر به هم پیوسته تشکیل شده است که به طور منطقی با هم هماهنگ می‌شوند، همراه با قوانینی که نحوه عملکرد کانتینرها را کنترل می‌کنند. پادها طول عمر محدودی دارند و در نهایت پس از ارتقا یا کاهش حجم از بین می‌روند. با این حال، اگرچه پادها زودگذر (ephemeral) هستند، اما پادها می‌توانند برنامه‌های stateful را با اتصال به ذخیره‌سازی دائمی اجرا کنند. پادها همچنین قادر به مقیاس پذیری خودکار افقی هستند، به این معنی که می‌توانند تعداد نمونه های در حال اجرا افزایش یا کاهش یابد. آنها همچنین می‌توانند به روز رسانی‌های چرخشی و استقرار قناری را انجام دهند.

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

با ایجاد مجموعه‌های تکراری (replica sets) که با حفظ مداوم مجموعه‌ای از پادها از پیش تعریف‌شده انجام می‌شود، مقیاس‌ پذیری پادها در زمان اجرا را تضمین می‌شود. به کمک این مجموعه این اطمینان حاصل می‌شود که همیشه تعداد مورد نظری از پادها در یک deployment اجرا می‌شود. سرویس‌ها می‌توانند یک پاد یا یک مجموعه ازreplica  را در برای مصرف کنندگان خارجی یا داخلی در دسترس قرار دهند.