اجرای کانتینرها در محیط تولید یک موضوع است؛ اما حفظ عملکرد پایدار آن‌ها موضوعی دیگر است. برای توسعه‌دهندگان سطح متوسط تا پیشرفته، مواجهه با یک پاد در حال کرش کردن یا غیرفعال در خوشه کوبرنیتس تنها یک آزاردهندگی نیست، بلکه یک حادثه حیاتی است که نیاز به رفع سریع و روشمند دارد. چه با خطاهای CrashLoopBackOff، شکست در کشیدن تصویر (image pull) یا زمان‌بر شدن شبکه سروکار داشته باشید، داشتن یک رویکرد سیستماتیک برای اشکال‌زدایی ضروری است.
این راهنما فراتر از سینتکس‌های پایه می‌رود و به جریان کاری عملی تشخیص و رفع مشکلات رایج پاد در کوبرنیتس می‌پردازد. در پایان، شما یک مدل ذهنی قوی برای جداسازی شکست‌ها در چرخه حیات کانتینر خواهید داشت.
مرحله ۱: بررسی وضعیت پاد و رویدادها
اولین قدم در هر جلسه عیب‌یابی، درک وضعیت فعلی بار کاری است. هرگز بدون دانستن دلیل ورود پاد به وضعیت فعلی‌اش، مستقیماً وارد بررسی لاگ‌ها نشوید. دستور kubectl get pods وضعیت کلی را به شما می‌دهد، اما اغلب برای تشخیص عمیق کافی نیست.
در عوض، همیشه این دستور را با kubectl describe pod ترکیب کنید. این دستور خروجی مفصلی ارائه می‌دهد که شامل رویدادهای پاد است؛ رویدادهایی که برای درک اقدامات برنامه‌ریز (scheduler) و دلایل شکست حیاتی هستند.
# بررسی وضعیت کلی پادها در نامسپیس 'default'
kubectl get pods -n default
# دریافت اطلاعات دقیق درباره یک پاد خاص، شامل رویدادها
kubectl describe pod my-app-pod-xyz123 -n defaultبه دقت به بخش Events (رویدادها) در انتهای خروجی نگاه کنید. آیا FailedScheduling را مشاهده می‌کنید؟ این معمولاً به محدودیت‌های منابع (درخواست‌های CPU/رم) یا مسائل مربوط به هم‌افزایی گره (node affinity) اشاره دارد. آیا ImagePullBackOff را می‌بینید؟ این نشان‌دهنده مشکل احراز هویت در رجیستری یا اشتباه تایپی در تگ تصویر است. رفع این مشکلات لایه اول اغلب سریع‌تر از کاوش در لاگ‌های برنامه است.
مرحله ۲: بازرسی لاگ‌های کانتینر
پس از تأیید اینکه پاد در حالت اجرا قرار دارد (یا تازه کرش کرده است)، منطقی‌ترین قدم بعدی بررسی خروجی برنامه است. کوبرنیتس خروجی stdout و stderr از نقطه ورود (entrypoint) کانتینر را در لاگ‌های قابل دسترسی جمع‌آوری می‌کند.
از kubectl logs برای پخش زنده یا دریافت لاگ‌ها استفاده کنید. اگر یک پاد در حالت CrashLoopBackOff باشد، به این معنی است که کانتینر شروع به کار کرده، با خطا مواجه شده و خارج شده است. شما باید لاگ‌ها را از نمونه قبلی کانتینر بررسی کنید.
# مشاهده لاگ‌های نمونه جاری در حال اجرا
kubectl logs my-app-pod -n default
# مشاهده لاگ‌های نمونه قبلی کانتینر در صورت کرش کردن
kubectl logs my-app-pod --previous -n defaultهنگام تحلیل این لاگ‌ها، به دنبال ردپای پشته (stack traces)، خطاهای فاتال یا استثناهای پیکربندی باشید. اگر لاگ‌ها خالی باشند، ممکن است کانتینر در یک حلقه بی‌پایان گیر کرده باشد یا منتظر یک سیگنال باشد که نیاز به بررسی بیشتر از طریق exec دارد.
مرحله ۳: اشکال‌زدایی تعاملی با Exec
گاهی اوقات لاگ‌ها کافی نیستند. ممکن است نیاز به بررسی فایل سیستم، متغیرهای محیطی یا تست اتصال شبکه از داخل زمینه کانتینر داشته باشید. اینجاست که kubectl exec به قدرتمندترین ابزار شما تبدیل می‌شود.
# باز کردن یک پوسته bash در کانتینر در حال اجرا
kubectl exec -it my-app-pod -- /bin/bash
# بررسی متغیرهای محیطی
printenv
# تست اتصال به یک سرویس خارجی یا پایگاه داده
curl -v http://internal-service:8080/health
# فهرست کردن فایل‌ها برای بررسی صحیح نصب شدن نقشه‌های پیکربندی
ls -la /etc/configجلسات تعاملی برای تشخیص مشکلات نصب حجم (volume mount) به ویژه مفید هستند. اگر برنامه شما نمی‌تواند یک فایل پیکربندی را پیدا کند که در یک ConfigMap یا Secret وجود دارد، بررسی دایرکتوری نصب شده از طریق exec فوراً نشان می‌دهد که آیا مسیر نصب نادرست است یا مجوزها اشتباه هستند.
مرحله ۴: بررسی محدودیت‌های منابع
یکی از شایع‌ترین دلایل مرگ خاموش پاد، رسیدن به محدودیت‌های منابع است. اگر یک کانتینر از محدودیت‌های CPU یا رم خود فراتر رود، قاتل حافظه (OOM killer) هسته لینوکس ممکن است آن را بدون ارائه زمینه کافی در لاگ‌های برنامه، خاتمه دهد.
مصرف منابع را با دستور زیر بررسی کنید:
kubectl top pod my-app-podمصرف گزارش شده را با resources.limits تعریف شده در مانیفست YAML خود مقایسه کنید. اگر مصرف به طور مداوم نزدیک به حد مجاز باشد، ممکن است نیاز به مقیاس‌دهی افقی یا تنظیم مجدد محدودیت‌ها داشته باشید. علاوه بر این، اگر پاد به طور مکرر در حال راه‌اندازی مجدد است، لاگ‌های سیستم روی گره زیرین (از طریق journalctl در گره‌های لینوکس) را برای پیام‌های قاتل حافظه بررسی کنید.
نتیجه‌گیری
عیب‌یابی پادهای کوبرنیتس بیشتر درباره دنبال کردن یک مسیر تشخیص منطقی است تا حفظ کردن دستورات: وضعیت → رویدادها → لاگ‌ها → بازرسی داخلی → منابع. با تسلط بر این چهار مرحله، می‌توانید شکست‌ها را به طور کارآمد جداسازی کنید، میانگین زمان تا رفع خرابی (MTTR) را کاهش دهید و پایداری برنامه‌های کانتینری خود را حفظ کنید. به یاد داشته باشید، کوبرنیتس تمام ابزارهای مورد نیاز شما را فراهم می‌کند؛ شما فقط باید بدانید چگونه از آن‌ها به ترتیب استفاده کنید.