kubelet چیست؟ بررسی وظایف و نحوه کار

kubelet (کیوب‌لت) عامل اصلی نود در کلاستر کوبرنتیز است که روی هر نود اجرا می‌شود. این مؤلفه مجموعه‌ای از مشخصات پاد (PodSpec) را از سازوکارهای مختلف دریافت می‌کند و اطمینان می‌دهد کانتینرهای تعریف‌شده در این مشخصات در حال اجرا و سالم باشند.

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

جایگاه kubelet در معماری کوبرنتیز

در معماری کوبرنتیز، kubelet یکی از اجزای نود (Node Components) است و روی هر نود کلاستر اجرا می‌شود. اجزای نود وظیفه دارند پادهای در حال اجرا را مدیریت کنند و محیط اجرای کوبرنتیز را روی نود فراهم سازند. بنابراین، kubelet در معماری کلاستر در گروه اجزای نود قرار می‌گیرد.

تفاوت اجزای نود با اجزای کنترل‌پلین

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

تفاوت Kubelet و kube-proxy

kubelet و kube-proxy هر دو از اجزای نود هستند، اما وظایف متفاوتی دارند. kubelet اطمینان می‌دهد کانتینرهای تعریف‌شده در PodSpec در حال اجرا و سالم باشند. در مقابل، kube-proxy یک پروکسی شبکه است که بخشی از مفهوم Service در کوبرنتیز را پیاده‌سازی می‌کند و قواعد شبکه را روی نودها نگه می‌دارد. این قواعد امکان برقراری ارتباط شبکه‌ای با پادها را از نشست‌های داخل یا خارج کلاستر فراهم می‌کنند

kubelet چگونه کار می‌کند؟

kubelet مجموعه‌ای از مشخصات پاد را دریافت می‌کند. پس از اینکه Scheduler در کوبرنتیز یک پاد را به نود اختصاص داد، kubelet با استفاده از محیط اجرای کانتینر (Container Runtime)، ایجاد کانتینرهای آن پاد را آغاز می‌کند.

kubelet مشخصات پاد را برای محیط اجرای کانتینر ترجمه می‌کند و برای ارتباط با این مؤلفه از رابط Container Runtime Interface یا CRI استفاده می‌کند. بنابراین، kubelet خودش مسئول اجرای مستقیم کانتینرها نیست؛ بلکه با محیط اجرای کانتینر برای ایجاد و مدیریت آن‌ها ارتباط برقرار می‌کند.

kubelet این فرایند را در یک حلقه تطبیق دوره‌ای ادامه می‌دهد. در این حلقه، وضعیت مطلوب تعریف‌شده در PodSpec با وضعیت واقعی کانتینرهای در حال اجرا مقایسه می‌شود تا وضعیت مورد انتظار پاد حفظ شود.

kubelet چگونه مشخصات پاد را دریافت می‌کند؟

کیوب‌لت PodSpecها را از چند سازوکار دریافت می‌کند. سازوکار اصلی، دریافت PodSpec از API Server است. علاوه بر آن، kubelet می‌تواند مانیفست پاد را از فایل‌های موجود در مسیری مشخص بخواند یا آن را از یک HTTP Endpoint دریافت کند. فایل‌ها و HTTP Endpoint به‌صورت دوره‌ای برای تغییرات بررسی می‌شوند.

ارتباط kubelet با API Server

kubelet می‌تواند نود را در API Server ثبت کند و مشخصات پادها را هم عمدتا از API Server دریافت می‌کند. فایل kubeconfig هم نحوه اتصال kubelet به API Server را مشخص می‌کند. پس از دریافت مشخصات پادهای اختصاص‌یافته به نود، kubelet از این اطلاعات برای مدیریت کانتینرهای مربوط به آن‌ها استفاده می‌کند.

ارتباط kubelet با محیط اجرای کانتینر و CRI

kubelet اجرای مستقیم کانتینرها را بر عهده نمی‌گیرد. این مؤلفه PodSpec را برای محیط اجرای کانتینر ترجمه می‌کند و از این محیط برای ایجاد و مدیریت کانتینرهای پاد استفاده می‌کند.

