خلاصه: در Kubernetes v1.37 قابلیت Scale to Zero برای HorizontalPodAutoscaler یا HPA به مرحله Beta رسیده و بهصورت پیشفرض فعال است. یعنی یک workload میتواند وقتی تقاضای واقعی وجود ندارد تا صفر Replica پایین بیاید و هنگام بازگشت تقاضا دوباره Pod بسازد؛ البته این الگو به metric مناسب نیاز دارد و در ازای صرفهجویی منابع، باید هزینه Cold Start را هم در طراحی در نظر گرفت.
Scale to Zero در Kubernetes یعنی چه؟
Scale to Zero یعنی Kubernetes اجازه بدهد تعداد Replicaهای یک workload از یک به صفر کاهش پیدا کند. تا پیش از Kubernetes v1.37، برای رسیدن به صفر معمولاً به افزونه، کنترلر خارجی یا قابلیتهای آزمایشی نیاز بود. در v1.37 این امکان برای HPA وارد API اصلی Kubernetes شده و طبق اعلام رسمی پروژه، قابلیت مربوطه Beta و بهصورت پیشفرض فعال است.
کاربرد اصلی آن جایی است که نگهداشتن حتی یک Pod بیکار هزینه قابلتوجهی دارد؛ برای نمونه queue consumerها، پردازشهای batch، workerهای رویدادمحور یا workloadهایی که CPU یا GPU رزروشده دارند. در چنین سناریوهایی صفر کردن Replicaها در زمان بیکاری میتواند مصرف منابع را کاهش دهد.
HorizontalPodAutoscaler یا HPA چه کاری انجام میدهد؟
HPA یکی از اجزای استاندارد Kubernetes برای تغییر خودکار تعداد Replicaهای workload بر اساس metric است. اگر هنوز با ساختار کلی کلاستر، Pod و Service آشنا نیستید، ابتدا راهنمای Kubernetes چیست و چگونه کانتینرها را مدیریت میکند را ببینید.
در حالت معمول، HPA وضعیت metric را با مقدار هدف مقایسه میکند و تعداد Replicaها را بالا یا پایین میبرد. تفاوت مهم v1.37 این است که در شرایط پشتیبانیشده، حد پایین میتواند واقعاً صفر باشد؛ بنابراین آخرین Pod بیکار هم لازم نیست فقط برای حفظ امکان Scale Up روشن بماند.
شرط مهم: Metric باید بدون Pod فعال هم قابل مشاهده باشد
نکته کلیدی Scale to Zero این است که Kubernetes باید وقتی هیچ Pod فعالی وجود ندارد نیز بفهمد چه زمانی تقاضا برگشته است. طبق مستند رسمی v1.37، HPA برای این سناریو باید از Object Metric یا External Metric مناسب استفاده کند.
برای مثال، طول یک صف پیام، تعداد Jobهای منتظر، نرخ رویداد ورودی یا metric خارجی دیگری که مستقل از Podهای خاموش قابل خواندن باشد، میتواند سیگنال Scale Up باشد. در مقابل، اگر تنها سیگنال شما مصرف CPU یک Pod باشد، وقتی Replica صفر است Podی وجود ندارد که مصرف CPU آن اندازهگیری شود؛ بنابراین طراحی metric اهمیت بیشتری از صرفاً تنظیم minReplicas دارد.
چه workloadهایی بهترین گزینه برای Scale to Zero هستند؟
- Queue Consumerها: وقتی صف خالی است workerها میتوانند خاموش شوند و با افزایش طول صف دوباره ساخته شوند.
- Batch Processorها: پردازشهایی که فقط در بازههای مشخص Job دریافت میکنند.
- پردازشهای رویدادمحور: سرویسهایی که با رخداد خارجی بیدار میشوند و در زمان بیکاری نیازی به Replica دائمی ندارند.
- Workloadهای GPU محور: خاموشکردن Pod بیکار زمانی ارزش بیشتری دارد که هر Replica منبع گرانقیمت رزرو کند.
- محیطهای آزمایشی و DevOps: سرویسهایی که دائماً استفاده نمیشوند اما در زمان نیاز باید خودکار برگردند.
مزیت اصلی: کاهش مصرف منابع و هزینه
وقتی حداقل Replica همیشه یک باشد، حتی در دورهای که هیچ درخواست واقعی وجود ندارد بخشی از CPU، RAM و گاهی GPU رزرو میشود. Scale to Zero این هزینه پایه را حذف میکند. اثر آن در یک سرویس کوچک ممکن است محدود باشد، اما در دهها worker یا چند workload سنگین میتواند محسوس شود.
این قابلیت بهخصوص برای معماریهایی جذاب است که تقاضای burst دارند؛ یعنی بیشتر زمان بیکارند ولی گاهی ناگهان بار میگیرند. بهجای روشن نگهداشتن ظرفیت برای بدترین حالت، میتوان ظرفیت را با metric واقعی بالا آورد.
هزینه پنهان Scale to Zero: Cold Start
صفر کردن Replica رایگان نیست. وقتی تقاضا برمیگردد، HPA ابتدا باید metric را ببیند، سپس Replica جدید درخواست شود، Scheduler برای Pod جا پیدا کند، image در صورت نیاز Pull شود، Container بالا بیاید و برنامه آماده پاسخگویی شود. مجموع این مراحل همان تأخیر Cold Start را میسازد.
برای سرویسهای تعاملی که کاربر انتظار پاسخ در چند ده میلیثانیه دارد، این تأخیر ممکن است قابل قبول نباشد. اما برای queue workerها، پردازش async یا Jobهایی که چند ثانیه تأخیر در شروع مشکلی ایجاد نمیکند، Scale to Zero معمولاً منطقیتر است.
قبل از فعالسازی چه چیزهایی را بررسی کنیم؟
۱. منبع Metric را مشخص کنید
Metric باید حتی در نبود Pod قابل خواندن باشد. اگر metric از خود Podها تولید میشود، برای بیدار کردن workload از صفر احتمالاً به سیگنال مناسبتری نیاز دارید.
۲. زمان Cold Start را اندازه بگیرید
زمان Pull شدن image، زمان Startup برنامه، اتصال به دیتابیس، Warm-up کش و آمادگی Readiness Probe را جداگانه بسنجید. تصمیم Scale to Zero باید بر اساس عدد واقعی باشد، نه صرفاً کاهش هزینه.
۳. ظرفیت کلاستر را در لحظه Scale Up در نظر بگیرید
HPA میتواند Replica درخواست کند، اما اگر Node ظرفیت نداشته باشد Pod در Pending میماند. در محیطی که Node Autoscaling هم وجود دارد، تأخیر اضافه برای ایجاد Node را نیز حساب کنید.
۴. رفتار هنگام جهش ناگهانی تقاضا را تست کنید
یک metric خارجی ممکن است در چند ثانیه از صفر به مقدار بسیار بالا برسد. Rate Limit، صف، maxReplicas و سیاستهای پایداری باید طوری تنظیم شوند که سیستم بهجای نوسان شدید، کنترلشده Scale شود.
Scale to Zero با خاموش کردن سرور فرق دارد
HPA تعداد Replicaهای workload را مدیریت میکند، نه الزاماً تعداد Nodeهای کلاستر را. ممکن است همه Podهای یک Deployment صفر شوند ولی Node همچنان روشن بماند. اگر هدف شما کاهش هزینه کل زیرساخت است، باید Scale to Zero در سطح workload را در کنار مدیریت ظرفیت Nodeها بررسی کنید.
برای آزمایش کلاستر، کنترل کامل سیستمعامل و پیادهسازی سناریوهای DevOps، یک سرور مجازی مناسب برای کلاسترهای آزمایشی و DevOps میتواند محیط قابلکنترلی برای تست HPA، metricها و رفتار Scale Up فراهم کند.
آیا در Kubernetes v1.37 باید Feature Gate جداگانه فعال کنیم؟
طبق اعلام رسمی Kubernetes، پشتیبانی Scale to Zero در HPA در نسخه v1.37 به مرحله Beta رسیده و بهصورت پیشفرض فعال است. این تفاوت مهمی با دوره Alpha دارد که برای استفاده از قابلیت، فعالسازی آزمایشی بیشتری لازم بود.
با این حال Beta بودن به این معناست که قبل از استفاده در سرویس حساس Production، سازگاری ابزارهای metric، رفتار کنترلر و سیاستهای عملیاتی خودتان را در محیط تست بررسی کنید.
Scale to Zero برای چه سرویسهایی مناسب نیست؟
- سرویسهایی با SLA بسیار سخت و حساسیت شدید به اولین پاسخ.
- برنامههایی که Startup طولانی یا Warm-up سنگین دارند.
- Workloadهایی که سیگنال تقاضای مستقل از Pod ندارند.
- سرویسهایی که همیشه حداقل یک اتصال دائمی یا Consumer فعال لازم دارند.
- سیستمهایی که هزینه Cold Start بیشتر از صرفهجویی منابع است.
چکلیست عملی برای مهاجرت به HPA با صفر Replica
- Kubernetes v1.37 و سازگاری اجزای کلاستر را بررسی کنید.
- Object Metric یا External Metric مناسب و مستقل از Pod تعریف کنید.
- رفتار workload در صفر Replica را در Staging تست کنید.
- Cold Start را با image کشنشده و شرایط واقعی اندازهگیری کنید.
- حداکثر Replica، ظرفیت Node و رفتار Burst را آزمایش کنید.
- Alert برای باقیماندن طولانی workload در صفر یا Pending تنظیم کنید.
- صرفهجویی واقعی CPU/RAM/GPU را با قبل مقایسه کنید.
جمعبندی
Scale to Zero در Kubernetes v1.37 یک تغییر کاربردی برای workloadهای event-driven و کماستفاده است. HPA اکنون میتواند در شرایط مناسب تعداد Replica را تا صفر پایین بیاورد و با مشاهده Object/External Metric دوباره workload را فعال کند. مزیت اصلی، حذف مصرف منابع در زمان بیکاری است و مهمترین هزینه، Cold Start محسوب میشود. اگر metric مستقل و قابل اتکا دارید و چند ثانیه تأخیر در بیدارشدن سرویس قابل قبول است، این قابلیت ارزش تست جدی دارد.
منبع اصلی: Kubernetes Blog — Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler، منتشرشده در ۲ سپتامبر ۲۰۲۶.