کوچ اجباری کوبرنتیز به cgroup v2؛ فراتر از فعال‌سازی یک پارامتر در کرنل

اجباری‌شدن cgroup v2 در نسخه‌های اخیر کوبرنتیز و فعال‌شدن پیش‌فرض پرچم failCgroupV1=true در ابزارهایی مانند kubeadm، دیگر فرصتی برای تعویق ارتقا باقی نگذاشته است. اما خطای رایج تیم‌های زیرساخت این است که تصور می‌کنند تغییر cgroup تنها با اضافه کردن یک آرگومان به GRUB خاتمه می‌یابد. در محیط‌های پربار، این تغییر روی الگوی محاسباتی OOMKilled، ران‌تایم‌های کانتینری و رفتار برنامه‌ها تأثیر مستقیم دارد.

چرا معماری cgroup v1 دیگر پاسخگو نبود؟

در معماری قدیمی v1، هر کنترل‌کننده (CPU, Memory, blkio) سلسله‌مراتب درختی کاملاً مستقلی داشت. در این وضعیت، اگر فرایندی داخل یک کانتینر حافظه زیادی به عنوان Page Cache دیسک اشغال می‌کرد، کنترل‌کننده حافظه نمی‌توانست با کنترل‌کننده blkio هماهنگ شود تا جلوی I/O اضافه را بگیرد. نتیجه این ناهماهنگی در سرورهای عملیاتی، قفل شدن تصادفی I/O و تصمیم‌گیری‌های غیرقابل پیش‌بینی کرنل در سناریوهای کمبود رم بود.

در cgroup v2 یک سلسله‌مراتب واحد (Single Unified Hierarchy) جایگزین شده است که در آن هر پردازه تنها می‌تواند به یک گروه والد متصل باشد.

بهبود محاسبات با معیار PSI (Pressure Stall Information)

یکی از اساسی‌ترین دلایل مهاجرت، دسترسی به معیارهای PSI است. تا پیش از این، مانیتورینگ حافظه تنها می‌توانست به شما بگوید چه میزان از ظرفیت پر است، اما نمی‌توانست نشان دهد برنامه‌ها چند میلی‌ثانیه معطل بازیابی حافظه (Reclaim) شده‌اند. معیارهای PSI نشان می‌دهند چه درصدی از زمان پردازش، پردازه‌ها به خاطر دسترسی به حافظه، رم یا I/O معطل مانده‌اند.

گام‌های عملیاتی پیش از فعال‌سازی روی نودها

1. بررسی وضعیت فعلی کنترل‌کننده‌ها در سیستم‌عامل: ابتدا بررسی کنید کرنل سیستم با کدام نسخه بالا آمده است:

   stat -fc %T /sys/fs/cgroup/
   

   اگر خروجی cgroup2fs باشد، v2 فعال است؛ اگر tmpfs باشد، هنوز v1 فعال است.

2. اعتبارسنجی ران‌تایم کانتینر (Containerd / CRI-O): مطمئن شوید در پیکربندی containerd از SystemdCgroup = true استفاده شده باشد. مدیریت مستقیم cgroup توسط ران‌تایم به جای systemd در v2 خطاهای متعددی ایجاد می‌کند.

3. ارزیابی نسخه‌های قدیمی کتابخانه‌ها: سرویس‌های قدیمی جاوا (نسخه‌های ماقبل OpenJDK 8u372 و ماقبل 11.0.16) کدهای بررسی متفاوتی برای cgroup v2 دارند و ممکن است سقف حافظه کانتینر را تشخیص نداده و با خطای OOM مواجه شوند.

روال پیشنهادی ارتقای نودها (SOP)

• نود را با kubectl cordon و kubectl drain از مدار خارج کنید.
• آرگومان کرنل systemd.unified_cgroup_hierarchy=1 را به پارامترهای بوت GRUB اضافه و سرور را ریست کنید.
• سلامت سرویس Kubelet و ارتباط آن با containerd را بسنجید.
• یک پاد آزمایشی با محدودیت سفت‌وسخت حافظه مستقر کرده و فایل /sys/fs/cgroup/memory.current آن را بررسی کنید.
• نود را مجدداً uncordon کرده و به ترافیک برگردانید.

جمع‌بندی؛ تغییر در سطح لایه مبنا

مهاجرت به cgroup v2 انتخابی نیست، بلکه یک استاندارد زیرساختی برای ثبات کلاسترهای مدرن است. پیشنهاد ما این است که پیش از رسیدن نسخه‌های ارتقای کوبرنتیز به چرخه تولید، این مهاجرت را نود به نود و با مانیتورینگ دقیق نرخ OOMKilled پیش ببرید.