WIUNIX ACADEMY
پاد Evicted در Kubernetes؛ فشار نود رو از OOM و زمان‌بندی جدا کن
علت Evicted رو با وضعیت نود در همان زمان تطبیق بده؛ فرقش با OOM کانتینر، مشکل زمان‌بندی و نپذیرفتن پاد توسط kubelet رو روشن کن و بازیابی رو با کار واقعی برنامه بسنج.
محیطت رو انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه رو با مشخصات سرورت عوض کن تا متن و دستورها با هم تغییر کنن. رمز، کلید خصوصی و توکن اینجا وارد نکن. مقدارها فقط توی همین زبانه می‌مونن و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شن. قبل از اجرا، DNS، گواهی‌ها و تنظیمات دسترسی شبکه رو روی سرورت بررسی کن.
اگر آی‌پی، دامنه یا پورت‌های نمونه با سرورت فرق دارن، بخش تنظیمات پایین رو باز کن. مقدارها رو عوض کن و «اعمال در آموزش» رو بزن؛ بعد دستورهای تازه رو کپی کن.
تنظیم مقادیر برای محیط من3 مقدار قابل‌تغییر
از اینجا شروع کن
آخر این آموزش چی خواهیم داشت؟
علت Evicted رو با وضعیت نود در همان زمان تطبیق بده؛ فرقش با OOM کانتینر، مشکل زمان‌بندی و نپذیرفتن پاد توسط kubelet رو روشن کن و بازیابی رو با کار واقعی برنامه بسنج.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
این مسیر برای مشاهدهٔ کلاستر موجود از میزبان مدیریت لینوکس است؛ انتخاب OS نسخهٔ نودهای کلاستر رو تعیین نمی‌کنه. شاخه‌های upstream نگهداری‌شدهٔ ۱٫۳۵ تا ۱٫۳۷ و محدودیت skew کلاینت در ۲۰۲۶-۱۱-۰۵ مرور شده‌اند؛ پشتیبانی عرضه‌کننده، runtime و سیاست واقعی نود جدا بررسی می‌شه. فرم نام ساده تا ۳۲ نویسه رو می‌پذیره؛ این محدودیت فرم است، نه Kubernetes. اگر نام واقعی بلندتره یا نویسه‌ای بیرون از فرم داره، دستورهای همان شاخه رو در ویرایشگر مورد اعتماد با نام دقیق منابع خودت آماده کن؛ اسم رو کوتاه نکن و شیء رو تغییر نام نده. هیچ فرمان این راهنما هنگام نویسندگی روی کلاستر اجرا نشده و ماتریس اجرای همهٔ OSها ادعا نمی‌شه.
قبل از شروع
- کلاستر موجود، context و هویت مورد اعتماد و مجاز، kubectl سازگار و نام دقیق منابع و زمان رخداد.
- دسترسی خواندن پاد و رخداد همان namespace؛ دیدن نود، رخدادها و پادهای کل کلاستر و metrics ممکنه مجوز جدا بخواد. نبود دسترسی رو با مسئول نود یا پلتفرم پیگیری کن.
- روش موجود مدیریت تغییر و بازیابی برنامه و محل خصوصی برای شواهد؛ دادهٔ حساس و رمز و kubeconfig وارد فرم یا گزارش عمومی نمی‌شن.
اول بفهمیم چه چیزی پاد رو متوقف کرده
پادی با وضعیت Evicted با کانتینری که OOMKilled شده یکی نیست؛ پادی هم که هنوز زمان‌بندی نشده مسیر دیگری داره. UID و پیام همان پاد ناموفق رو به نود واقعی، سابقهٔ فشار و تنظیم منابع برنامه وصل می‌کنیم. در این راهنما پادی حذف، drain، ری‌استارت یا عمداً تحت بار گذاشته نمی‌شه.
kubelet می‌تونه برای آزادکردن منبع کمیاب روی نود، پاد رو متوقف کنه. کنترل‌کننده ممکنه یک پاد تازه با UID جدید و حتی روی نود دیگری بسازه. حذف شیء ناموفق حافظه، بایت دیسک، inode یا ظرفیت پردازش اضافه نمی‌کنه؛ شواهد اولیه رو تا ثبت علت توسط مسئول نگه دار.
روی کلاستر موجود در شاخه‌های نگهداری‌شدهٔ ۱٫۳۵ تا ۱٫۳۷ کار می‌کنیم و محدودیت عرضه‌کننده و runtime جداست. راهنمای CrashLoop/OOM برای خطای شروع و تکرار کانتینر است؛ اینجا فشار نود، انتخاب قربانی و پذیرش پاد رو بررسی می‌کنیم. kubelet نصب نمی‌کنیم، آستانهٔ eviction رو عوض نمی‌کنیم و بارساز اجرا نمی‌کنیم.
پاد ناموفق و نود واقعی‌اش رو انتخاب کن
فرم مقادیر نمونه رو باز کن و namespace و پاد ناموفق واقعی رو اعمال کن. قبل از عوض‌کردن نمونهٔ نود، نود تخصیص‌یافتهٔ پاد رو بخون. حتی نام یکسان ممکنه UID تازه داشته باشه؛ replica یا جایگزین کنترل‌کننده، مشاهدهٔ جدید است و ادامهٔ همان پاد قبلی نیست.
مقدارها برای همین زبان و محیط در همین تب می‌مونن. تغییر معلق یا نامعتبر تا اعمال یا بازنشانی، کپی رو متوقف می‌کنه. محدودیت نام سادهٔ ۳۲ نویسه‌ای از فرم میاد. اگر نام واقعی بلندتره یا مثلاً نقطه داره، دستورهای همان شاخه رو در ویرایشگر مورد اعتماد با نام دقیق منابع خودت آماده کن؛ اسم رو کوتاه نکن و شیء رو تغییر نام نده. اطلاعات ورود وارد فرم نمی‌شن.
قدم بعدی
ابزار و کانال واقعی همین میزبان رو ببین
انتخاب سیستم‌عامل برای میزبان اجرای kubectl است، نه گواهی سازگاری سیستم‌عامل نودها. از همان حساب عادیِ مجاز و kubectl مورد تأیید تیم استفاده کن؛ اجرای kubectl با sudo می‌تونه kubeconfig و هویت متفاوتی انتخاب کنه. این ابزار روی میزبان مدیریت daemon نیست و برایش kubelet یا کلاستر تازه راه نمی‌اندازیم.
بسته‌های پایه و نسخهٔ خود کلاینت رو بخون. نبود ابزار یعنی قبل از ادامه، کلاینت سازگار رو در تغییر برنامه‌ریزی‌شده با روش رسمی تیم آماده کنی. آخرین نسخهٔ تصادفی، بستهٔ آرچ روی مانجارو یا مخزن خارجیِ تأییدنشده راه آماده‌سازی این رخداد نیست. راهنمای رسمی، دریافت نسخهٔ مشخص و بررسی checksum باینری رو هم توضیح می‌ده؛ این آموزش عمداً کلاینت موجود و مجاز رو پیش‌نیاز می‌گیره.
مسیر غلتان میزبان مدیریت در ۲۰۲۶-۱۱-۰۵ بررسی شده. بسته‌های نصب‌شده و باینری مجاز kubectl رو ببین؛ کلاینت مخزن روز الزاماً با کلاستر قدیمی سازگار نیست. هر ارتقای کامل رو جدا برنامه‌ریزی کن؛ ارتقای ناقص، ابزار AUR یا تغییر شاخه و مخزن مانجارو لازم نداریم.
میزبان مدیریت با حساب عادی مجاز
cat /etc/os-release
uname -m
pacman -Q ca-certificates bash coreutils
command -v bash kubectl
kubectl version --client --output=yamlکلاینت موجود و سازگار و بسته‌های پایه مشخصن؛ نبود هرکدوم آماده‌سازی رو متوقف می‌کنه.
قدم بعدی
اعتماد و دسترسی میزبان رو حفظ کن
فقط kubeconfig و افزونهٔ احراز هویتِ مورد اعتماد تیم رو استفاده کن؛ یک فایل ناشناس می‌تونه اجرای برنامهٔ احراز هویت رو درخواست کنه. کلید و توکن و متن کامل تنظیمات رو چاپ یا در فرم وارد نکن. مجوز فایل و CA فعلی رو حفظ کن؛ برای رفع خطای اتصال، بررسی TLS رو خاموش نکن.
kubectl از این میزبان به API مجاز وصل می‌شه و پورت ورودی تازه نمی‌خواد. AppArmor یا سیاست امنیتی فعلی رو نگه دار و خطای اجرای افزونه، دسترسی فایل یا اتصال رو با مسئول میزبان حل کن. این مشاهدهٔ کرنل فقط به میزبان مدیریت مربوطه؛ تنظیم امنیتی نود کلاستر رو ثابت نمی‌کنه.
همان شل Bash مجاز روی میزبان مدیریت
sudo journalctl -k --since '-10 min' --no-pager -n 60خطای اعتماد، افزونه یا مجوز میزبان از خطای کلاستر جدا شده و هیچ سیاستی خاموش نشده.
قدم بعدی
context رو مشخص کن و همان نشست رو نگه دار
نام context رو با مقصد مورد تأییدت تطبیق بده و همین شل Bash رو تا پایان نگه دار. تابع k در پنل‌های بعدی همان context رو صریح انتخاب می‌کنه و برای هر درخواست مهلت می‌ذاره. اگر شل تازه باز کردی، این مرحله رو دوباره انجام بده؛ context خالی نباید بی‌صدا به مقصد دیگری تبدیل بشه.
در تاریخ بررسی، شاخه‌های نگهداری‌شدهٔ upstream برابر ۱٫۳۷، ۱٫۳۶ و ۱٫۳۵ هستن. kubectl باید حداکثر یک نسخهٔ minor با همهٔ API serverهایی که ممکنه بهشون وصل بشه اختلاف داشته باشه؛ کلاستر HA هنگام ارتقا این بازه رو محدودتر می‌کنه. محدودیت عرضه‌کننده و نسخهٔ درایور هم جداست. خطا یا نرسیدن به نسخهٔ سرور، اجازهٔ ادامه بر اساس حدس نیست.
همان شل Bash مجاز روی میزبان مدیریت
context=$(kubectl config current-context) || exit 1
test -n "$context" || exit 1
printf 'Selected context: %s\n' "$context"
k() {
test -n "${context:-}" || { printf 'STOP: load the selected context in this shell first.\n' >&2; return 1; }
kubectl --context "$context" --request-timeout=20s "$@"
}
k version --output=yaml
context موردنظر و نسخه‌های واقعی تأیید شده‌اند و تابع k برای همین شل آماده است.
قدم بعدی
دید واقعیِ حساب رو روشن کنیم
خواندن namespace رو جدا از نود، پاد/رخداد همهٔ namespaceها و metrics بسنج. ممکنه مسئول نود یا پلتفرم باید بخش کلاستری شواهد رو جمع کنه. جواب no ثابت نمی‌کنه آن نشانه وجود نداره؛ مجوز metrics هم نصب‌بودن API یا تازه‌بودن نمونه رو تضمین نمی‌کنه.
پیام پاد، نام‌ها و مشخصات نود رو خصوصی نگه دار. فقط برای کامل‌شدن شاخهٔ اختیاری این آموزش، دسترسی proxy نود، پاد debug با مجوز بالا یا cluster-admin نخواه. برای تشخیص اولیه به kubeconfig خام، Secret یا بدنهٔ لاگ برنامه نیاز نداریم.
همان شل Bash مجاز روی میزبان مدیریت
k auth can-i get pods -n 'apps'
k auth can-i list events -n 'apps'
k auth can-i get nodes
k auth can-i list pods --all-namespaces
k auth can-i list events --all-namespaces
k auth can-i get nodes.metrics.k8s.ioمشاهده‌های در دسترس و مسئولِ کمک برای بخش دیده‌نشده مشخصن.