پیکربندی هر kubelet در کلاستر شما با استفاده از kubeadm

توجه: Dockershim از نسخه 1.24 از پروژه کوبرنتیز حذف شده است. برای جزئیات بیشتر سوالات متداول حذف Dockershim را بخوانید.
وضعیت ویژگی: کوبرنتیز v1.11 [stable]

چرخه حیات ابزار رابط خط فرمان kubeadm از kubelet که یک سرویس (daemon) است که روی هر گره(node) در کلاستر کوبرنتیز اجرا می‌شود، جدا شده است. ابزار رابط خط فرمان kubeadm هنگام راه‌اندازی یا ارتقاء کوبرنتیز توسط کاربر اجرا می‌شود، در حالی که kubelet همیشه در پس‌زمینه در حال اجرا است.

از آنجایی که kubelet یک سرویس (daemon) است، باید توسط نوعی سیستم init یا مدیر سرویس نگهداری شود. وقتی kubelet با استفاده از DEBها یا RPMها نصب می‌شود، systemd برای مدیریت kubelet پیکربندی می‌شود. می‌توانید به جای آن از یک مدیر سرویس متفاوت استفاده کنید، اما باید آن را به صورت دستی پیکربندی کنید.

برخی از جزئیات پیکربندی kubelet باید در تمام kubelet های موجود در کلاستر یکسان باشد، در حالی که سایر جنبه‌های پیکربندی باید بر اساس هر kubelet تنظیم شوند تا با ویژگی‌های مختلف یک ماشین خاص (مانند سیستم عامل، فضای ذخیره‌سازی و شبکه) سازگار شوند. شما می‌توانید پیکربندی kubelet های خود را به صورت دستی مدیریت کنید، اما kubeadm اکنون یک نوع API از نوع KubeletConfiguration را برای مدیریت پیکربندی‌های kubelet خود به صورت مرکزی ارائه می‌دهد.

الگوهای پیکربندی Kubelet

بخش‌های زیر الگوهایی را برای پیکربندی kubelet شرح می‌دهند که با استفاده از kubeadm ساده شده‌اند، نه اینکه پیکربندی kubelet را برای هر گره(node) به صورت دستی مدیریت کنند.

انتشار پیکربندی سطح کلاستر به هر kubelet

شما می‌توانید مقادیر پیش‌فرض را برای استفاده توسط دستورات kubeadm init و kubeadm join به kubelet ارائه دهید. مثال‌های جالب شامل استفاده از یک مجری کانتینر متفاوت یا تنظیم زیرشبکه پیش‌فرض مورد استفاده توسط سرویس‌ها است.

اگر می‌خواهید سرویس‌های شما از زیرشبکه 10.96.0.0/12 به عنوان پیش‌فرض برای سرویس‌ها استفاده کنند، می‌توانید پارامتر --service-cidr را به kubeadm ارسال کنید:

kubeadm init --service-cidr 10.96.0.0/12

اکنون IPهای مجازی برای سرویس‌ها از این زیرشبکه اختصاص داده می‌شوند. همچنین باید نشانی(آدرس) DNS مورد استفاده توسط kubelet را با استفاده از پرچم --cluster-dns تنظیم کنید. این تنظیم باید برای هر kubelet روی هر مدیر و گره(node) در کلاستر یکسان باشد. kubelet یک شیء API نسخه‌بندی شده و ساختار یافته ارائه می‌دهد که می‌تواند اکثر پارامترها را در kubelet پیکربندی کند و این پیکربندی را به هر kubelet در حال اجرا در کلاستر ارسال کند. این شیء KubeletConfiguration نامیده می‌شود. KubeletConfiguration به کاربر اجازه می‌دهد پرچم‌هایی مانند نشانی‌(آدرس)های IP DNS کلاستر را که به صورت لیستی از مقادیر با کلید camelCased بیان می‌شوند، مشخص کند، که با مثال زیر نشان داده شده است:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
- 10.96.0.10

برای جزئیات بیشتر در مورد KubeletConfiguration، به این بخش نگاهی بیندازید.

