مایکروسافت راهنمایی عملی برای NAP در AKS منتشر کرده تا حذف، جایگزینی و تجمیع خودکار نودها در زمان کاهش مقیاس، ارتقا و نگهداری، قابل‌پیش‌بینی و امن‌تر شود. این راهکارها برای تیم‌های پلتفرم که به دنبال کاهش هزینه و افزایش پایداری‌اند، موثر است.

NAP در AKS چیست و چرا اهمیت دارد

Node Auto-Provisioning (NAP) در AKS بر پایه پروژه متن‌باز Karpenter عمل می‌کند و بر اساس تقاضای بارها، نودها را تأمین یا حذف می‌کند تا بسته‌بندی کارآمدتر و کاهش هزینه حاصل شود. با این حال، حذف خودکار نودها می‌تواند اختلالی در دسترس‌پذیری سرویس‌ها ایجاد کند که نیازمند سیاست‌های هماهنگ در لایه برنامه و زیرساخت است.

دو لایه حاکمیت: لایه برنامه و لایه زیرساخت

برای مدیریت ایمن اختلال نودها، باید دو مکانیزم هم‌زمان به کار روند:

  • لایه برنامه: بودجه اختلال پادها (Pod Disruption Budgets — PDB) مشخص می‌کنند چند نمونه از یک سرویس می‌توانند به‌صورت داوطلبانه تخلیه شوند. مستندات رسمی را در مجموعه مستندات Kubernetes ببینید.
  • لایه زیرساخت: کنترل‌های NAP شامل سیاست‌های تجمیع (consolidation policies)، پارامترهایی مانند consolidateAfter و expireAfter و گزینه‌هایی مانند WhenEmptyOrUnderutilized برای تعیین زمان و نحوه اختلال نودها هستند.

خطای رایج: PDBهای بیش از حد محدودکننده

پیکربندی PDB با maxUnavailable: 0 که نیاز به حضور ۱۰۰٪ نمونه‌ها دارد، مانع تخلیه داوطلبانه پادها می‌شود. در نتیجه NAP نمی‌تواند نودها را تخلیه کند و عملیات تجمیع، ارتقا یا مهاجرت قفل می‌شود. راه‌حل این نیست که همه PDBها را شل کنیم؛ بلکه باید مقادیر PDB را بر اساس نیاز واقعی هر سرویس تعیین کرد. برای سرویس‌های تکثیرشده، اجازه یک نمونه غیرقابل‌دسترس می‌تواند نگهداری زیرساخت را ممکن سازد بدون تأثیر محسوس برای کاربران.

ابزارهای NAP برای کنترل تجمیع

با فعال شدن گزینه WhenEmptyOrUnderutilized، NAP می‌سنجد که آیا بارها را می‌توان روی ترکیب کارآمدتری از VMها قرار داد و سپس ظرفیت اضافی را حذف کند. اپراتورها می‌توانند تجمیع را با consolidateAfter به تأخیر بیندازند و با expireAfter حداکثر عمر نودها را تعیین کنند. این پارامترها فرایند بهینه‌سازی را به یک حلقه تصمیم‌گیری مداوم تبدیل می‌کنند: آیا می‌توان ظرفیت را کاهش داد بدون نقض قیدهای دسترسی؟

نمایی از داشبورد مدیریت نودها در محیط ابری

اختلال داوطلبانه در مقابل غیرداوطلبانه

کنترل‌های NAP و PDBها عمدتاً روی عملیات داوطلبانه مانند تجمیع، drift و انقضای نود تمرکز دارند و از وقوع خرابی سخت‌افزاری، اشکال میزبان یا اخراج VMهای Spot جلوگیری نمی‌کنند. نمونه‌های Spot ذاتاً اختلال‌پذیرند؛ AKS می‌تواند اخطار اخراج را تشخیص دهد و ظرفیت جایگزین فراهم کند، اما طراحی برنامه‌ها باید تحمل قطع سرویس را در نظر بگیرد.

چگونه سیاست‌ها را عملیاتی کنیم

  • شناسایی و اولویت‌بندی بارها: هر سرویس را بر اساس نیاز در دسترس‌پذیری و حساسیت به تأخیر دسته‌بندی کنید.
  • تنظیم PDB متناسب: به‌جای maxUnavailable: 0، برای سرویس‌هایی با تکرار بالا مقدار معقولی مثل 1 یا درصدی از replicas در نظر بگیرید.
  • پیکربندی NAP: از WhenEmptyOrUnderutilized، consolidateAfter و expireAfter برای هم‌راستا کردن اهداف هزینه و دسترسی استفاده کنید.
  • نظارت و آزمایش: سناریوهای تخلیه، ارتقا و اخراج Spot را در محیط تست شبیه‌سازی و پاسخ سرویس‌ها را بررسی کنید.
  • مستندسازی و هماهنگی: قوانین autoscaling و محدودیت‌های هر بارکاری را ثبت کنید تا تیم‌های اپلیکیشن و پلتفرم هم‌راستا عمل کنند.

چشم‌انداز: از «مقیاس‌دهی» به «مقیاس‌دهی امن»

با پیشرفت قابلیت‌های پروویژن و تجمیع نود در Kubernetes و پروژه‌هایی مثل Karpenter، مسئله این است که خودکارسازی چگونه امن و قابل‌پیش‌بینی پیاده‌سازی شود. ترکیب محافظت در سطح برنامه (PDB) و کنترل دقیق زیرساخت کمک می‌کند تا خودکارسازی شفاف، قابل‌اعتماد و اقتصادی باشد.

مراجع بیشتر

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