در مدل استاندارد Kubernetes، آماده‌بودن یک گره برای میزبانی پادها صرفاً یک شرط باینری “Ready” است. اما در خوشه‌های امروزی، گره‌ها معمولاً به وابستگی‌های زیرساختی پیچیده‌تری مثل network agents، storage drivers، میان‌افزارهای GPU یا بررسی‌های سلامت سفارشی نیاز دارند تا بتوانند با اطمینان پادها را میزبانی کنند 🚦

برای پاسخ به این نیازها، پروژه Node Readiness Controller معرفی شده است — سیستمی اعلامی که مدیریت «لکه‌ها» (patches) روی گره و محافظ‌های آمادگی (readiness guards) را فراتر از شرایط استاندارد گسترش می‌دهد. با اعمال پویاِ لکه‌ها بر اساس سیگنال‌های سلامت سفارشی، این کنترلر تضمین می‌کند که بارها فقط روی گره‌هایی زمان‌بندی شوند که همهٔ نیازهای زیرساختی آنها برآورده شده است ⚙️

اپراتورها معمولاً مجبورند قبل از اضافه‌کردن یک گره به استخر زمان‌بندی، مطمئن شوند که DaemonSetها یا سرویس‌های محلی خاص سالم شده‌اند. Node Readiness Controller این شکاف را با اجازه به تعریف دروازه‌های زمان‌بندی (scheduling gates) سفارشی برای گروه‌های گره خاص پر می‌کند — مثلاً اطمینان می‌دهد که گره‌های دارای GPU فقط وقتی پذیرای پاد شوند که درایورهای اختصاصی آنها تأیید شده باشد، در حالی که گره‌های عمومی از مسیر استاندارد پیروی می‌کنند 💡

سه مزیت اصلی که این کنترلر ارائه می‌دهد:

🟢 تعریف آمادگی سفارشی — می‌توانید به صورت دقیق مشخص کنید که «Ready» برای اپلیکیشن‌های شما چه معنایی دارد، و از فرود پادها روی زیرساخت‌های ناقص جلوگیری کنید.

🔁 حالت‌های عملیاتی متمایز — اجرای مستمر (continuous enforcement) تضمین می‌کند که آمادگی در طول عمر گره حفظ شود؛ اگر یک وابستگی حیاتی بعداً از کار افتاد، گره فوراً برای جلوگیری از زمان‌بندی جدید علامت‌گذاری می‌شود. در مقابل، حالت bootstrap-only برای مراحل یک‌بارهٔ اولیه مثل pre-pulling تصاویر سنگین یا آماده‌سازی سخت‌افزار مناسب است؛ پس از برآورده‌شدن شروط، کنترلر بوت‌استرپ را کامل کرده و نظارت خاص را متوقف می‌کند.

📣 گزارش وضعیت و ادغام — کنترلر به جای انجام بررسی‌های سلامت مستقل، به شرایط گره واکنش نشان می‌دهد و بنابراین به‌راحتی با ابزارهای موجود مثل Node Problem Detector (NPD) یا گزارشگر وضعیت آمادگی (یک عامل سبک که با یک endpoint محلی HTTP کار می‌کند) یکپارچه می‌شود.

🧪 اجرای rules در سراسر ناوگان می‌تواند خطراتی داشته باشد، بنابراین یک حالت dry-run فراهم شده که به اپراتورها اجازه می‌دهد ابتدا تأثیر تغییرات را شبیه‌سازی کنند. در این حالت کنترلر اقدامات پیشنهادی را لاگ می‌کند و وضعیت قانون را طوری به‌روزرسانی می‌کند که نشان دهد کدام گره‌ها تحت‌تأثیر قرار می‌گیرند بدون اعمال واقعی لکه‌ها — امکان اعتبارسنجی ایمن پیش از اجرا.

مثال: راه‌اندازی یک NodeReadinessRule برای CNI که تضمین می‌کند گره تا زمانی که عامل CNI کار نکند، زمان‌بندی نشود. نمونهٔ YAML زیر الگوی ساده‌ای از چنین قانونی است 📄

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadiness
metadata:
  name: node-readiness-cni
spec:
  selector:
    matchLabels:
      node-role.kubernetes.io/worker: ""
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  patches:
    - key: "readiness.k8s.io/acme.com/network-unavailable"
      effect: "NoSchedule"
      value: "waiting"
  enforcementMode: "bootstrap-elector"

این کنترلر اخیراً با انتشار اولیه شروع به کار کرده و تیم توسعه منتظر بازخورد جامعه برای اصلاح مسیر توسعه است. اگر مایلید در گفتگو شرکت کنید یا بازخورد بدهید، می‌توانید در Slack به کانال #sig-node-readiness-controller بپیوندید و مستندات شروع به کار را بررسی کنید 🔗🙂