ارائه جزئیات پیکربندی مختص به هر نمونه

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

  • مسیر فایل DNS resolution، همانطور که توسط پرچم پیکربندی --resolv-conf در kubelet مشخص شده است، ممکن است در بین سیستم عامل‌ها یا بسته به اینکه آیا از systemd-resolved استفاده می‌کنید یا خیر، متفاوت باشد. اگر این مسیر اشتباه باشد، DNS resolution در گره‌ای که kubelet آن به طور نادرست پیکربندی شده است، با شکست مواجه خواهد شد.

  • شیء گره(node) API با نام .metadata.name به طور پیش‌فرض روی نام میزبان دستگاه تنظیم شده است، مگر اینکه از یک ارائه‌دهنده ابری استفاده کنید. در صورت نیاز به تعیین نام گره‌ای متفاوت از نام میزبان دستگاه، می‌توانید از پرچم --hostname-override برای لغو رفتار پیش‌فرض استفاده کنید.

  • در حال حاضر، kubelet نمی‌تواند به طور خودکار درایور cgroup مورد استفاده توسط مجری کانتینر را تشخیص دهد، اما مقدار --cgroup-driver باید با درایور cgroup مورد استفاده توسط مجری کانتینر مطابقت داشته باشد تا سلامت kubelet تضمین شود.

  • برای مشخص کردن مجری کانتینر، باید نقطه پایانی آن را با پرچم --container-runtime-endpoint=<path> تنظیم کنید.

روش توصیه‌شده برای اعمال چنین پیکربندی مختص به نمونه، استفاده از KubeletConfiguration patches است.

پیکربندی kubelets با استفاده از kubeadm

می‌توان kubelet را طوری پیکربندی کرد که kubeadm آن را اجرا کند اگر یک شیء API سفارشی KubeletConfiguration با یک فایل پیکربندی مانند kubeadm ... --config some-config-file.yaml ارسال شود.

با فراخوانی kubeadm config print init-defaults --component-configs KubeletConfiguration می‌توانید تمام مقادیر پیش‌فرض این ساختار را مشاهده کنید.

همچنین می‌توان وصله‌های مخصوص هر نمونه را روی «KubeletConfiguration» پایه اعمال کرد. برای جزئیات بیشتر، نگاهی به سفارشی‌سازی kubelet بیندازید.

گردش کار هنگام استفاده از kubeadm init

وقتی kubeadm init را فراخوانی می‌کنید، پیکربندی kubelet در مسیر /var/lib/kubelet/config.yaml روی دیسک ذخیره می‌شود و همچنین در یک نقشه پیکربندی kubelet-config در فضای نام kube-system کلاستر آپلود می‌شود. یک فایل پیکربندی kubelet همچنین در مسیر /etc/kubernetes/kubelet.conf با پیکربندی پایه در سطح کلاستر برای همه kubelet های کلاستر نوشته می‌شود. این فایل پیکربندی به گواهی‌های کلاینت اشاره می‌کند که به kubelet اجازه می‌دهد با سرور API ارتباط برقرار کند. این امر نیاز به انتشار پیکربندی سطح کلاستر به هر kubelet را برطرف می‌کند.

برای پرداختن به الگوی دومِ ارائه جزئیات پیکربندی مختص به نمونه، kubeadm یک فایل محیطی را در /var/lib/kubelet/kubeadm-flags.env می‌نویسد که شامل فهرستی از پرچم‌هایی است که باید هنگام شروع به kubelet منتقل شوند. پرچم‌ها در فایل به این شکل ارائه می‌شوند:

KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."

علاوه بر پرچم‌های مورد استفاده هنگام شروع kubelet، این فایل همچنین شامل پارامترهای پویا مانند درایور cgroup و اینکه آیا از یک سوکت مجری کانتینر متفاوت (--cri-socket) استفاده شود یا خیر، می‌باشد.

پس از مرتب‌سازی این دو فایل روی دیسک، kubeadm تلاش می‌کند دو دستور زیر را اجرا کند، البته اگر از systemd استفاده می‌کنید:

systemctl daemon-reload && systemctl restart kubelet

اگر بارگذاری مجدد و راه‌اندازی مجدد موفقیت‌آمیز باشد، گردش کار عادی kubeadm init ادامه می‌یابد.

گردش کار هنگام استفاده از kubeadm join

وقتی kubeadm join را اجرا می‌کنید، kubeadm از اعتبارنامه‌ی Bootstrap Token برای انجام یک راه انداز TLS استفاده می‌کند که اعتبارنامه‌ی مورد نیاز برای دانلود نقشه‌ی پیکربندی kubelet-config را دریافت کرده و آن را در /var/lib/kubelet/config.yaml می‌نویسد. فایل محیط پویا دقیقاً به همان روشی که kubeadm init تولید می‌شود، تولید می‌شود.

در مرحله بعد، kubeadm دو دستور زیر را برای بارگذاری پیکربندی جدید در kubelet اجرا می‌کند:

