کارشناس زن در حال بررسی توقف کانتینر در فضای آموزشی Kubernetes

WIUNIX ACADEMY

عیب‌یابی CrashLoopBackOff و OOMKilled در Kubernetes؛ از شواهد تا رفع علت

علت توقف پی‌درپی کانتینر را با بررسی وضعیت خروج، لاگ اجرای قبلی، پروب‌ها و مصرف حافظه پیدا کنید و نتیجهٔ اصلاح را زیر بار واقعی بسنجید.

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

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

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

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

Debian 12بررسی‌شده با مستندات رسمی ·

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

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

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من7 مقدار قابل‌تغییر

از اینجا شروع کن

در پایان چه چیزی خواهی داشت؟

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

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

فرمان‌ها و تفاوت‌های محیط‌های منتخب با مستندات رسمی بررسی شده‌اند؛ این بررسی به معنای اجرای عملی روی همهٔ سیستم‌ها یا سرویس شما نیست. فرم فعلی نام‌های ساده تا ۳۲کاراکتر را می‌پذیرد؛ این محدودیت فرم است، نه Kubernetes. اگر نام واقعی طولانی‌تر است، مقدار نمونه را کپی نکنید؛ فرمان را در ویرایشگر خودتان با نام کامل تنظیم کنید. نام منبع را تغییر ندهید.

قبل از شروع

  • دسترسی مجاز به یک کلاستر موجود و Deployment مشخصی که مسئول آن اجازهٔ بررسی و تغییر را داده است.
  • نسخهٔ سازگار kubectl و مجوز خواندن Pod، رویدادها و لاگ؛ دسترسی به نمودارهای تاریخی مصرف منابع در صورت وجود.
  • شناخت مسیر انتشار سرویس و محدودیت بازگشت نسخه، به‌ویژه پس از تغییر ساختار داده.
01

قدم بعدی

ابزار میزبان انتخاب‌شده را آماده کنید

ابزارهای لازم را روی کامپیوتر یا سروری آماده کنید که فرمان‌های مدیریتی را از آن اجرا می‌کنید. پیش از تأیید، فهرست تغییر بسته‌ها را بخوانید؛ داخل کانتینر برنامه ابزار نصب نکنید. کلاستر، سرویس و باینری‌های اصلی باید از قبل با نسخهٔ مورد تأیید موجود باشند. پنل‌های بعد را در Bash اجرا کنید. نصب بسته روی همین میزبان تغییر ایجاد می‌کند، اما سرور برنامهٔ تازه‌ای راه نمی‌اندازد.

از kubectl لینوکسیِ موجود استفاده کنید که اختلاف آن با همهٔ نسخه‌های API Server حداکثر یک نسخهٔ فرعی باشد. پیش از ادامه نسخهٔ سرور را در کانتکست مجاز ببینید. برای این عیب‌یابی kubelet یا kubeadm نصب نکنید و مخزن بستهٔ کلاینت را بازنویسی نکنید.

bash

میزبان انتخاب‌شده؛ نصب بسته فقط با مجوز تغییر همین میزبان

sudo apt-get update
sudo apt-get install --no-install-recommends ca-certificates curl bash coreutils
cat /etc/os-release
command -v bash curl timeout
command -v kubectl
kubectl version --client --output=yaml
از کجا بدانم درست انجام شد؟

نسخهٔ سیستم با انتخاب شما یکسان باشد، ابزارها پیدا شوند و نسخهٔ کلاینت و سرویس با شرایط بالا سازگار باشند. اگر باینری موجود نیست یا سازگار نیست، ادامه ندهید.

حفاظت میزبان و مسیرهای نصب موجود را حفظ کنید

در Ubuntu و Debian ممکن است AppArmor و قواعد دیوارهٔ آتش میزبان فعال باشند. این روند پورت ورودی باز نمی‌کند و پروفایل امنیتی را تغییر نمی‌دهد. اگر دسترسی فایل یا شبکه رد شد، لاگ و سیاست سرویس را با مسئول آن بررسی کنید. مسیر نصب واقعی را حفظ کنید؛ مسیرهای نمونهٔ فرم، کشف خودکار محل نصب نیستند.

پیش از هر تغییر، معنای وضعیت را درست بخوانید

CrashLoopBackOff نام علت خرابی نیست. این وضعیت می‌گوید کانتینر چند بار متوقف شده و Kubernetes پیش از اجرای دوباره منتظر می‌ماند. در مقابل، OOMKilled یکی از دلیل‌های ثبت‌شده برای پایان اجراست. ممکن است وضعیت کلی Pod همچنان Running باشد، اما یکی از کانتینرهایش مرتب از کار بیفتد. کانتینر اصلی، کانتینر آغازین و کانتینر جانبی را از روی نام دقیق تشخیص دهید.

این راهنما بررسی یک Deployment موجود را دنبال می‌کند. برای جمع‌کردن شواهد، برنامه را عمداً خراب نکنید و با حذف Pod سرنخ‌های حادثه را از بین نبرید. نام کانتینر، زمان رخداد و نسخهٔ برنامه را در یادداشت داخلی ثبت کنید. لاگ ممکن است دادهٔ کاربر یا اطلاعات محرمانه داشته باشد؛ پیش از اشتراک‌گذاری آن را پالایش کنید.

02

قدم بعدی

کلاستر، فضای نام و مجوز بررسی را تأیید کنید

نام کانتکست در همهٔ فرمان‌ها صریح آمده تا بررسی ناخواسته روی کلاستر دیگری انجام نشود. آدرس سرور و فضای نام را با محدودهٔ بررسی توافق‌شده تطبیق دهید؛ شباهت نام Pod کافی نیست. تنظیمات فرم فقط در همین زبانهٔ مرورگر می‌مانند و جای واردکردن رمز یا توکن نیستند.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

kubectl config get-contexts 'lab'
kubectl --context='lab' get namespace 'academy-lab'
kubectl --context='lab' auth can-i get pods -n 'academy-lab'
kubectl --context='lab' -n 'academy-lab' get pod 'api-example' -o wide
از کجا بدانم درست انجام شد؟

کلاستر و Pod دقیقاً همان مقصد مجاز باشند و پاسخ بررسی مجوز yes باشد. اگر مقصد یا مجوز درست نیست، ادامه ندهید.

03

قدم بعدی

وضعیت آخرین توقف را پیش از اجرای بعدی ثبت کنید

به ستون STATUS اکتفا نکنید. وضعیت فعلی و آخرین وضعیت پایان‌یافتهٔ هر کانتینر را کنار هم بخوانید. کد خروج ۱۳۷ به‌تنهایی کمبود حافظه را ثابت نمی‌کند؛ دریافت SIGKILL هم می‌تواند همین کد را ایجاد کند. دلیل ثبت‌شدهٔ توقف، سقف منابع، وضعیت نود و زمان حادثه باید یکدیگر را تأیید کنند. با اجرای دوباره ممکن است تنها لاگ قبلیِ در دسترس از بین برود.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

kubectl --context='lab' -n 'academy-lab' get pod 'api-example' -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\nstate="}{.state}{"\nlastState="}{.lastState}{"\nrestarts="}{.restartCount}{"\n\n"}{end}'
kubectl --context='lab' -n 'academy-lab' describe pod 'api-example'
kubectl --context='lab' -n 'academy-lab' get pod 'api-example' -o jsonpath='{range .status.initContainerStatuses[*]}{.name}{"\nstate="}{.state}{"\nlastState="}{.lastState}{"\nrestarts="}{.restartCount}{"\n"}{end}'
از کجا بدانم درست انجام شد؟

نام کانتینر، دلیل و کد خروج، زمان شروع و پایان و رویدادهای هم‌زمان مشخص شده باشند.

04

قدم بعدی

لاگ اجرای فعلی و قبلی را با زمان توقف تطبیق دهید

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

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

kubectl --context='lab' -n 'academy-lab' logs 'api-example' -c 'app' --previous --timestamps --tail=200
kubectl --context='lab' -n 'academy-lab' logs 'api-example' -c 'app' --timestamps --tail=200
از کجا بدانم درست انجام شد؟

مشخص شود برنامه هنگام شروع خطا می‌دهد، حین کار استثنا رخ می‌دهد یا بدون پیام خروج متوقف می‌شود.

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