ملوانی با کوبرنتیز (قسمت سوم) – معماری کوبرنتیز

لیست شماره های پیشین:


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


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

Master NodeWorkers Node

همونطور که از اسامی مشخصه، کوبرنتیز دارای دو بخش master و worker عه. بخش master کارش مدیریت کلاستر و کار بخش worker، اجرای فرامین master هست و عملا جایی هست که نرم افزارها و پایگاه داده ها و سرویس های ما اجرا میشن.


اجزای بخش Master در کوبرنتیز:

  • kube-apiserver:
    • این بخش عملا تنها بخشی از کوبرنتیز هست که به ما امکان گفتگو با غولی به نام کوبرنتیز رو میده. تمام دستوراتی که قراره به کوبرنتیز بدیم از طریق این گذرگاه رد میشه.

  • etcd:
    • تمام داده هایی که مرتبط با کلاستر ما هست توی این پایگاه داده key/value ذخیره میشه. مثلا تصور کنید که به کوبرنتیز گفتیم برامون ۱۰۰ تا کانتینر رو ران کنه. کوبرنتیز بعد از گذشت چندین ماه از این دستور ما، چون توی etcd ذخیره کرده که باید از container X دقیقا ۱۰۰ تا Instance ران باشه پس حواسش هست که دقیقا ۱۰۰ تا ران باشه!

  • kube-scheduler:
    • کارش اینه که مشخص میکنه کانتینرها باید کجاها اجرا بشن. مثلا فرض کنید یک کلاستر دارید با ۱۰۰۰ تا سرور. بهش میگید برای من از نرم افزار ‌X به اندازه ۱۰ تا کانتینر اجرا کن. خب این ها بر چه اساسی باید توی این ۱۰۰۰ تا سرور پخش بشن؟ اینجاست که kube-scheduler وارد کار میشه و با توجه به یک سری پارامتر که ما بهش گفتیم و یا بر اساس وضعیت سرورها مشخص میکنه این ۱۰ تا کانتینر دقیقا باید روی چه worker هایی یا همون سرورها ران بشه.

  • kube-controller-manager:
    • وقتی ما میگیم برامون از این image به این تعداد و با این مشخصات و با این ارتباطات و با این volume ها و … اجرا کن،‌ یکی باید باشه که همیشه حواسش جمع باشه که تو کلاستر همون چیزی که ما ازش خواسته بودیم در حال اجرا شدنه. اینجاست که kube-controller-manager وارد کار میشه. حواسش به همه چیز هست که طبق خواسته ما رفتار کنه. حالا این که ما چه چیزهایی از کوبرنتیز میتونیم بخوایم که برامون انجام بده و kube-controller-manager باید حواسش به اون ها باشه، بحثیه که جلوتر و در پست های آتی بهش میرسیم.

اجزای بخش Worker در کوبرنتیز:

  • kubelet:
    • روی همه worker ها اجرا میشه. مسئول مدیریت هر worker همین kubelet هستش. یعنی حواسش هست اون worker کارهاشو درست انجام بده. هر وقت master کوبرنتیز یک فرمانی رو تو کلاستر صادر میکنه، kubelet ها گوش به فرمانن و روی هر worker که مسئولیتشو به عهده دارن فرمان ها رو اجرا میکنن.

  • kube-proxy:
    • وظیفه اش مدیریت اوضاع شبکه و دسترسی به container ها در هر worker میباشد. البته این موضوع مفصل و بزرگیه که باید جداگانه بهش بپردازیم ولی فعلا در همین حد که بدونیم در نهایت چه کار میکنه کافیه 🙂 ولی به زودی یک مطلب مفصل درباره شبکه در کوبرنیتز خواهم نوشت،‌ چون مقوله خیلی بزرگ و مفصلیه و کلی نکته و بخش داره.

  • Container Runtime:
    • برای ایجاد کردن و ساختن و اجرا کردن container های لینوکسی نیازمند یک engine هستیم. مثلا docker یا rkt یا ..


یک مثال واقعی از درخواست راه اندازی یک کانتینر در کوبرنتیز (توی کوبرنتیز به پایه ای ترین ماهیت که کانتینرها توش قرار میگیرن، میگن Pod. به زودی در پست بعدی درباره ماهیت ها و object های مختلفی که تو کوبرنتیز برای کارکردن وجود داره توضیح میدم):

شما به api کوبرنتیز خبر میدید که میخوام یک پاد درست کنم (یعنی میخوام یک کانتینر ران کنم). api کوبرنتیز اول بررسی میکنه درخواستمون درست باشه، و اگر اکی بود به etcd خبر میده و ذخیره‌اش میکنه. هر وقت که با موفقیت ذخیره شده، api کوبرنتیز به Scheduler خبر میده که یک worker خوب برای اجرای container پیدا کنه.هر وقت که یک چیز خوب پیدا کرد به api کوبرنتیز خبر میده. مجدد api کوبرنتیز روی etcd مینویسه. هر وقت که با موفقیت روی etcd نوشته شد،‌api کوبرنتیز به kubelet مربوطه خبر میده که باید چه کار کنه الان. kubelet هم به container eninge روی سرور که مثلا docker باشه خبر میده که کانتینر رو این شکلی ران کن. وقتی که docker تونست اقدامات مربوطه رو انجام بده به kubelet خبر میده و kubelet هم مجدد به api کوبرنتیز خبر میده. و خب همونطور که میتونید حدس بزنید مجدد api کوبرنتیز به etcd میگه بنویس که الان وضعیت به چه صورته. (تصویر و چند خط بالا از این مقاله برگرفته شده.) – تمام این event ها از طریق لاگ های کوبرنتیز قابل رویته. به زودی توی راه اندازی نرم افزارها همه این ها رو به صورت عملی خواهیم دید.


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


خب توی مطلب بعدی میخوایم به معرفی آبجکت ها و اجزایی که کوبرنتیز برای کار با سرویس ها و نرم افزار ها داره بپردازیم. همچنین دو سه تا سرویس واقعی اجرا کنیم که ببینیم چی میشه.

امیدوارم حالتون خوب باشه هر جا که هستین 🙂

بازدیدها: 5

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *