KUBERNETENS

کوبرنتیز (Kubernetes) در‌ واقع ساز و کار مدیریت کانتینر ها است که توسعه آن را شرکت معظم گوگل انجام داده است و در نتیجه سلاطین فناوری و توسعه‌دهندگان، علاقه زیادی به استفاده از کوبرنتیز نشان می‌‌دهند. کوبرنتیز (Kubernetes‎) نرم افزاری متن باز برای ارکستراسیون برنامه های کانتینربیس هست.
به زبان go نوشته شده و ۶ ژوئن ۲۰۱۴؛ ۶ سال پیش با لایسنس آپاچی ۲ منتشر شده. وب سایتش kubernetes.io . معنیش هم به یونانی معنی سکاندار، خلبان، راننده و ... هست.

ارکستراسیون یعنی چی ؟

یعنی کانفیگ اتوماتیک، هماهنگی و مدیریت، نرم افزار ها. حالا ارکستراسیون توی کوبرنتیز چیه ؟ بخش کانفیگ اتوماتیک، هماهنگی و مدیریت کانتینر ها میشه همین اورکستراسیون. یعنی کوبرنتیز به شما توی کانفیگ و مدیریت و هماهنگی کانتینتر هاتون کمک میکنه.

کوبرنتیز، کجا ها استفاده میشه ؟

اکثر شرکت هایی که از معماری microservice استفاده میکنن، احتمالا از کوبرنتیز هم استفاده میکنن. بیشتر جا هایی که از کانتینر و داکر خبری هست، احتمالا k8sهم اون جا حضور داره

کانتینر ها و Vm ها چه هستند ؟

کانتینر ها و Vm ها در هدفشون یکسان هستن : ایزوله کردن یک برنامه یا application و نیازمندی هاش درقالب یک واحد بسته بندی شده که بتونه هرجایی اجرا بشه.

اگر بیشتر بخوایم بدونیم container ها و Vm ها نیاز ما به سخت افزار فیزیکی رو حذف میکنن ، اجازه میدن که استفاده کارآمد تری از منابع داشته باشیم و در واقع صرفه جویی در انرژی و هزینه رو تجربه کنیم تفاوت اصلی Container و Vm در رویکرد معماریشون هست.

ماشین های مجازی چی هستند؟

ماشین مجازی در واقع یک شبیهسازی از کامپیوتر واقعی هست که مثل یک کامپیوتر واقعی application هارواجرا میکنه.

