<h2>استفاده از config-dir برای kubelet در Kubernetes</h2>


امکانات config-dir به شما امکان می‌دهد پیکربندی پایه kubelet را با فایل‌های drop-in برای گروه‌های نُد مختلف ترکیب کنید و کاهش drift پیکربندی را فراهم آورد.

نسخه 1.35 از Kubernetes حالا پشتیبانی از فهرست drop-in پیکربندی برای kubelet را به حالت GA (پایدار) رسانده است 🙂. این قابلیت با فعال شدن آرگومان خط فرمان –config-dir به شما اجازه می‌دهد یک دایرکتوری مشخص حاوی فایل‌های پیکربندی کوچک (drop-in) برای kubelet داشته باشید؛ kubelet به‌صورت خودکار همه فایل‌های داخل آن دایرکتوری را در پیکربندی اصلی ادغام می‌کند تا مدیریت تنظیمات در خوشه‌های بزرگ و ناهمگن ساده‌تر شود.

چرا این مهم است؟ در خوشه‌های تولیدی بزرگ معمولاً گروه‌های مختلفی از نُدها مثل گره‌های GPU، نُدهای لبه و نُدهای استاندارد وجود دارد که هر کدام نیاز به تنظیمات خاصی در kubelet دارند. نگهداری یک فایل کامل و جداگانه برای هر نوع نُد یا استفاده از ابزارهای پیچیده مدیریت پیکربندی هم پرخطا و هم سربار عملیاتی بالایی دارد؛ قابلیت drop-in این روند را ساده و قابل‌قابلیت‌نگهداری می‌کند 😊.

کارکرد اصلی واضح است: یک پیکربندی پایه (base) را نگه‌دارید و تغییرات مختص هر گروه نُد را در فایل‌های drop-in با نام‌گذاری عددی (برای کنترل ترتیب) قرار دهید. kubelet فایل‌ها را به ترتیب نام (معمولاً با پیشوندهای عددی مثل 00-, 50-, 90-) می‌خواند و آن‌ها را روی پیکربندی پایه merge می‌کند تا پیکربندی نهایی اجرا شود.

چالش‌هایی که این ویژگی حل می‌کند عبارتند از: کاهش drift پیکربندی بین نُدها، سهولت در اعمال overrideهای هدفمند برای استخرهای نُد مختلف، و کم کردن سربار نگهداری و ممیزی فایل‌ها در مقیاس. این روش به شما امکان می‌دهد بدون نیاز به ابزار خارجی یا اسکریپت‌های پیچیده، پیکربندی‌های منظم و قابل ردیابی داشته باشید.

نمونه‌ای از ساختار برای یک خوشه با نُدهای متنوع را این‌جا می‌بینید — سه فایل نمونه که kubelet آن‌ها را ادغام خواهد کرد:

# 00-base.conf
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "10.96.0.10"
clusterDomain: "cluster.local"

# 50-high-priority.conf (نُدهای با ظرفیت بالا مانند GPU)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 50
systemReserved:
  memory: "4Gi"
  cpu: "1000m"

# 50-edge-nodes.conf (نُدهای Edge معمولاً تنظیمات سبک‌تر دارند)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "5%"

با این ساختار، نُدهای با ظرفیت بالا هر دو پیکربندی پایه و override مخصوص خود را دریافت می‌کنند و نُدهای لبه فقط تنظیمات پایه به‌علاوه تنظیمات لایه لبه را می‌گیرند. برای آزمایش ویژگی جدید می‌توانید یک فایل drop-in با پیشوند عددی بالا (مثلاً 99-new-feature.conf) اضافه کرده و آن را فقط روی یک زیرمجموعه از نُدها آزمایش کنید تا تاثیر آن را قبل از انتشار در سطح خوشه بسنجید 🔬.

برای دیدن پیکربندی نهایی که kubelet پس از ادغام استفاده می‌کند، می‌توانید از endpoint داخلی /configz استفاده کنید. مراحل کلی:

# در یک ترمینال:
kubectl proxy

# در ترمینال دیگر، پیکربندی ادغام‌شده را واکشی کنید (قبل از اجرا، نام node را جایگزین کنید):
curl -X GET "http://127.0.0.1:8001/api/v1/nodes//proxy/configz" | jq .

خروجی نشان می‌دهد که kubelet پس از اعمال همه drop-inها و همچنین آرگومان‌های خط فرمان چه پیکربندی‌ای را در عمل استفاده می‌کند — این راه خوبی برای اعتبارسنجی تغییرات است ✔️.

نکات عملی و best practices برای استفاده تدریجی و ایمن:

– همیشه تغییرات جدید را ابتدا روی زیرمجموعه‌ای از نُدها آزمایش کنید تا ریسک را کاهش دهید. 🔁

– از پیشوندهای عددی (مثلاً 00-, 50-, 90-) برای کنترل ترتیب merge استفاده کنید تا لایه‌بندی پیکربندی برای دیگران واضح باشد. 🔢

– مراقب فایل‌های موقت یا بکاپ ویرایشگرها (.bak, .swp, ~ و غیره) باشید؛ اگر چنین فایل‌هایی داخل دایرکتوری drop-in بمانند، kubelet ممکن است آن‌ها را پردازش کند و نتیجه ناخواسته ایجاد شود. 🧹

این ویژگی نتیجه تلاش‌های مشترک SIG Node است و از نسخه آلفا در v1.28 تا بتا در v1.30 تکامل پیدا کرد و اکنون در v1.35 به GA رسیده است. اگر تجربه‌ای در تولید با این قابلیت دارید یا سوالی درباره رفتار ادغام و سناریوهای عملی دارید، در کانال‌های عمومی SIG Node می‌توانید بحث کنید — بازخوردهای عملی شما به بهبود مستندات و رفتارهای عملیاتی کمک می‌کند 🙌.