فضای آموزشی عملیاتیِ بدون آدم با تابلوی فشار منابع نود و مراحل تشخیص eviction

WIUNIX ACADEMY

پاد Evicted در Kubernetes؛ فشار نود رو از OOM و زمان‌بندی جدا کن

علت Evicted رو با وضعیت نود در همان زمان تطبیق بده؛ فرقش با OOM کانتینر، مشکل زمان‌بندی و نپذیرفتن پاد توسط kubelet رو روشن کن و بازیابی رو با کار واقعی برنامه بسنج.

پیشرفته35 دقیقه مطالعهبه‌روزرسانی
محیطت رو انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.

AlmaLinux 9بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه رو با مشخصات سرورت عوض کن تا متن و دستورها با هم تغییر کنن. رمز، کلید خصوصی و توکن اینجا وارد نکن. مقدارها فقط توی همین زبانه می‌مونن و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شن. قبل از اجرا، 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 یا جایگزین کنترل‌کننده، مشاهدهٔ جدید است و ادامهٔ همان پاد قبلی نیست.

مقدارها برای همین زبان و محیط در همین تب می‌مونن. تغییر معلق یا نامعتبر تا اعمال یا بازنشانی، کپی رو متوقف می‌کنه. محدودیت نام سادهٔ ۳۲ نویسه‌ای از فرم میاد. اگر نام واقعی بلندتره یا مثلاً نقطه داره، دستورهای همان شاخه رو در ویرایشگر مورد اعتماد با نام دقیق منابع خودت آماده کن؛ اسم رو کوتاه نکن و شیء رو تغییر نام نده. اطلاعات ورود وارد فرم نمی‌شن.

01

قدم بعدی

ابزار و کانال واقعی همین میزبان رو ببین

انتخاب سیستم‌عامل برای میزبان اجرای kubectl است، نه گواهی سازگاری سیستم‌عامل نودها. از همان حساب عادیِ مجاز و kubectl مورد تأیید تیم استفاده کن؛ اجرای kubectl با sudo می‌تونه kubeconfig و هویت متفاوتی انتخاب کنه. این ابزار روی میزبان مدیریت daemon نیست و برایش kubelet یا کلاستر تازه راه نمی‌اندازیم.

بسته‌های پایه و نسخهٔ خود کلاینت رو بخون. نبود ابزار یعنی قبل از ادامه، کلاینت سازگار رو در تغییر برنامه‌ریزی‌شده با روش رسمی تیم آماده کنی. آخرین نسخهٔ تصادفی، بستهٔ آرچ روی مانجارو یا مخزن خارجیِ تأییدنشده راه آماده‌سازی این رخداد نیست. راهنمای رسمی، دریافت نسخهٔ مشخص و بررسی checksum باینری رو هم توضیح می‌ده؛ این آموزش عمداً کلاینت موجود و مجاز رو پیش‌نیاز می‌گیره.

در شاخهٔ ۱۰/۹ از نسخهٔ فرعی پشتیبانی‌شده و به‌روز و مخزن مجاز RHEL یا مخزن رسمی راکی/آلما برای بستهٔ پایه استفاده کن. kubectl و افزونهٔ مجاز فعلی رو نگه دار. SELinux، firewalld و سیاست رمزنگاری میزبان حفظ می‌شن؛ پورت ورودی یا سرویس نود تازه لازم نیست.

bash

میزبان مدیریت با حساب عادی مجاز

cat /etc/os-release
uname -m
rpm -q ca-certificates bash coreutils
command -v bash kubectl
kubectl version --client --output=yaml
از کجا بفهمم درست انجام شده؟

کلاینت موجود و سازگار و بسته‌های پایه مشخصن؛ نبود هرکدوم آماده‌سازی رو متوقف می‌کنه.

02

قدم بعدی

محدودیت SELinux و مسیر API رو جدا ببین

SELinux و firewalld و سیاست رمزنگاری فعلیِ میزبان مدیریت رو نگه دار. خطای افزونه یا kubeconfig یا اعتماد TLS رو با مسئول همان میزبان حل کن؛ سیاست رو permissive نکن، مسیرها رو بازگشتی relabel نکن و پورت عمومی تازه باز نکن. این بررسی فقط وضعیت موجود رو می‌خونه و دربارهٔ سیاست نودهای کلاستر رأی نمی‌ده.

bash

میزبان مدیریت؛ فقط خواندن وضعیت

if command -v getenforce >/dev/null 2>&1; then getenforce; fi
if command -v firewall-cmd >/dev/null 2>&1; then firewall-cmd --state; fi
از کجا بفهمم درست انجام شده؟

وضعیت قابل‌مشاهده ثبت شده و خطای سیاست با مالک میزبان پیگیری می‌شه؛ حفاظتی خاموش نشده.

03

قدم بعدی

context رو مشخص کن و همان نشست رو نگه دار

نام context رو با مقصد مورد تأییدت تطبیق بده و همین شل Bash رو تا پایان نگه دار. تابع k در پنل‌های بعدی همان context رو صریح انتخاب می‌کنه و برای هر درخواست مهلت می‌ذاره. اگر شل تازه باز کردی، این مرحله رو دوباره انجام بده؛ context خالی نباید بی‌صدا به مقصد دیگری تبدیل بشه.

در تاریخ بررسی، شاخه‌های نگهداری‌شدهٔ upstream برابر ۱٫۳۷، ۱٫۳۶ و ۱٫۳۵ هستن. kubectl باید حداکثر یک نسخهٔ minor با همهٔ API serverهایی که ممکنه بهشون وصل بشه اختلاف داشته باشه؛ کلاستر HA هنگام ارتقا این بازه رو محدودتر می‌کنه. محدودیت عرضه‌کننده و نسخهٔ درایور هم جداست. خطا یا نرسیدن به نسخهٔ سرور، اجازهٔ ادامه بر اساس حدس نیست.

bash

همان شل 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 برای همین شل آماده است.

04

قدم بعدی

دید واقعیِ حساب رو روشن کنیم

خواندن namespace رو جدا از نود، پاد/رخداد همهٔ namespaceها و metrics بسنج. ممکنه مسئول نود یا پلتفرم باید بخش کلاستری شواهد رو جمع کنه. جواب no ثابت نمی‌کنه آن نشانه وجود نداره؛ مجوز metrics هم نصب‌بودن API یا تازه‌بودن نمونه رو تضمین نمی‌کنه.

پیام پاد، نام‌ها و مشخصات نود رو خصوصی نگه دار. فقط برای کامل‌شدن شاخهٔ اختیاری این آموزش، دسترسی proxy نود، پاد debug با مجوز بالا یا cluster-admin نخواه. برای تشخیص اولیه به kubeconfig خام، Secret یا بدنهٔ لاگ برنامه نیاز نداریم.

bash

همان شل 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
از کجا بفهمم درست انجام شده؟

مشاهده‌های در دسترس و مسئولِ کمک برای بخش دیده‌نشده مشخصن.

همهٔ آموزش‌های آکادمی ↗