Memory QoS در Kubernetes؛ مدیریت فشار حافظه در 1.37

Memory QoS در Kubernetes به مدیریت رفتار حافظه هنگام فشار منابع مربوط می‌شود. فرض کنید چند برنامه روی یک Node اجرا می‌شوند و مصرف حافظه یکی از آن‌ها افزایش می‌یابد. در این وضعیت، فقط دانستن مقدار RAM مصرف‌شده کافی نیست؛ باید بفهمیم رقابت بر سر حافظه چه اثری بر کیفیت سرویس‌ها دارد.

در این مقاله، مفهوم Memory QoS، تفاوت آن با محدودیت حافظه و یک مسیر پیشنهادی برای ارزیابی عملی را بررسی می‌کنیم.

Memory QoS چیست و در نسخه 1.37 چه تغییری کرده است؟

Memory QoS در Kubernetes 1.37 به وضعیت Beta رسیده و Feature Gate آن به‌صورت پیش‌فرض روشن است. این قابلیت روی Nodeهای لینوکسی مبتنی بر cgroup v2 از کنترل‌کننده حافظه استفاده می‌کند. بااین‌حال، روشن‌بودن Feature Gate به معنای اعمال خودکار throttling یا حفاظت حافظه نیست: مقدار پیش‌فرض memoryThrottlingFactor برابر null و سیاست رزرو پیش‌فرض None است. رفتارهای مربوط باید صریحاً در kubelet تنظیم شوند. اعلام رسمی نسخه Beta

تفاوت memory.high با سقف سخت حافظه چیست؟

در cgroup v2، memory.high مرزی برای ایجاد فشار بازپس‌گیری حافظه و کندکردن فرایندهای مصرف‌کننده است. عبور از این مرز به‌خودی‌خود OOM killer را فعال نمی‌کند. در مقابل، memory.max سقف سخت است و اگر مصرف به آن برسد و امکان کاهش کافی وجود نداشته باشد، ممکن است OOM در همان cgroup رخ دهد.

همچنین memory.low حفاظت ترجیحی در برابر بازپس‌گیری و memory.min حفاظت سخت‌تر را، در محدوده مؤثر سلسله‌مراتب cgroup، تعریف می‌کنند. محافظت بیش‌ازحد نسبت به حافظه موجود نیز مشکل‌ساز است. مرجع کنترل حافظه در Linux

نتیجه عملی برای تیم بهره‌برداری این است که نبود OOM را تنها معیار موفقیت نداند. ممکن است فرایند زنده بماند، اما افزایش تأخیر برای کاربران قابل قبول نباشد.

نقش کلاس‌های QoS در حفاظت حافظه

در سیاست TieredReservation، Podهای Guaranteed با memory.min و Podهای Burstable با memory.low بر اساس request حافظه محافظت می‌شوند؛ BestEffort چنین حفاظتی ندارد. این سیاست در سطح Node اعمال می‌شود، بنابراین انتخاب آن باید با ترکیب بارهای همان Node هماهنگ باشد.

برای Guaranteed، حفاظت page cache هم اهمیت دارد: محدودیت نامناسب و فضای ناکافی برای کش می‌تواند همچنان به OOM منجر شود. نام کلاس QoS را تضمین نبود خطا تلقی نکنید. راهنمای رسمی کلاس‌های QoS

نمونه تنظیم Memory QoS در kubelet

نمونه زیر دو رفتار throttling و رزرو لایه‌ای را برای Kubernetes 1.37 نشان می‌دهد. این یک بخش از پیکربندی kubelet است؛ آن را به‌عنوان Manifest یک Pod اعمال نکنید:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservation

این گزینه‌ها مستقل‌اند و می‌توان فقط یکی را انتخاب کرد. مقدار 0.9 در این مثال یک نقطه شروع عمومی برای همه برنامه‌ها نیست؛ انتخاب نهایی باید با آزمون انجام شود. تغییر پیکربندی را از مسیر مدیریت Nodeهای خود اجرا کنید. تنظیمات نسخه 1.37

یک مثال برای درک آستانه throttling

برای کانتینر Burstable، مستندات رابطه زیر را ارائه می‌کنند:

memory.high = request + factor × (limit - request)

اگر request برابر 256Mi، limit برابر 1Gi و factor برابر 0.9 باشد، آستانه حدود 947Mi خواهد بود. این عدد، ظرفیت اضافه یا تضمین زمان پاسخ ایجاد نمی‌کند. محاسبه رسمی آستانه

قبل از استفاده در محیط عملیاتی چه چیزی را بسنجیم؟

پیشنهاد اجرایی ما این است که ابتدا یک گروه محدود از Nodeها و یک بار کاری نماینده انتخاب کنید. ترکیب بار آزمایش باید به شرایط واقعی نزدیک باشد؛ تست یک برنامه تنها روی Node خلوت، رقابت واقعی را نشان نمی‌دهد.

زمان پاسخ صدک 95 و 99 و نرخ خطای برنامه را ثبت کنید.
مصرف حافظه، رخدادهای OOM، restart و eviction را کنار هم ببینید.
اثر تغییر بر برنامه‌های همسایه را نیز بررسی کنید.
دوره راه‌اندازی، پردازش‌های زمان‌بندی‌شده و اوج بار را پوشش دهید.
پیشاپیش معیار پذیرش و شرایط توقف آزمایش را تعیین کنید.

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

چه ارتباطی با VPA دارد؟

برای تفکیک مسئله، ابتدا دو سؤال مطرح کنید: «چه مقدار منبع برای برنامه مناسب است؟» و «وقتی رقابت حافظه رخ می‌دهد، رفتار سیستم چگونه باشد؟» مقاله VPA در Kubernetes به سؤال نخست می‌پردازد؛ این مقاله بر سؤال دوم متمرکز است.

در برنامه آزمایش، تغییر پیشنهاد منابع و تغییر سیاست حافظه را جداگانه ارزیابی کنید تا مشخص باشد کدام اقدام روی نتیجه اثر گذاشته است.

پرسش‌های متداول

آیا Memory QoS مانع تمام OOMها می‌شود؟

خیر. محدودیت ظرفیت و سقف سخت حافظه همچنان مطرح‌اند. علاوه بر رخدادهای OOM باید کیفیت سرویس را نیز بسنجید.

آیا برای هر Pod یک Feature Gate می‌گذاریم؟

پیکربندی ارائه‌شده مربوط به kubelet است. به‌ویژه سیاست رزرو حافظه روی تمام Podهای آن Node اثر دارد و نباید آن را تنظیم مستقل یک Deployment در نظر گرفت.