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

شکست پروب liveness یا startup می‌تواند به اجرای دوبارهٔ کانتینر منجر شود. شکست readiness معمولاً فقط اعلام آمادگی را تغییر می‌دهد و به‌خودی‌خود فرایند را متوقف نمی‌کند. اگر شروع برنامه واقعاً زمان‌بر است، startup probe فرصت لازم را پیش از فعال‌شدن liveness فراهم می‌کند. مسیر درخواست، پورت، پروتکل و مهلت پاسخ را با رفتار واقعی برنامه زیر بار بسنجید. حذف پروب یا ساختن پاسخ موفقِ صوری، علت خرابی را برطرف نمی‌کند.

kubectl --context='lab' -n 'academy-lab' get deployment 'api' -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\nresources="}{.resources}{"\nliveness="}{.livenessProbe}{"\nreadiness="}{.readinessProbe}{"\nstartup="}{.startupProbe}{"\n\n"}{end}'

مصرف فعلی حافظه الزاماً همان اوجی نیست که باعث توقف شده است. ممکن است Metrics Server نصب نباشد یا جهش کوتاه میان دو نمونه‌برداری رخ داده باشد. درخواست و سقف حافظه، پیش‌فرض‌های فضای نام، سهمیه‌ها و شرایط نود را همراه نمودارهای تاریخی بررسی کنید. افزایش request روی زمان‌بندی اثر می‌گذارد؛ افزایش limit فقط فضای بیشتری می‌دهد و نشت حافظه را درمان نمی‌کند. اگر نود تحت فشار است یا Pod تخلیه شده، بررسی ظرفیت و جانمایی بار را با مسئول کلاستر ادامه دهید. نام نود را از خروجی واقعی بگیرید و در فرم وارد کنید.

kubectl --context='lab' -n 'academy-lab' top pod 'api-example' --containers
kubectl --context='lab' -n 'academy-lab' get limitrange,resourcequota
kubectl --context='lab' get nodes
kubectl --context='lab' -n 'academy-lab' get events --field-selector involvedObject.name='api-example' --sort-by=.metadata.creationTimestamp
kubectl --context='lab' get pod 'api-example' -n 'academy-lab' -o jsonpath='{.spec.nodeName}{"\n"}'
# Replace the node name below with the observed .spec.nodeName.
kubectl --context='lab' describe node 'worker1'

رابطهٔ Pod با ReplicaSet و Deployment را از ownerReferences دنبال کنید. StatefulSet، Job، Pod ایستا و منابع تحت مدیریت اپراتورها شیوهٔ بازیابی دیگری دارند؛ فرمان بازگشت این راهنما برای آن‌ها نیست. شناسهٔ ایمیج، تغییر تنظیمات و تاریخچهٔ انتشار را مقایسه کنید. محتوای Secret یا مقادیر محرمانهٔ محیط اجرا را وارد گزارش نکنید.

kubectl --context='lab' -n 'academy-lab' get pod 'api-example' -o jsonpath='{.metadata.ownerReferences}'
kubectl --context='lab' -n 'academy-lab' rollout history deployment/'api'
kubectl --context='lab' -n 'academy-lab' get deployment 'api' -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{" "}{.image}{"\n"}{end}'

پس از انتشار تغییر تأییدشده، تکمیل rollout و وضعیت Podهای جایگزین را بررسی کنید. از کلاینت مجاز، یک کار واقعی برنامه را هم انجام دهید. شمارندهٔ restart از Pod قدیمی به Pod تازه منتقل نمی‌شود؛ UID و مقدار اولیهٔ شمارندهٔ Pod تازه را ثبت کنید و پس از مدت مناسب دوباره بسنجید. Ready بودن به‌تنهایی درست‌کارکردن برنامه یا متوقف‌شدن رشد حافظه را ثابت نمی‌کند.

kubectl --context='lab' -n 'academy-lab' rollout status deployment/'api' --timeout=180s
kubectl --context='lab' -n 'academy-lab' get pods -o wide
kubectl --context='lab' -n 'academy-lab' get deployment 'api' -o jsonpath='{.status.availableReplicas}{" available / "}{.spec.replicas}{" desired\n"}'

بازگشت نسخه اقدامی اختیاری است و خود یک انتشار تازه ایجاد می‌کند. فقط با تأیید مسئول سرویس و پس از بررسی سازگاری نسخهٔ قبلی با داده و ساختار فعلی، شمارهٔ نسخهٔ سالم را انتخاب کنید. تاریخچهٔ Deployment نسخهٔ پشتیبان پایگاه داده، دیسک پایدار یا تنظیمات بیرونی نیست. اگر سازگاری روشن نیست، طبق برنامهٔ مهار حادثه عمل کنید.

kubectl --context='lab' -n 'academy-lab' rollout undo deployment/'api' --to-revision='2'
kubectl --context='lab' -n 'academy-lab' rollout status deployment/'api' --timeout=180s