Vm ها روی یک کامپیوتر فیزیکی توسط Hypervisor ران میشن. Hypervisor یک مدل از مجازی سازی سخت افزاری یا ) hardware virtualization ( هست که به شما امکان اجرا از چندین سیستم عامل guest را در یک زمان روی یک سیستم host را فراهم میکنه

. که در این حالت سیستم عامل های مجازی نصب شده همانند هر سیستم عامل واقعی امکان استفاده از منابع سخت افزاری موجود درسیستم مانند CPU و یا

hardو ram رو داره. Hypervisor در حقیقت اشاره به تامین نیازمندی های سخت افزاری سیسم عامل های guest و مدیریت ارتباط بین اونا و میزان استفادشون از منابع سخت افزاری رو داره. از Hypervisor با عنوان دیگری هم نام برده میشه Vmm نام داره و مخفف کلمات virtual machine manager میباشد و دراصل هر دو به یک موضوع اشاره دارند.

در واقع هر guest machine دارای خود application فایل های مورد نیاز از قبیل سیستم عامل فایلای باینری و دیپندنسی هاش و در واقع شامل همه چیه ماشین مجازی دارای منابع کاملا اختصاصی خودش هست اینجا مشخص میشه که وقتی میگیم ماشین مجازی در واقع یک کامپیوتر واقعی هست یعنی چی VirtualBox VMware Workstation 8 مجازی ساز های معرفی هستن که احتمالا باهاشون کار کردین.همان‌‌گونه که شما بهتر از ما می‌دانید رایانش ابری نیازهای جدیدی را در دنیای سخت‌افزار و نرم‌افزار ایجاد کرد و شاهد نسل جدیدی از فناوری‌ها بودیم که تعامل با رایانش ابری را ساده‌تر می‌کردند. اپلیکیشن‌های بزرگ نیز به سمت ماژولار شدن پیش رفتند تا مدیریت و تعامل با آن‌ها از جانب توسعه‌دهندگان و کاربران ساده‌تر شود

در واقع میتوان گفتContainer ظرفی است کهImage ها را در آن

اجرا میکنند. Container ها از رویImage ها ایجاد میشوند و به

وظایف خود عمل میکنند. مثلا فرض کنید از یک Centos چندContainer میسازیم و در هر کدام تغییرات متفاوتی اعمال میکنیم.

در همین راستا گوگل به عنوان یکی از بزرگترین غول‌های فناوری که حیات خود را مدیون رایانش ابری است به این فکر افتاد تا یکی از پروژه‌های بزرگ خود را که در داخل این مجموعه از آن استفاده می‌کرد به صورت متن باز منتشر کند. این پروژه از زیرساخت‌هایی بر اساس کانتینرها بهره می‌گرفت و در داخل گوگل با نام BROG شناخته می‌شد.

کوبرنتیز نیز به‌سرعت راه خود را به جوامع فناوری باز کرد و به رقیب بزرگی برای ساز و کارهای دیگر کنترل کانتینرها مانند Apache Mesos و Docker Swarm تبدیل شد.

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

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

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

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

کوبرنتیز قابلیت‌های فنی زیادی را در اختیار توسعه‌دهندگان قرار می‌دهند که در این بین می‌توان به امکان بررسی سلامت و تکثیر برنامه‌ها در مجموعه سرورهای یک مجموعه اشاره کرد. قابلیت تشخیص سرویس‌ها، تعادل حجم‌بار (Load Balancing) و مدیریت تنظیمات برای ایجاد سیستم‌هایی که از فناوری معماری Microservice Architecture بهره می‌برند اشاره کرد.

هرکجا که صحبت از کوبرنتیس به میان می‌آید اشاره‌ای به داکر نیز می‌شود و این دو پلتفرم به‌عنوان رایج‌ترین ابزارها برای مدیریت کانتینرها شناخته می‌شوند، به این ترتیب کاملاً طبیعی است این سؤال برای توسعه‌دهندگان پیش بیاید که داکر بهتر است یا کوبرنتیز؟

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

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

در مجموع می‌‌توان گفت داکر و کوبرنتیز به لحاظ امکانات تفاوت‌هایی با هم دارند اما این تفاوت‌ها بسته به نیاز یک مجموعه اهمیت پیدا می‌کند و به همین دلیل بسیاری از توسعه‌دهندگان کوبرنتیز را به دلیل قابلیت‌های ماژولار آن انتخاب می‌کنند.

چرا به کوبرنتیز نیاز داریم و چه کاربردی برای ما به همراه دارد؟

Container ها روشی مناسب برای دسته بندی اپلیکیشن ها و اجرای آن ها هستند. در یک production environment، شما باید container هایی که برنامه ها را اجرا می‌کنند، مانیتور نمایید تا از عدم وجود خرابی یا downtime در آن ها اطمینان حاصل کنید. به عنوان مثال، اگر یک کانتینر از کار بیفتد، به کانتینر دیگری نیاز خواهیم داشت تا اجرا شود. این درحالی است که، اگر ما بخواهیم این روند را توسط یک سیستم انجام دهیم به شکل ساده تر و آسان تری می‌توان را اجرا نماییم.

کوبرنتیز تکنولوژی است که در چنین موقعیت هایی ما به آن نیاز خواهیم داشت تا بتواند چنین عملیاتی را انجام دهد. کوبرنتیز یک چارچوبی را برای اجرای سیستم های توزیع شده (distributed) به شکل منعطف در اختیار ما می‌گذارد. این تکنولوژی از scaling و failover اپلیکیشن مراقبت می کند و الگوهای استقرار (deployment patterns) را ارائه می‌دهد تا در کنار آن بتواند canary deployment را برای سیستم شما مدیریت کند.

کوبرنتیز ارائه دهنده قابلیت های متنوعی است که عبارتند از:

Service Discovery و Load Balancing

با کوبرنتیز می توانیم یک container را با استفاده از Name DNS یا IP address ، نمایش دهیم. اگر ترافیک به یک کانتینر زیاد باشد، کوبرنتیز قادر است Load Balancing را انجام دهد و ترافیک شبکه را توزیع کند تا استقرار پایدار و stable باشد.

Storage Orchestration

کوبرنتیز به شما این امکان را می دهد تا به طور خودکار سیستم ذخیره سازی مورد نظر خود را مانند Local Storages، Public Cloud Providers و موارد دیگر را نصب نمایید.

Automated Rollbacks and Rollouts

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

Automated Bin Packing

شما به کوبرنتیز یک کلاستری از نودها را می‌دهید تا بتواند از طریق آن، containerized tasks را انجام دهد. همچنین می‌توان به کوبرنتیز دستورات مختلفی را بدهید تا هر container چه مقدار CPU و حافظه (RAM) نیاز داشته باشد. این تکنولوژی نوین می‌تواند containerها را بر روی node ها قرار دهد تا از منابع به بهترین شکل استفاده شود.

Self-Healing

کوبرنتیز containerهای fail شده را مجدداً راه اندازی می کند، container ها را جایگزین می کند و container هایی را که به درستی کار نمی‌کنند را خاموش می‌نماید.

Secret and Configuration Management

کوبرنتیز این امکان را می دهد تا اطلاعات مهمی مانند passwords، tokens OAuth و SSH keys ذخیره و مدیریت شوند. می توان کانفیگ های برنامه ها را که مهم و سری هستند، بدون بازسازی container images مستقر و update نمایید.

· کوبرنتیز یک سیستم PaaS (Platform as a Service) سنتی و all-inclusive نیست. از آنجا که کوبرنتیز در سطح container کار می‌کند و نه در سطح سخت افزار، برخی از ویژگی های کلی را که همانند offering PaaS هستند ارائه می‌دهد مانند deployment، مقیاس پذیری، Load Balancing و ... و همچنین به کاربران این اجازه را می‌دهد تا راهکارهایlogging ، مانیتورینگ و alerting خود را یکپارچه کنند. با این حال، کوبرنتیز یکپارچه نیست و این راهکارها پیش فرض، optional و pluggable هستند.

· کوبرنتیز building blocks را برای ساخت پلتفرم های توسعه دهندگان فراهم می‌کند، اما user choice و user flexibility را در جایی که مهم و حیاتی است حفظ می‌نماید.

· اپلیکیشن هایی که ساپورت می‌‌شوند را محدود نمی‌کند و از انواع workloads، مانند stateless، stateful وdata-processing پشتیبانی می‌کند. می‌توان این نتیجه گیری را داشته باشیم که اگر یک اپلیکیشن بتواند در یک container اجرا شود، پس بر روی کوبرنتیز به خوبی اجرا خواهد شد.

· کوبرنتیز Source code را deploy نمی کند. ادغام، تحویل و استقرار مداوم (Continuous Integration, Continuous Delivery, Continuous Deployment) workflows به عنوان الزامات فنی و فرهنگ های سازمانی است که باید رعایت شوند.

· کوبرنتیز سرویس های application-level، مانند middleware (message buses)، data processing frameworks (Spark)، پایگاه های داده (MySQL)، caches و سیستم های cluster storage (Ceph) را ارائه نمی دهد. این کامپوننت ها می توانند روی کوبرنتیز اجرا شوند و یا از طریق مکانیسم های portable (مانند Open Service Broker)، به برنامه هایی که روی کوبرنتیز در حال اجرا هستند، دسترسی کاملی داشته باشید.

· کوبرنتیز راهکارهای logging، monitoring و alerting را dictate نمی کند و برخی از integrationها را به عنوان proof of concept و مکانیسم هایی جهت جمع آوری و export، metrics فراهم می‌نماید.

· کوبرنتیز نمی‌تواند زبان / سیستم configuration (Jsonnet) را ارائه‌ دهد. اما declarative API را ارائه می دهد که ممکن است به اشکال مختلفی از خصوصیات declarative، از آن استفاده شود.

· هیچگونه machine configuration جامع، maintenance، مدیریت و یا سیستم های self-healing را ارائه نمی دهد و اتخاذ نمی‌‌کند. علاوه بر این، کوبرنتیز صرفا یک سیستم orchestration نیست. در حقیقت، این سیستم نیاز به orchestration را برطرف می کند. اگر بخواهیم تعریف فنی از orchestration داشته باشیم، اجرای یک گردش کار (workflow) خواهد بود: یعنی ابتدا تسک A، سپس B و در نهایت تسک C را انجام می‌دهد. در مقابل، کوبرنتیز شامل مجموعه ای از فرآیندهای کنترل مستقل و composable است که بطور مداوم وضعیت فعلی (current state) را به حالت مورد نظر (desired state) تغییر می‌دهد. فرقی ندارد که چگونه از A به C می‌خواهیم برویم یا حتی لزومی بر استفاده از کنترل متمرکز(centralized control) داشته باشیم، کوبرنتیز این کارها را برای ما انجام می‌دهد!

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

بررسی معماری Kubernetes

Kubernetes ارتباط خود را با ماشین‎های مجازی یا ماشین‎های فیزیکی از یک شبکه‎ی اشتراکی مانند “Flannel ” که در هر ماشین وجود دارد برقرار می‌کند. در شبکه‎ی کلاستریKubernetes، تمامی اجزا، قابلیت‎ها و Workloadها پیکربندی می‎شوند. هر ماشین در اکو سیستم Kubernetes یک وظیفه و نقش را بر‌ عهده دارد.

· Master

یک ماشین (سرور) در کلاستر به انتخاب ما باید به عنوانMaster در نظر گرفته شود. این سرور با ایجاد یک IP برای مدیر سیستم، راه ورود به کلاستر و مدیریت آن را باز می‎کند. علاوه بر این، تست سلامت و پایداری دیگر سرور‎ها، تعیین نقش و همچنین ارکستراسیون بین اجزای مختلفKubernetes را برعهده دارد.

در واقع سرور Master نقطه اصلی ارتباط با کلاستر است و مدیریت و نظارت متمرکز در سراسر سیستم Kubernetes را فراهم می‎کند.

· Node

دیگر ماشین‎هایی که در کلاستر Kubernetes ایجاد می‎شوند سرور Node نام دارند. این سرورها وظیفه‎ی اجرا کردن بارِ کاری را با استفاده از منابع داخلی یا خارجی برعهده دارند. Node برای کمک به ایزوله سازی، مدیریت و انعطاف پذیری Kubernetes برای اجرای اپلیکیشن‎ها و سرویس‎ها از Container استفاده می‎کند، بدین ترتیب هر ماشینNode در کلاستر نیاز به دارا بودن به یک سیستم و نرم افزار کانتینری مانندDocker یا rkt Node است. در کلاستر دستور العمل‎ها را از سرور Master دریافت می‎کند و بر اساس تنظیمات، کانتینرها را ایجاد یا آن‎ها را حذف می‎کند و همچنین تنظیمات مناسب شبکه‎ی کلاستر و مسیریابی ترافیک را انجام می‌دهد.

· Container

همانطور که اشاره شد، اپلیکیشن‎ها و سرویس‎های ما در کلاسترKubernetes با کاینتر اجرا می‎شوند. کاربر جهت تعامل با کلاستر از IP سرور اصلی، کلاینت و یا کتابخانه استفاده می‎کند. برای اجرای اپلیکیشن‎ها یا سرویس‎ها، یک برنامه اعلامیه در فایل‎های JSON یا Yaml ارائه می‎شود که مشخص‌کننده این است که چه چیزی باید ایجاد شود و چگونه باید آن را مدیریت کرد. سرور Master، فایل برنامه را می‎گیرد (JSON یا Yaml) و چگونگی اجرای آن در زیرساخت را با بررسی شرایط و وضعیت فعلی سیستم مشخص می‎کند. این گروه از برنامه‎های تعریف شده توسط کاربر که بر اساس یک نقشه خاص اجرا می‎شوند، نتیجه‎ی نهایی Kubernetes را نشان می‎دهند.

اجزای سرور Master

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

جایگاه etcd در Kubernetes

etdc یک جزء مهم Kubernetes جهت ذخیره‌سازی و نگهداری فایل‎های پیکربندی کلاستر است. پروژه‎ی etcd توسط تیم Core Os توسعه داده شده است که بسیار سبک بوده و یک مکانی جهت نگهداری Key-Valueها است که می‎تواند در سراسر کلاستر وNodeها توزیع شود. Kubernetes از etcd برای نگهداری فایل‎ها و داده‎های پیکربندی کلاستر استفاده می‎کند که قابل دسترسی توسط هر Node در کلاستر است. این سرویس می‎تواند جهت جستجوی سرویس‎ها، پیکربندی یا پیکربندی مجدد خودشان جهت بروز نگه‌داشتن اطلاعات استفاده شود.

Kube apiserver، مدیریت Kubernetes

یکی دیگر از سرویس‎های مهم در سرور Api-server ،Master است. این نقطه‎ی اصلی مدیریت و ورود به Kubernetes است که به کاربر اجازه می‎دهد Kubernetes را پیکربندی کند. در واقع kube-apiserver پلی بین اجزای مختلف با هدف نگهداری و حفظ سلامت کلاستر و انتشار اطلاعات و اجرای دستور عمل‌ها است.

api server یک رابط RESTfull ایجاد می‎کند که به این معنی است که بسیاری از ابزارها و کتابخانه‎ها به راحتی می‎توانند با آن ارتباط برقرار کنند.

راه ارتباطی کاربر نیز از طریق ابزار Kubectl مهیا می‎شود که به صورت پیش فرض در سیستم وجود دارد.

وظایف سرویس Kube Controller Manager

Kube Control Manager سرویسی است که وظایف زیادی دارد از جمله:

· کنترل کننده‎های وضعیت کلاستر

· چرخه‎ی حیات کلاستر

· و …

به عنوان مثال یک Replication-Controller تضمین می‎کند که تعداد کپی‎ها (نسخه های یکسان) درست تعریف شده یا تعداد مورد نظر Podها در کلاستر یکی باشند و به درستی در کلاستر قرار بگیرند. جزئیات این عملیات در etcd نوشته می‎شود، جایی که Controller Manager برای تغییرات به آن نگاه می‎کند. زمانی که تغییرات در کلاستر ایجاد می‎شوند، Controller اطلاعات جدید را می‎خواند و دستوری را اجرا می‎کند.

وظیفه فرایند Kube Scheduler چیست؟

Kube-Scheduler فرایندی است که در واقع مسئولیت و وظیفه را به Nodeهای خاص در کلاستر اختصاص می‎دهد. این سرویس شرایط عملیاتی را می‎خواند. همچنین تجزیه و تحلیل محیط زیرساخت فعلی و جایگزین را انجام داده و وظایف را به Node قابل قبول واگذار می‌کند. Scheduler مسئول بررسی ظرفیت موجود در هر Node است تا مطمئن شود که حجم کاری اختصاص داده شده بیش از منابع موجود نباشد. Schedular باید ظرفیت کل و همچنین منابعی که قبلا در هر سرور اختصاص داده شده است را بشناسد.

اجزای سرور Node

در Kubernetes سرورهایی که Container روی آن ها کار می کنند به عنوان Node شناخته می شوند. سرورهای Node دارای چندین الزام هستند که برای ارتباط با اجزای اصلی کلاستر و پیکربندی شبکه و اجرای Workload اختصاص یافته به آنها ضروری است.

نقش Container در سرورهایNode

اولین جزء در هر Node باید یک Container همیشه در حال اجرا باشد. به طور معمول این نیاز با نصب و راه اندازی Docker برطرف می‎شو. همچنین گزینه‎های دیگری نظیر rkt و runc وجود دارند.

Kubelet، راه ارتباطی میان Node وMaster

نقطه تماس اصلی برای هر Node با کلاستر سرویس Kubelet است. این سرویس مسئول انتقال اطلاعات (دستور) به سرویس‎های کنترل کلاستر است و از طریق آن در ارتباط با etcd Data Base برای خواندن جزئیات پیکربندی یا نوشتن مقادیر جدید استفاده می‎کند. سرویس Kubelet در هر Node با اجزای اصلی کلاستر سرور Master ارتباط برقرار می‎کند تا در کلاستر احراز هویت شود و دستورات و وظایف را از سرور Master دریافت کند.

فرایند Kubelet مسئول نگهداری و دریافت وظایف است. در این زمان Containerها توسط فرمان‎های رسیده از سرور Master ایجاد یا حذف می‎شوند.

Kube proxy چه نقشی را ایفا می‎کند؟

برای مدیریت شبکه و زیرشبکه (subnet) هر سرور در کلاستر و فعال‌سازی سرویس‎های دیگر، یک سرویس کوچک به نام Kube-Proxy در هر Node ایجاد می‎شود. این فرایند، درخواست ارتباطی را به Container مورد نظر داده و می‎تواند Load Balance اولیه را انجام داده و و مطمئن شود که شبکه‎ی کلاستر در دسترس و قابل پیش‌بینی و همچنین ایزوله است.