systemctl daemon-reload && systemctl restart kubelet

پس از اینکه kubelet پیکربندی جدید را بارگذاری کرد، kubeadm فایل KubeConfig را می‌نویسد که شامل یک گواهی CA و راه انداز Token است. این فایل‌ها توسط kubelet برای انجام TLS راه انداز و دریافت یک اعتبارنامه منحصر به فرد استفاده می‌شوند که در /etc/kubernetes/kubelet.conf ذخیره می‌شود.

وقتی فایل /etc/kubernetes/kubelet.conf نوشته می‌شود، kubelet اجرای TLS راه انداز را به پایان رسانده است. Kubeadm پس از تکمیل TLS راه انداز ، فایل /etc/kubernetes/bootstrap-kubelet.conf را حذف می‌کند.

فایل نصبی kubelet برای systemd

kubeadm به همراه پیکربندی نحوه‌ی اجرای kubelet توسط systemd ارائه می‌شود. توجه داشته باشید که دستور kubeadm CLI هرگز به این فایل drop-in دست نمی‌زند.

این فایل پیکربندی که توسط بسته kubeadm نصب شده است، در مسیر /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf نوشته شده و توسط systemd استفاده می‌شود. این فایل، بسته اصلی kubelet.service را تکمیل می‌کند.

اگر می‌خواهید این مورد را بیشتر تغییر دهید، می‌توانید یک پوشه به نشانی(آدرس) /etc/systemd/system/kubelet.service.d/ (نه /usr/lib/systemd/system/kubelet.service.d/) ایجاد کنید و تنظیمات شخصی‌سازی خود را در یک فایل در آنجا قرار دهید. برای مثال، می‌توانید یک فایل محلی جدید به نشانی(آدرس) /etc/systemd/system/kubelet.service.d/local-overrides.conf اضافه کنید تا تنظیمات واحد پیکربندی شده توسط kubeadm را تغییر دهید.

این چیزی است که احتمالاً در /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf خواهید یافت:

توجه:

مطالب زیر فقط یک مثال هستند. اگر نمی‌خواهید از مدیر بسته استفاده کنید، راهنمای ذکر شده در بخش (بدون مدیر بسته) را دنبال کنید.
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
# the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

این فایل مکان‌های پیش‌فرض برای تمام فایل ‌های مدیریت‌شده توسط kubeadm در kubelet را مشخص می‌کند.

  • فایل KubeConfig مورد استفاده برای TLS راه انداز، فایل /etc/kubernetes/bootstrap-kubelet.conf است، اما فقط در صورتی استفاده می‌شود که /etc/kubernetes/kubelet.conf وجود نداشته باشد.
  • فایل KubeConfig با هویت منحصر به فرد kubelet در مسیر /etc/kubernetes/kubelet.conf قرار دارد.
  • فایل حاوی ComponentConfig مربوط به kubelet در مسیر /var/lib/kubelet/config.yaml قرار دارد.
  • فایل محیط پویا که شامل KUBELET_KUBEADM_ARGS است، از /var/lib/kubelet/kubeadm-flags.env گرفته شده است.
  • فایل ای که می‌تواند شامل لغو پرچم‌های مشخص‌شده توسط کاربر با KUBELET_EXTRA_ARGS باشد، از /etc/default/kubelet (برای DEBها) یا /etc/sysconfig/kubelet (برای RPMها) گرفته شده است. KUBELET_EXTRA_ARGS

آخرین فایل در زنجیره پرچم‌ها است و در صورت وجود تنظیمات متناقض، بالاترین اولویت را دارد.

فایل های باینری و محتویات بسته‌های کوبرنتیز

بسته‌های DEB و RPM که با نسخه‌های کوبرنتیز ارائه می‌شوند عبارتند از:

Package nameDescription
kubeadmابزار خط فرمان /usr/bin/kubeadm و فایل نصبی kubelet را برای kubelet نصب می‌کند.
kubeletفایل باینری /usr/bin/kubelet را نصب می‌کند.
kubectlفایل باینری /usr/bin/kubectl را نصب می‌کند.
cri-toolsفایل باینری /usr/bin/crictl را از مخزن گیت cri-tools نصب می‌کند.
kubernetes-cniفایل‌های باینری /opt/cni/bin را از مخزن plugins git نصب می‌کند.

آخرین تغییرات May 01, 2026 at 11:19 AM PST: Update-Content-Before-Publish (dca3f44400)