ارتباط kubelet با محیط اجرای کانتینر از طریق رابط Container Runtime Interface یا CRI انجام می‌شود. محیط اجرای کانتینر باید با CRI سازگار باشد تا kubelet بتواند درخواست‌های مربوط به اجرای کانتینرها را با آن در میان بگذارد.

مهم‌ترین وظایف kubelet چیست؟

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

اطمینان از اجرای سالم کانتینرها

kubelet مجموعه‌ای از مشخصات پاد را دریافت می‌کند و اطمینان می‌دهد کانتینرهایی که در این مشخصات تعریف شده‌اند، در حال اجرا و سالم باشند. محدوده مسئولیت آن هم به کانتینرهای ایجادشده توسط کوبرنتیز محدود است و کانتینرهایی را که خارج از مدیریت کوبرنتیز ایجاد شده‌اند، مدیریت نمی‌کند.

ایجاد کانتینرهای پاد روی نود

پس از اینکه Scheduler یک پاد را به نود اختصاص می‌دهد، kubelet ایجاد کانتینرهای آن را با استفاده از محیط اجرای کانتینر آغاز می‌کند. بنابراین، پس از مرحله زمان‌بندی، kubelet در نود انتخاب‌شده فرایند لازم برای اجرای کانتینرهای پاد را دنبال می‌کند.

اجرای پروب‌های سلامت کانتینر

پروب (Probe) یک عملیات تشخیصی است که kubelet آن را به‌صورت دوره‌ای روی کانتینر اجرا می‌کند. kubelet می‌تواند بر اساس نتیجه پروب‌ها واکنش نشان دهد.

سه نوع پروب در کوبرنتیز وجود دارد:

• Startup Probe: شروع‌شدن برنامه داخل کانتینر را بررسی می‌کند. تا زمانی که این پروب با موفقیت اجرا نشود، پروب‌های Liveness و Readiness اجرا نمی‌شوند.
• Liveness Probe: مشخص می‌کند که آیا کانتینر باید ری‌استارت شود یا نه.
• Readiness Probe: مشخص می‌کند که کانتینر برای دریافت ترافیک آماده است یا نه. اگر این پروب شکست بخورد، آدرس IP پاد از EndpointSliceهای سرویس‌های منطبق حذف می‌شود.

مدیریت ری‌استارت کانتینرها

kubelet ری‌استارت کانتینرها را بر اساس restartPolicy تعریف‌شده در PodSpec مدیریت می‌کند. این سیاست برای پاد می‌تواند یکی از سه مقدار زیر باشد:

• Always: کانتینر پس از هر خاتمه دوباره راه‌اندازی می‌شود.
• OnFailure: کانتینر فقط در صورتی دوباره راه‌اندازی می‌شود که با خطا خاتمه یافته باشد.
• Never: کانتینر خاتمه‌یافته به‌صورت خودکار دوباره راه‌اندازی نمی‌شود.

وقتی kubelet بر اساس این سیاست کانتینری را دوباره راه‌اندازی می‌کند، این کار برای ایجاد کانتینر جایگزین در همان پاد و روی همان نود انجام می‌شود. این فرایند به معنای زمان‌بندی دوباره پاد روی نودی دیگر نیست.

مشارکت در خاتمه پاد

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

اگر برای کانتینر یک هوک preStop تعریف شده باشد و مقدار terminationGracePeriodSeconds صفر نباشد، kubelet ابتدا این هوک را اجرا می‌کند. سپس از محیط اجرای کانتینر می‌خواهد سیگنال TERM را به فرایند اصلی هر کانتینر ارسال کند. بسیاری از محیط‌های اجرای کانتینر، در صورت تعریف‌شدن مقدار STOPSIGNAL در Image، به‌جای TERM از همان سیگنال استفاده می‌کنند.

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

kubelet چه کارهایی را انجام نمی‌دهد؟

kubelet مسئول اجرای کانتینرهای تعریف‌شده در PodSpec روی نود است، اما جایگزین Scheduler، محیط اجرای کانتینر یا kube-proxy نیست. مرز مسئولیت‌های kubelet را می‌توان به شکل زیر خلاصه کرد:

• مدیریت کانتینرهای خارج از کوبرنتیز: kubelet کانتینرهایی را که توسط کوبرنتیز ایجاد نشده‌اند، مدیریت نمی‌کند. مسئولیت آن به کانتینرهایی مربوط می‌شود که در مشخصات پادهای دریافت‌شده تعریف شده‌اند.
• انتخاب نود برای پاد: kubelet تعیین نمی‌کند پاد روی کدام نود اجرا شود. انتخاب نود برای پادهایی که هنوز به نودی اختصاص داده نشده‌اند، بر عهده Scheduler است. kubelet پس از اختصاص پاد به نود، اجرای آن را روی همان نود دنبال می‌کند.
• اجرای مستقیم کانتینرها: kubelet جایگزین محیط اجرای کانتینر نیست. kubelet برای ایجاد و مدیریت کانتینرهای پاد با محیط اجرای کانتینر ارتباط برقرار می‌کند.
• مدیریت قواعد شبکه و رفتار Service: کیوب‌لت وظایف kube-proxy را انجام نمی‌دهد. kube-proxy بخشی از مفهوم Service را پیاده‌سازی می‌کند و قواعد شبکه را روی نودها نگه می‌دارد.

پیکربندی kubelet چگونه انجام می‌شود؟

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

ساخت فایل پیکربندی kubelet

فایل پیکربندی kubelet باید نمایش JSON یا YAML از پارامترهای ساختار KubeletConfiguration باشد و kubelet هم باید مجوز خواندن این فایل را داشته باشد. نمونه YAML ارائه‌شده در مستندات کوبرنتیز به این صورت است:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
    memory.available:  "100Mi"
    nodefs.available:  "10%"
    nodefs.inodesFree: "5%"
    imagefs.available: "15%"
    imagefs.inodesFree: "5%"

در نمونه بالا، مقدار apiVersion برابر با kubelet.config.k8s.io/v1beta1 و مقدار kind برابر با KubeletConfiguration است. فیلد address باعث می‌شود kubelet روی آدرس 192.168.0.8 سرویس ارائه دهد و port هم پورت آن را روی 20250 قرار می‌دهد. مقدار false برای serializeImagePulls هم باعث می‌شود دریافت ایمیج‌ها به‌صورت موازی انجام شود.

مجموعه evictionHard آستانه‌هایی را مشخص می‌کند که در صورت رسیدن نود به آن‌ها، kubelet پادها را تخلیه می‌کند. در این نمونه، این آستانه‌ها شامل کاهش حافظه در دسترس نود به کمتر از 100MiB، کاهش فضای در دسترس فایل‌سیستم اصلی به کمتر از 10%، کاهش فضای در دسترس فایل‌سیستم Image به کمتر از 15% و استفاده بیش از 95% از inodeهای فایل‌سیستم اصلی است.

اجرای kubelet با فایل پیکربندی

برای اجرای kubelet با فایل پیکربندی، مسیر فایل را با گزینه --config مشخص کنید:

kubelet --config=/path/to/kubelet-config.yaml

kubelet --config=/path/to/kubelet-config.yaml

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

استفاده از فایل‌های Drop-in

kubelet امکان استفاده از یک دایرکتوری برای فایل‌های پیکربندی Drop-in را هم فراهم می‌کند. مسیر این دایرکتوری با فلگ –config-dir مشخص می‌شود. نمونه ارائه‌شده در مستندات به این صورت است:

--config-dir=/etc/kubernetes/kubelet.conf.d

--config-dir=/etc/kubernetes/kubelet.conf.d

kubelet به‌صورت پیش‌فرض هیچ دایرکتوری‌ای را برای فایل‌های Drop-in بررسی نمی‌کند و مسیر این دایرکتوری باید با --config-dir مشخص شود. فایل‌های معتبر در این دایرکتوری باید پسوند .conf داشته باشند.

فایل‌ها براساس نام کامل و به‌ترتیب الفبایی‌عددی پردازش می‌شوند. برای مثال، 00-kubelet.conf پیش از 01-kubelet.conf پردازش می‌شود و فایل بعدی می‌تواند مقادیر فایل قبلی را بازنویسی کند. فایل‌های Drop-in می‌توانند شامل پیکربندی جزئی باشند، اما نباید نامعتبر باشند و باید متادیتای نوع، یعنی apiVersion و kind، را داشته باشند. اعتبارسنجی روی ساختار نهایی پیکربندی انجام می‌شود.

ترتیب ادغام تنظیمات kubelet

هنگام راه‌اندازی، kubelet تنظیمات را از چند منبع دریافت و با ترتیب مشخصی ادغام می‌کند. ترتیب آن‌ها از کمترین به بیشترین اولویت به این صورت است:

• Feature Gateهای مشخص‌شده از طریق خط فرمان؛
• فایل اصلی پیکربندی kubelet؛
• فایل‌های Drop-in براساس ترتیب پردازش؛
• سایر آرگومان‌های خط فرمان، به‌جز Feature Gateها.

مشاهده پیکربندی نهایی kubelet

برای مشاهده پیکربندی نهایی kubelet، ابتدا در یک ترمینال Proxy را اجرا کنید:

kubectl proxy

kubectl proxy

سپس در ترمینالی دیگر، با جایگزین‌کردن <node-name> با نام واقعی نود، پیکربندی kubelet را از مسیر configz دریافت کنید:

curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

اجرای این مراحل به ابزارهای curl و jq نیاز دارد. این ابزارها را می‌توان از منابع نرم‌افزاری سیستم‌عامل نصب کرد.

نقش kubelet در چرخه حیات پاد

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

وضعیت‌های کانتینر از دید kubelet

پس از آنکه Scheduler پاد را به یک نود اختصاص می‌دهد، kubelet با استفاده از محیط اجرای کانتینر، ایجاد کانتینرهای آن پاد را آغاز می‌کند. کانتینرها از دید کوبرنتیز می‌توانند یکی از سه وضعیت Waiting ،Running یا Terminated را داشته باشند.

• Waiting: کانتینر هنوز در وضعیت Running یا Terminated قرار ندارد و عملیات لازم برای تکمیل راه‌اندازی آن در حال انجام است؛ برای مثال، ممکن است Image کانتینر در حال دریافت یا داده‌های Secret در حال اعمال باشند.
• Running: کانتینر در حال اجراست. اگر برای آن هوک postStart تعریف شده باشد، این هوک در این مرحله اجرا و تکمیل شده است.
• Terminated: کانتینر اجرای خود را آغاز کرده و سپس با موفقیت به پایان رسیده یا به دلیلی با شکست متوقف شده است.

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

رفتار kubelet در CrashLoopBackOff

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

عبارت CrashLoopBackOff نشان می‌دهد سازوکار تأخیر برای کانتینری فعال شده است که پی‌درپی با شکست مواجه می‌شود و دوباره راه‌اندازی می‌شود. این عبارت ممکن است در فیلد Status برخی خروجی‌های kubectl نمایش داده شود؛ بنابراین نباید آن را با یکی از وضعیت‌های رسمی چرخه حیات پاد اشتباه گرفت.

رفتار پادها هنگام ری‌استارت kubelet

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

هماهنگی kubelet و محیط اجرای کانتینر در مدیریت منابع

در لینوکس، گروه‌های کنترلی یا cgroup برای محدودکردن منابع اختصاص‌یافته به فرایندها استفاده می‌شوند. kubelet و محیط اجرای کانتینر برای اعمال مدیریت منابع پادها و کانتینرها، از جمله درخواست‌ها و محدودیت‌های CPU و حافظه، با cgroupها در تعامل‌اند.

هر دو مؤلفه برای کار با cgroupها از یک درایور استفاده می‌کنند؛ بنابراین باید درایور cgroup و تنظیمات مرتبط در kubelet و محیط اجرای کانتینر با یکدیگر هماهنگ باشند. مستندات کوبرنتیز دو درایور cgroupfs و systemd را معرفی می‌کند.

جمع‌بندی

کیوب‌لت عامل اصلی هر نود در کلاستر کوبرنتیز است و روی هر نود اجرا می‌شود. این مؤلفه PodSpecها را از سازوکارهای مختلف دریافت می‌کند و اطمینان می‌دهد کانتینرهای تعریف‌شده در آن‌ها در حال اجرا و سالم باشند.

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