liveness probe और readiness probe में क्या फर्क है, और लोग इनमें गलती कैसे करते हैं?

readiness probe तय करता है कि pod को ट्रैफिक मिलेगा या नहीं; liveness probe तय करता है कि kubelet कंटेनर को रीस्टार्ट करेगा या नहीं। क्लासिक गलती है liveness को किसी downstream डिपेंडेंसी पर टिका देना, जिससे एक धीमा डेटाबेस हर pod को लूप में रीस्टार्ट करा देता है और आंशिक आउटेज को पूरा आउटेज बना देता है। liveness को सिर्फ यह जांचना चाहिए कि प्रोसेस जिंदा है और deadlock में नहीं है। धीरे बूट होने वाली एप्लिकेशन के लिए startup probe इस्तेमाल करें।

readiness तय करता है कि pod सर्विस endpoints में है या नहीं, liveness तय करता है कि kubelet कंटेनर को मारकर दोबारा चलाएगा या नहीं। जो नाकामी मैंने सच में देखी है वह एक टीम की थी जिसने liveness endpoint से डेटाबेस जंचवाया। डेटाबेस धीमा हुआ, लगभग एक ही वक्त हर pod का liveness फेल हुआ, पूरा deployment रीस्टार्ट लूप में चला गया, और अब खराब हालत में पढ़ने की जगह हमारे पास कुछ भी नहीं बचा, ऊपर से वापस आते वक्त ठंडे कनेक्शन की भगदड़। liveness लगभग उबाऊ होना चाहिए: क्या प्रोसेस एक मामूली handler सर्व कर सकती है, क्या event loop अटका तो नहीं है। डिपेंडेंसी से जुड़ी हर बात readiness में जानी चाहिए, क्योंकि किसी pod को रोटेशन से हटाना पलटा जा सकता है और सस्ता है। दूसरी चीज जो मैं हमेशा जांचता हूं वह है समय। अगर ऐप को कैश गरम करने में 45 सेकंड लगते हैं, तो या तो startup probe इस्तेमाल करें या initialDelaySeconds और failureThreshold उसी हिसाब से रखें, वरना आपने ऐसी मशीन बना दी है जो कभी बूट पूरा कर ही नहीं सकती।