🕔 🚛 🧝🏿 कुबेरनेट्स: एक चूल्हा का जीवन 👲🏾 👻 🧘🏽

लगभग। ट्रांस। : Red Hat में OpenShift टीम की ओर से माइकल हौसेनब्लास द्वारा लिखा गया यह छोटा (लेकिन कैपेसिटिव!) लेख हमें इतना पसंद आया कि इसे खोजे जाने के लगभग तुरंत बाद हमारे Kubernetes के आंतरिक ज्ञानकोष में जोड़ दिया गया। और चूंकि इसमें प्रस्तुत की गई जानकारी स्पष्ट रूप से व्यापक रूसी-भाषी आईटी समुदाय के लिए उपयोगी होगी, इसलिए हम इसका अनुवाद पोस्ट करके खुश हैं।

जैसा कि आपने अनुमान लगाया होगा, इस प्रकाशन का शीर्षक 1998 के पिक्सर कार्टून "ए बग्स लाइफ़" (रूसी बॉक्स ऑफ़िस में इसे "एडवेंचर्स ऑफ़ फ़्लिक" या "द लाइफ़ ऑफ़ ए कीट" - लगभग अनुवाद। ) और वास्तव में चींटी के बीच का संदर्भ है। श्रमिकों और चूल्हों के साथ कुबेरनेट्स में बहुत कुछ है। हम व्यावहारिक रूप से चूल्हा के पूर्ण जीवन चक्र को ध्यान से देखेंगे - विशेष रूप से, ऐसे तरीके जिनसे आप स्टार्टअप और शटडाउन पर व्यवहार को प्रभावित कर सकते हैं, साथ ही आवेदन की स्थिति की जांच करने के लिए सही दृष्टिकोण भी देख सकते हैं।

चाहे आप खुद के तहत बनाए गए या बेहतर, परिनियोजन , डेमनसेट या स्टेटफुलसेट जैसे नियंत्रक के माध्यम से, निम्न चरणों में से एक में हो सकते हैं:

लंबित : API सर्वर ने एक पॉड संसाधन बनाया और इसे etcd में सहेजा, लेकिन यह अभी तक नियोजित नहीं था, और इसके कंटेनरों की छवियां रजिस्ट्री से प्राप्त नहीं हुई थीं;
रनिंग (कामकाज): अंडर को नोड को सौंपा गया था और सभी कंटेनरों को क्यूबलेट द्वारा बनाया गया था ;
सफल (सफलतापूर्वक पूरा हुआ): सभी चूल्हा कंटेनरों का संचालन सफलतापूर्वक पूरा हो चुका है और वे पुनः आरंभ नहीं करेंगे;
विफल : चूल्हा में सभी कंटेनरों ने काम करना बंद कर दिया है और कम से कम एक कंटेनर विफल हो गया है;
अज्ञात : एपीआई सर्वर चूल्हा की स्थिति को क्वेरी करने में सक्षम नहीं था, आमतौर पर क्यूबलेट के साथ बातचीत में त्रुटि के कारण।

kubectl get pod को निष्पादित kubectl get pod , ध्यान दें कि STATUS कॉलम अन्य (इन पांच को छोड़कर) संदेश दिखा सकता है - उदाहरण के लिए, Init:0/1 CrashLoopBackOff या CrashLoopBackOff । यह इसलिए है क्योंकि चरण चूल्हा की सामान्य स्थिति का केवल एक हिस्सा है। यह पता लगाने का एक अच्छा तरीका है कि वास्तव में क्या हुआ है kubectl describe pod/$PODNAME को चलाने के लिए और नीचे दिए गए kubectl describe pod/$PODNAME प्रविष्टि को देखें। वह प्रासंगिक कार्यों की एक सूची प्रदर्शित करती है: कंटेनर छवि प्राप्त हुई थी, इसके लिए योजना बनाई गई थी, कंटेनर " अस्वस्थ" स्थिति में है।

अब शुरू से अंत तक चूल्हा के जीवन चक्र के एक विशिष्ट उदाहरण पर एक नज़र डालें, जैसा कि निम्नलिखित चित्र में दिखाया गया है:

यहाँ क्या हुआ? चरण इस प्रकार हैं:

यह आरेख में नहीं दिखाया गया है, लेकिन शुरुआत में एक विशेष इन्फ्रा-कंटेनर लॉन्च किया गया है और नामस्थान स्थापित करता है जिसमें शेष कंटेनर शामिल होते हैं।
पहला उपयोगकर्ता-परिभाषित कंटेनर जो प्रारंभ होता है वह इनिट कंटेनर है ; इसका उपयोग आरंभीकरण कार्यों के लिए किया जा सकता है।
अगला, मुख्य कंटेनर और पोस्ट-स्टार्ट हुक एक साथ लॉन्च किए जाते हैं; हमारे मामले में, यह 4 सेकंड के बाद होता है। प्रत्येक कंटेनर के लिए हुक परिभाषित किए गए हैं ।
फिर, 7 वें सेकंड में, लिनन और तत्परता परीक्षण खेल में आते हैं, फिर से प्रत्येक कंटेनर के लिए।
11 वें सेकंड में, जब अंडर मारा जाता है, तो प्री-स्टॉप हुक को ट्रिगर किया जाता है और मुख्य कंटेनर को अनुग्रह अवधि के बाद मार दिया जाता है। कृपया ध्यान दें कि वास्तव में, फली पूर्ण होने की प्रक्रिया कुछ अधिक जटिल है।

मैं उपरोक्त अनुक्रम और उसके समय पर कैसे आया? ऐसा करने के लिए, हमने निम्नलिखित परिनियोजन का उपयोग किया, विशेष रूप से घटनाओं के क्रम को ट्रैक करने के लिए बनाया (यह अपने आप में बहुत उपयोगी नहीं है):

 kind: Deployment apiVersion: apps/v1beta1 metadata: name: loap spec: replicas: 1 template: metadata: labels: app: loap spec: initContainers: - name: init image: busybox command: ['sh', '-c', 'echo $(date +%s): INIT >> /loap/timing'] volumeMounts: - mountPath: /loap name: timing containers: - name: main image: busybox command: ['sh', '-c', 'echo $(date +%s): START >> /loap/timing; sleep 10; echo $(date +%s): END >> /loap/timing;'] volumeMounts: - mountPath: /loap name: timing livenessProbe: exec: command: ['sh', '-c', 'echo $(date +%s): LIVENESS >> /loap/timing'] readinessProbe: exec: command: ['sh', '-c', 'echo $(date +%s): READINESS >> /loap/timing'] lifecycle: postStart: exec: command: ['sh', '-c', 'echo $(date +%s): POST-START >> /loap/timing'] preStop: exec: command: ['sh', '-c', 'echo $(date +%s): PRE-HOOK >> /loap/timing'] volumes: - name: timing hostPath: path: /tmp/loap

ध्यान दें कि जब मुख्य कंटेनर काम कर रहा था, तब फली को जबरदस्ती बंद करने के लिए, मैंने निम्न कमांड चलाई:

 $ kubectl scale deployment loap --replicas=0

हमने कार्रवाई में घटनाओं के एक विशिष्ट अनुक्रम को देखा और अब आगे बढ़ने के लिए तैयार हैं - चूल्हा जीवन चक्र प्रबंधन के क्षेत्र में प्रथाओं के लिए। वे इस प्रकार हैं:

सामान्य ऑपरेशन के लिए चूल्हा तैयार करने के लिए इनिट कंटेनर का उपयोग करें। उदाहरण के लिए, बाहरी डेटा प्राप्त करने के लिए, डेटाबेस में टेबल बनाएं, या उस सेवा की उपलब्धता की प्रतीक्षा करें जिस पर यह निर्भर करता है। यदि आवश्यक हो, तो आप कई init कंटेनर बना सकते हैं, और उन सभी को नियमित रूप से कंटेनर लॉन्च करने से पहले सफलतापूर्वक पूरा करना होगा।
हमेशा livenessProbe और readinessProbe जोड़ें। पहले क्यूबलेट के ओम का उपयोग यह समझने के लिए किया जाता है कि कंटेनर को फिर से कब और कब चालू करना है, और यह तय करने के लिए कि क्या रोलिंग अद्यतन सफल था, तैनाती का ओम। दूसरे का उपयोग उप द्वारा यातायात की दिशा तय करने के लिए सेवा द्वारा किया जाता है। यदि इन नमूनों को परिभाषित नहीं किया जाता है, तो दोनों मान लेते हैं कि वे सफलतापूर्वक पूरा हो गए हैं। यह दो परिणामों की ओर जाता है: ए) पुनरारंभ नीति लागू नहीं की जा सकती है, बी) चूल्हा में कंटेनरों को तुरंत उस सेवा से ट्रैफ़िक प्राप्त होता है जो वे सामना कर रहे हैं, और भले ही वे अभी भी स्टार्टअप प्रक्रिया में व्यस्त हों।
कंटेनर को ठीक से शुरू करने और इसे पूरी तरह से नष्ट करने के लिए हुक का उपयोग करें। उदाहरण के लिए, यह एक एप्लिकेशन के कामकाज के मामले में उपयोगी है, जिसका स्रोत कोड आपके पास एक्सेस नहीं है या संशोधित नहीं कर सकता है, लेकिन जिसे पूरा करने के लिए कुछ आरंभीकरण या तैयारी की आवश्यकता होती है - उदाहरण के लिए, डेटाबेस कनेक्शन क्लियर करना। ध्यान दें कि सेवा का उपयोग करते समय , एपीआई सर्वर, समापन बिंदु नियंत्रक और क्यूब-प्रॉक्सी को बंद करने में कुछ समय लग सकता है (उदाहरण के लिए, iptables से संबंधित प्रविष्टियों को हटाने)। इसलिए, आपके कार्य को समाप्त करने से आवेदन अनुरोध प्रभावित हो सकते हैं। अक्सर, इस समस्या को हल करने के लिए, नींद कॉल के साथ एक साधारण हुक पर्याप्त है।
डिबगिंग की जरूरतों के लिए और सामान्य रूप से यह समझने के लिए कि यह क्यों काम करना बंद कर देता है, एप्लिकेशन /dev/termination-log को लिख सकता है, और आप kubectl describe pod … का उपयोग करके संदेश देख सकते हैं kubectl describe pod … इन डिफ़ॉल्ट सेटिंग्स को terminationMessagePath माध्यम से बदल दिया जाता terminationMessagePath और / या उप विनिर्देश में terminationMessagePolicy का उपयोग terminationMessagePolicy है। अधिक विवरण के लिए एपीआई संदर्भ देखें।

यह प्रकाशन इनिशियलाइज़र्स पर चर्चा नहीं करता है (उनके बारे में कुछ विवरण इस सामग्री के अंत में मिल सकते हैं - लगभग। अनुवाद। ) । यह कुबेरनेट्स 1.7 में पेश की गई एक पूरी तरह से नई अवधारणा है। शुरुआती लोग क्यूबलेट संदर्भ में होने के बजाय नियंत्रण विमान (एपीआई सर्वर) के अंदर काम करते हैं, और उदाहरण के लिए, साइडकार कंटेनरों या सुरक्षा नीतियों को लागू करने के लिए चूल्हा को समृद्ध करने के लिए इस्तेमाल किया जा सकता है। इसके अलावा, पॉडप्रेसेट्स पर विचार नहीं किया गया था, जो कि भविष्य में शुरुआती लोगों की अधिक लचीली अवधारणा द्वारा प्रतिस्थापित किया जा सकता है।

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

"कुबेरनेट्स में क्या होता है जब कुबेटेल रन शुरू होता है?": भाग 1 और भाग 2 ;
" कुबेरनेट्स अनुसूचक वास्तव में कैसे काम करता है?" ";
" कुबेरनेट्स पर नेटवर्किंग के लिए इलस्ट्रेटेड गाइड ";
" छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (वीडियो रिपोर्ट, जिसमें कुबेरनेट्स के तकनीकी उपकरण का परिचय शामिल है);
" कुबेरनेट्स के साथ खेलें - के 8 के साथ व्यावहारिक परिचित के लिए एक सेवा ";
" एक सस्ती सेवा के रूप में कुबेरनेट्स के साथ बुनियादी ढांचा ।"

कुबेरनेट्स: एक चूल्हा का जीवन

अनुवादक से पी.एस.

More articles: