एक pod CrashLoopBackOff में अटका है। आप इसकी छानबीन कैसे करेंगे?

events और आखिरी exit code के लिए kubectl describe pod से शुरू करें, फिर क्रैश हुए कंटेनर का आउटपुट पढ़ने को --previous के साथ kubectl logs चलाएं। exit code 137 का मतलब आम तौर पर OOM kill होता है, तो मेमोरी की सीमाएं जांचें; exit 1 या 2 का मतलब आम तौर पर ऐप startup पर फेल हुआ, अक्सर कोई गायब config, secret, या न पहुंच सकने वाली डिपेंडेंसी। पक्का करें कि image tag सच में मौजूद है और देखें कि कहीं कोई सख्त liveness probe तो यह लूप नहीं करा रहा।

पहले kubectl describe pod, क्योंकि events वाला हिस्सा आम तौर पर सीधे बता देता है कि यह image pull की नाकामी है, कोई गायब secret है, या OOM kill, और वह आपको exit code के साथ आखिरी terminated state भी देता है। फिर --previous के साथ kubectl logs, क्योंकि चल रहा कंटेनर पहले ही बदला जा चुका है और उसके लॉग गायब हैं। exit 137 SIGKILL है और दस में से नौ बार वह मेमोरी सीमा होती है, तो मैं अंदाजा लगाने के बजाय सीमा और असली इस्तेमाल की तुलना करता हूं। stack trace के साथ exit 1 एप्लिकेशन के startup की नाकामी है, आम तौर पर config। मैं liveness probe भी जांचता हूं, क्योंकि मैंने एक बिलकुल सेहतमंद Java सर्विस को सिर्फ इसलिए crash loop में देखा है कि उसे गरम होने में 40 सेकंड चाहिए थे और probe उसे 10 दे रहा था। शांति से डिबग करने के लिए मैं deployment को स्केल करूंगा, एक कॉपी में command को sleep से बदलकर exec करूंगा, और restart टाइमर से लड़ने के बजाय वहीं दोबारा दिक्कत पैदा करूंगा।