تصمیم از روی کدام عدد گرفته می‌شود؟
Horizontal Pod Autoscaler تعداد replicaهای بار کاری را بر اساس متریک و هدف تنظیم‌شده تغییر می‌دهد. در حالت استفاده از درصد مصرف CPU، مقدار درخواست‌شده منابع در محاسبه نسبت اهمیت دارد. متریک ناموجود یا درخواست منابع نامناسب می‌تواند ارزیابی رفتار مقیاس‌دهی را دشوار کند.
HPA از APIهای متریک استفاده می‌کند و صرف تعریف شیء آن، فراهم‌بودن منبع داده را تضمین نمی‌کند. سیاست‌های مقیاس و پنجره تثبیت نیز بر سرعت تغییر ظرفیت اثر دارند. افزایش replicaها به معنی ایجاد خودکار ظرفیت نامحدود روی گره‌ها نیست؛ آماده‌شدن Podها و ظرفیت زمان‌بندی باید جدا بررسی شود.
سناریوی آموزشی تحریریه
یک سرویس فرضی با بار کنترل‌شده در نظر بگیرید. پیش از فعال‌کردن HPA، مصرف هر درخواست، زمان پاسخ و زمان آماده‌شدن نمونه جدید را ثبت کنید. سپس بار را پله‌ای افزایش دهید و ببینید بین زیادشدن تقاضا و آماده‌شدن ظرفیت چه فاصله‌ای وجود دارد.
در گزارش، چهار زمان جدا ثبت کنید: تولید متریک، تصمیم کنترل‌گر، ساخته‌شدن Pod و آماده‌شدن برنامه. این تفکیک کمک می‌کند تأخیر دریافت متریک با کندی شروع برنامه اشتباه نشود. نمودار تعداد replica به‌تنهایی پاسخ این سؤال‌ها را نمی‌دهد.
کاهش ظرفیت هم آزمون می‌خواهد
پس از پایان موج، کاهش ظرفیت را مشاهده کنید. پیشنهاد ما این است که درخواست‌های درحال اجرا و زمان خروج آرام برنامه در معیار پذیرش باشند. قطع ناگهانی پردازش طولانی می‌تواند تجربه کاربر را خراب کند، حتی زمانی که میانگین مصرف منابع مناسب به نظر می‌رسد.
برای بارهایی با زمان اجرای متفاوت، یک میانگین ساده ممکن است کافی نباشد. در آزمایش خود، زمان انتظار و صدک‌های تأخیر را کنار درصد مصرف ببینید. انتخاب متریک باید از مسئله سرویس بیاید، نه صرفاً از متریکی که آسان‌تر روی داشبورد نمایش داده می‌شود.
مرزهای مسئولیت
HPA را جایگزین کنترل اضافه‌بار، صف مناسب یا ظرفیت‌سنجی پایگاه داده ندانید. در یک نمونه فرضی، افزایش هم‌زمان چند سرویس می‌تواند اتصال‌های پایگاه داده را تمام کند. سقف replica و محدودیت وابستگی‌ها را با هم بنویسید.
پیشنهاد تحریریه، شروع از یک سرویس کم‌خطر و نگه‌داشتن پیکربندی قبلی برای بازگشت است. آزمون مثبت و منفی، قطع منبع متریک و رفتار هنگام ارتقا را هم ثبت کنید تا تنظیمات فقط برای یک نمودار نمایشی بهینه نشده باشند.
متریک مناسب را از صف کار پیدا کنیم
برای یک سرویس وب، CPU می‌تواند نشان‌دهنده فشار پردازشی باشد، اما برای مصرف‌کننده صف، طول صف یا زمان انتظار گاهی به مسئله نزدیک‌تر است. اگر برنامه بیشتر زمان را منتظر پاسخ یک سامانه بیرونی می‌ماند، افزایش درخواست‌های معطل ممکن است بدون مصرف بالای CPU رخ دهد. در این حالت، تکیه صرف بر CPU می‌تواند تصمیم مقیاس را دیر کند. انتخاب متریک باید با رابطه علت و معلولی همراه باشد: آیا افزودن یک نمونه واقعاً همان متریک را کاهش می‌دهد و کیفیت سرویس را بهتر می‌کند؟
یک نمونه فرضی از پردازش تصویر در نظر بگیرید. هر نمونه تعداد محدودی کار هم‌زمان می‌گیرد و کارها اندازه‌های متفاوت دارند. شمارش پیام صف به تنهایی ممکن است هزینه کارهای سنگین را نشان ندهد. سن قدیمی‌ترین کار و نرخ تکمیل نیز اطلاعات مفیدی می‌دهند. اگر صف خالی شود ولی پردازش‌های بلند هنوز فعال باشند، کاهش سریع نمونه‌ها می‌تواند کار را قطع کند. پس متریک تصمیم، راهبرد خروج برنامه و نحوه بازگرداندن کار ناتمام به صف باید با هم طراحی شوند؛ انتخاب ابزار مقیاس‌دهی این رابطه را حذف نمی‌کند.
درخواست CPU چگونه معنی درصد را تغییر می‌دهد؟
در حالت هدف‌گذاری استفاده نسبی CPU، مقدار درخواست منابع بخشی از مخرج محاسبه است. اگر دو برنامه مصرف یکسانی داشته باشند اما درخواست متفاوتی اعلام کنند، درصد استفاده نسبت به درخواست آن‌ها یکسان نخواهد بود. درخواست بسیار کوچک می‌تواند درصد بالا بسازد و درخواست بسیار بزرگ ممکن است فشار واقعی را در نسبت کمتر نشان دهد. بنابراین درخواست منابع نباید فقط عددی برای عبور از اعتبارسنجی باشد. اندازه مناسب آن را از مشاهده مصرف و نیاز زمان‌بندی برنامه به دست آورید و تغییرش را همراه با رفتار HPA بررسی کنید.
برای تمرین، دو استقرار آزمایشی یکسان با درخواست CPU متفاوت بسازید و بار کنترل‌شده یکسانی بدهید. نسبت گزارش‌شده، تعداد نمونه و زمان پاسخ را ثبت کنید. هدف پیدا کردن عدد جادویی نیست؛ هدف دیدن اثر تنظیم درخواست بر تصمیم کنترل‌گر است. اگر فقط نمودار مصرف مطلق را نگاه کنید، ممکن است علت اختلاف مقیاس را نبینید. پس در گزارش همیشه مصرف، درخواست و هدف HPA را کنار هم بیاورید. همچنین محدودیت CPU و اثر محدودسازی را جدا بررسی کنید، زیرا کندی ناشی از محدودیت با کمبود تعداد نمونه یکسان نیست.
از تصمیم تا ظرفیت قابل استفاده فاصله وجود دارد
کنترل‌گر ممکن است افزایش نمونه را بخواهد، اما زمان‌بند جای کافی پیدا نکند. در این حالت، عدد مطلوب بالا می‌رود و ظرفیت واقعی تغییر نمی‌کند. مشاهده Pending و رخدادهای Pod به ما می‌گوید مشکل در تأمین ظرفیت است، نه لزوماً متریک. حتی پس از زمان‌بندی، دریافت تصویر، اتصال حجم و گرم شدن برنامه زمان می‌برد. اگر موج ترافیک از مجموع این زمان‌ها کوتاه‌تر باشد، مقیاس واکنشی ممکن است بخش عمده موج را از دست بدهد. ظرفیت پایه و پیش‌بینی بار در چنین سرویس‌هایی اهمیت دارند.
برای اندازه‌گیری، چهار نقطه زمانی ثبت کنید: شروع افزایش بار، تغییر تصمیم HPA، آغاز کانتینر و آماده شدن پاسخ سالم. سپس همان آزمون را با تصویر موجود در گره و با تصویر تازه تکرار کنید. تفاوت نشان می‌دهد چه بخشی از تأخیر مربوط به دریافت تصویر است. اگر برنامه حافظه نهان محلی می‌سازد، زمان گرم شدن آن را نیز ببینید. آماده اعلام کردن زودهنگام نمونه می‌تواند ترافیک را به فرایندی بفرستد که هنوز کیفیت لازم را ندارد و ظاهراً افزایش ظرفیت را به افزایش خطا تبدیل کند.
نوسان را با کندی مطلوب اشتباه نگیریم
بار واقعی معمولاً صاف نیست. اگر هر تغییر کوتاه متریک باعث افزایش و کاهش شدید نمونه‌ها شود، سامانه وقت زیادی صرف شروع و توقف می‌کند. پنجره تثبیت و سیاست‌های تغییر برای کنترل این رفتار مفیدند، اما انتخاب آن‌ها باید با هزینه شروع برنامه و شکل بار هماهنگ باشد. تثبیت بسیار طولانی می‌تواند ظرفیت اضافه را دیر آزاد کند؛ تثبیت بسیار کوتاه می‌تواند نوسان ایجاد کند. معیار تصمیم فقط تعداد نمونه نیست، بلکه تأخیر کاربر، هزینه منابع و میزان کار از دست رفته در خروج است.
یک آزمایش مناسب، بار موجی با دوره‌های آرام و شلوغ است. نمودار متریک ورودی، تعداد مطلوب، تعداد آماده و زمان پاسخ را روی یک خط زمانی بگذارید. اگر تعداد مطلوب بالا می‌رود اما آماده‌ها عقب می‌مانند، مشکل با تنظیم کاهش مقیاس حل نمی‌شود. اگر آماده‌ها مدام حذف و ساخته می‌شوند، رفتار تثبیت و زمان خروج را بررسی کنید. این تفکیک باعث می‌شود هر گزینه تنظیمات برای مسئله مشخصی تغییر کند و مجموعه‌ای از اعداد تقلیدشده از یک آموزش وارد محیط واقعی نشود.
سقف وابستگی‌ها را در مقیاس برنامه حساب کنیم
فرض کنید هر نمونه سرویس تا چندین اتصال پایگاه داده باز می‌کند. افزایش نمونه‌ها می‌تواند مجموع اتصال‌ها را از ظرفیت پایگاه داده عبور دهد. در این وضعیت HPA از دید CPU درست عمل می‌کند، اما گلوگاه را به لایه دیگر منتقل می‌کند. سقف تعداد نمونه، اندازه مخزن اتصال و ظرفیت سامانه مقصد باید با هم محاسبه شوند. همین مسئله برای نرخ مجاز API بیرونی، ظرفیت صف و پهنای باند شبکه نیز وجود دارد. مقیاس افقی برنامه تضمین نمی‌کند تمام زنجیره درخواست ظرفیت مشابهی دارد.
کنترل اضافه‌بار باید در کنار مقیاس باشد. محدود کردن هم‌زمانی، صف محدود و پاسخ مناسب هنگام اشباع می‌توانند از فروپاشی وابستگی جلوگیری کنند. اگر صف نامحدود باشد، برنامه ممکن است مدتی ظاهراً درخواست بپذیرد اما تأخیر تا حد غیرقابل استفاده رشد کند. در آزمون، بار را کمی فراتر از ظرفیت مورد انتظار ببرید و ببینید سرویس چگونه افت می‌کند. شکست قابل پیش‌بینی و محدود، از انباشته شدن بی‌پایان کار و بازیابی طولانی بهتر قابل مدیریت است؛ معیار آن باید پیش از آزمون مشخص باشد.
خرابی منبع متریک و تعارض مالکیت
اگر منبع متریک قطع شود، رفتار HPA را از وضعیت و شرایط گزارش‌شده بخوانید. نبود داده را با مصرف صفر یکی نگیرید. یک هشدار مناسب باید تازگی داده و خطای دریافت را نیز بسنجد. در آزمایش، دسترسی منبع متریک را موقتاً قطع کنید و تغییر تعداد نمونه و پیام‌ها را ثبت کنید. سپس پس از بازگشت منبع، ادامه کار را بررسی کنید. این سناریو به ویژه برای متریک سفارشی مهم است، چون واسط و سامانه پایش خودشان وابستگی‌های عملیاتی دارند.
همچنین مشخص کنید چه کسی مالک تعداد replica است. اگر یک فرایند GitOps پیوسته مقدار ثابت را اعمال کند و HPA هم آن را تغییر دهد، باید رفتار هم‌زیستی آن‌ها آگاهانه تنظیم شود. انتشار برنامه نباید ناخواسته ظرفیت را به عدد اولیه برگرداند. یک آزمون انتشار در زمان بار انجام دهید و ببینید مقیاس حفظ می‌شود یا خیر. این مسئله در محیط آرام ممکن است دیده نشود، اما هنگام ترافیک بالا اثر جدی دارد. قرارداد مالکیت تنظیمات میان تیم برنامه و پلتفرم را کنار پیکربندی HPA مستند کنید.
معیار پذیرش یک تنظیم نهایی
پیکربندی قابل قبول باید در افزایش بار، کاهش بار، قطع متریک و انتشار نسخه تازه رفتار قابل توضیح داشته باشد. برای هر حالت، زمان پاسخ، نرخ خطا، تعداد آماده و وضعیت وابستگی اصلی ثبت شود. اگر افزایش نمونه فقط میانگین CPU را بهتر می‌کند اما زمان انتظار کاربر ثابت می‌ماند، احتمالاً متریک انتخابی با گلوگاه اصلی ارتباط کافی ندارد. پس از هر تغییر، نتیجه را با فرضیه اولیه مقایسه کنید و علت پذیرفتن تنظیم را بنویسید. این یادداشت در تغییر بعدی برنامه، که الگوی مصرف عوض می‌شود، ارزش بیشتری از خود عددهای تنظیمات دارد.
در تحویل تنظیمات به تیم شیفت، یک نمونه از افزایش سالم ظرفیت و یک نمونه از شکست زمان‌بندی نگه دارید. اپراتور باید از روی تفاوت تعداد مطلوب و تعداد آماده بداند آیا باید منبع متریک، زمان شروع برنامه یا ظرفیت گره را بررسی کند. این نمونه‌ها آموزش را به رفتار واقعی سرویس نزدیک می‌کنند و جلوی تغییر بی‌دلیل هدف درصدی را در حوادث نامرتبط می‌گیرند. همچنین مالک سقف ظرفیت وابستگی‌ها را مشخص کنید تا افزایش اضطراری سقف HPA بدون بررسی پایگاه داده انجام نشود.
