در قسمت قبل با کوبرنتیز آشنا شدیم و فهمیدیم کوبرنتیز چه کارهایی را برای ما انجام می‌دهد. در این قسمت ابتدا با معماری کوبرنتیز و سپس با اجزای مختلف آن آشنا می‌شویم.
کوبرنتیز از حداقل یک کنترل کننده (Control Plane) و یک ماشین کارگر (که به آن Node یا Worker Node گفته می‌شود) تشکیل شده است. کنترل کننده که بیشتر فرآیندهای (Processes) کوبرنتیز در آن اجرا می‌شوند؛ نقش
مدیریت؛ نظارت و هماهنگی کار بین گره‌های کارگر(Worker Node) را دارد که برنامه ما را اجرا می‌کنند و بیشتر منابع سخت افزاری را در اختیار دارند زیرا اجرای برنامه اصلی بر عهده همین نودهای کارگر است و کنترل کننده تنها بر درستی و سالم بودن و دیگر موارد هماهنگ کننده بین این نودها از قبیل تست‌ها و ... نظارت می‌کند.
نودها سرور ها یا ماشین های مجازی هستند و از اجزای زیر تشکیل شده اند:
پاد (Pod)
پاد کوچکترین قسمت نودهای کارگر هستند که یک لایه Abstraction به کانتینر ها اضافه می‌کند و در اصل بستر اجرای ایمیج‌ها؛ کانتینرها است و معمولا در هر پاد تنها یک کانتینر اجرا می‌شود. و اضافه شدن این لایه باعث می‌شود پیچیدگی های سطح کانتینر در کوبرنتیز وارد نشود. هر پاد زمانی که اجرا می‌شود یک IP جدید می‌گیرید و این در جایی مشکل ساز می‌شود که یک از پادهای دچار خطا می‌شود و یک پاد دیگر را جایگزین آن می‌کنیم. در این صورت باید در اجزای دیگر که با این پاد در ارتباط هستند IP جدید را بروزرسانی کنیم.
سرویس (Service)
برای حل کردم مشکل عوض شدن IP پادها سرویس ها استفاده می‌شوند. سرویس ها IP های ثابتی هستند که به یک پاد متصل می‌شوند و با از بین رفتن یک پاد سرویس از بین نمی‌رود و پاد جایگزین شده به این سرویس متصل شده و در این صورت پادهای ما همواره IP های ثابتی دارند که با از بین رفتن و جایگزین شدن پادها تغییر نمی‌کنند.
کیوبلت (kubelet)
کیوبلت‌ها ایجنت‌هایی هستند که اطمینان حاصل می‌کنند تا کانتینر ها درون پادها به درستی اجرا می‌شوند و همچنین ارتباط بین Node های مختلف را ممکن می‌سازند.
کانفیگ مپ (ConfigMaps)
برای توضیح این کامپوننت از یک مثال استفاده می‌کنیم. فرض کنید یک برنامه دارید که دیتا های خود را درون یک دیتابیس ذخیره می‌کند. پس باید آدرس این دیتابیس را درجایی ذخیره کنیم. اگر این آدرس را داخل ایمیج ساخته شده قرار دهیم و در زمانی دیگر آدرس دیتابیس تغییر کند ما مجبور می‌شویم ایمیج ساخته شده را دوباره بیلد کنیم و در داخل ریپازیتوری قرار دهیم و سپس این ایمیج را از ریپازیتوری برداریم. برای رفع این مشکل یک کامپوننت با نام ConfigMap در کوبرنتیز وجود دارد که به ما این امکان را می‌دهد تا دیتاهای تغییرپذیر و خارجی مانند آدرس دیتا بیس را در آن ذخیره کنیم و در صورت تغییر این داده ها تنها این داده ها را تغییر داده و نیازی به فرآیندهای بیلد و پوش کردن ایمیج نباشد.
(secret)
حال در همان مثال بالا حالتی را در نظر بگیرید که می‌خواهید نام‌کاربر و رمز دیتابیس که آن ها نیز تغییر پذیرند را در جایی ذخیره کنید از آن جایی که ConfigMap تنها برای دیتاهای غیرمحرمانه است کامپوننت دیگری به نام secret وجود دارد که می‌توان داده‌های با حساسیت بالاتر را در آن ها ذخیره کرد.
kube-apiserver
این ماژول؛ در حقیقت ماژول ارتباطی ما با کوبرنتیز است که ما می‌توانیم با API یا UI یا CLT بسته به نوع استفاده (برای مثال داشبورد یا استفاده از اسکریپت‌های اتوماتیک) از آن استفاده کنیم.
kube-scheduler
این کامپوننت پادهای جدید را که داری نود نیستند در نود ها قرار می‌دهد. برای مثال فرض کنید دو نود داریم که یکی از 60 درصد منابعش استفاده کرده است و دیگری از 20 درصد منابع در این صورت این کامپوننت پاد جدید به وجود آمده را در داخل نودی که منابع بیشتری دارد قرار می‌دهد.
etcd
این کامپوننت دیتاهای کلاستر های ما را نگه داری می‌کند. و کلاستر ها از این دیتا ها برای برای بازسازی در زمانی که خطا رخ می‌دهند استفاده می‌کنند.
kube-controller-manager
این کامپوننت تغییرات داخل کلاستر را دنبال می‌کند و مدیریت می‌کند.مثلا اگر کانتینری نیاز به تعمیر داشته باشد یا خراب شده باشد آن را درست یا جایگزین می‌کند.
در این قسمت درباره قسمت‌های اصلی کوبرنتیز صحبت کردیم و اجزای اصلی کنترل‌کننده و Node های آن را به صورت مختصر مورد بررسی قرار دادیم. در قسمت بعد پیاده سازی یک k3s را با هم انجام می‌دهیم.
