कुबेरनेट्स में एक एप्लिकेशन विकसित करने के लिए आवश्यकताएँ

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

यह व्याख्यान "का हिस्सा हैकुबेरनेट्स पर स्लम नाइट स्कूल" आप इवनिंग स्कूल के खुले सैद्धांतिक व्याख्यान देख सकते हैं यूट्यूब पर, एक प्लेलिस्ट में समूहीकृत. उन लोगों के लिए जो वीडियो के बजाय टेक्स्ट पसंद करते हैं, हमने यह लेख तैयार किया है।

मेरा नाम पावेल सेलिवानोव है, वर्तमान में मैं Mail.ru क्लाउड सॉल्यूशंस में अग्रणी DevOps इंजीनियर हूं, हम क्लाउड बनाते हैं, हम प्रबंधन कुबेरनेट्स आदि बनाते हैं। मेरे कार्यों में अब विकास में सहायता करना, इन क्लाउड्स को लॉन्च करना, हमारे द्वारा लिखे गए एप्लिकेशन को लॉन्च करना और हमारे उपयोगकर्ताओं के लिए हमारे द्वारा प्रदान किए जाने वाले टूल को सीधे विकसित करना शामिल है।

मैं DevOps कर रहा हूं, मुझे लगता है कि पिछले, शायद, तीन साल से। लेकिन, सिद्धांत रूप में, मैं लगभग पाँच वर्षों से वही कर रहा हूँ जो DevOps करता है। इससे पहले, मैं अधिकतर प्रशासनिक कार्यों में लगा रहता था। मैंने बहुत समय पहले कुबेरनेट्स के साथ काम करना शुरू कर दिया था - शायद मुझे इसके साथ काम करना शुरू किए हुए लगभग चार साल बीत चुके हैं।

सामान्य तौर पर, मैंने तब शुरुआत की जब कुबेरनेट्स संस्करण 1.3 था, शायद, और शायद 1.2 - जब यह अभी भी अपनी प्रारंभिक अवस्था में था। अब यह अपनी प्रारंभिक अवस्था में नहीं है - और यह स्पष्ट है कि बाजार में ऐसे इंजीनियरों की भारी मांग है जो कुबेरनेट्स करने में सक्षम होना चाहेंगे। और कंपनियों में ऐसे लोगों की डिमांड बहुत ज्यादा होती है. इसलिए, वास्तव में, यह व्याख्यान सामने आया।

मैं जो बात करूंगा उसकी योजना के अनुसार बोलें तो वह इस तरह दिखती है, कोष्ठक में लिखा है (TL;DR) - ''बहुत लंबा;'' मत पढ़ो"। आज की मेरी प्रस्तुति में अंतहीन सूचियाँ शामिल होंगी।

वास्तव में, जब ऐसी प्रस्तुतियाँ बनाई जाती हैं तो मैं स्वयं उन्हें पसंद नहीं करता हूँ, लेकिन यह एक ऐसा विषय है कि जब मैं इस प्रस्तुति को तैयार कर रहा था, तो मुझे वास्तव में यह समझ में नहीं आया कि इस जानकारी को अलग तरीके से कैसे व्यवस्थित किया जाए।

क्योंकि, कुल मिलाकर, यह जानकारी "ctrl+c, ctrl+v" है, अन्य बातों के अलावा, DevOps अनुभाग में हमारे विकी से, जहां हमने डेवलपर्स के लिए लिखित आवश्यकताएं लिखी हैं: "दोस्तों, ताकि हम आपका एप्लिकेशन लॉन्च कर सकें कुबेरनेट्स, यह इस तरह होना चाहिए।"

इसीलिए प्रस्तुतिकरण इतनी बड़ी सूची बन गया। क्षमा मांगना। मैं जितना संभव हो उतना बताने की कोशिश करूंगा ताकि यदि संभव हो तो यह उबाऊ न हो।

अब हम क्या देखने जा रहे हैं:

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

लॉग

मेरा सुझाव है कि लॉग्स से शुरुआत करें - जहां इन लॉग्स को कुबेरनेट्स में डालने की आवश्यकता है। अब आपने कुबेरनेट्स में एक एप्लिकेशन लॉन्च किया है। क्लासिक्स के अनुसार, पहले के एप्लिकेशन हमेशा फ़ाइल में कहीं न कहीं लॉग लिखते थे। खराब एप्लिकेशन ने एप्लिकेशन लॉन्च करने वाले डेवलपर की होम डायरेक्टरी में एक फ़ाइल में लॉग लिखे। अच्छे एप्लिकेशन ने किसी फ़ाइल में कहीं न कहीं लॉग लिखे /var/log.

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

जब हम कुबेरनेट्स की दुनिया में जाते हैं और वहां वही चीज़ चलाते हैं, तो पहली चीज़ जिस पर आप ध्यान दे सकते हैं वह यह तथ्य है कि लोग, जैसे उन्होंने फ़ाइल में लॉग लिखे थे, उन्हें लिखना जारी रखते हैं।

यह पता चला है कि अगर हम कुबेरनेट्स के बारे में बात करते हैं, तो डॉकटर कंटेनर से कहीं लॉग लिखने का सही स्थान बस उन्हें एप्लिकेशन से तथाकथित स्टडआउट/स्टडरर, यानी ऑपरेटिंग सिस्टम के मानक आउटपुट स्ट्रीम में लिखना है। मानक त्रुटि आउटपुट। सैद्धांतिक रूप से डॉकर और विशेष रूप से कुबेरनेटिस में लॉग डालने का यह सबसे सही, सरल और सबसे तार्किक तरीका है। क्योंकि यदि आपका एप्लिकेशन Stdout/Stderr पर लॉग लिखता है, तो यह डॉकर और Kubernetes ऐड-ऑन पर निर्भर है कि वह इन लॉग के साथ क्या करना है। डॉकर डिफ़ॉल्ट रूप से JSON प्रारूप में अपनी विशेष फ़ाइलें बनाएगा।

यहां सवाल उठता है कि आप इन लॉग्स के साथ आगे क्या करेंगे? सबसे आसान तरीका स्पष्ट है, हमारे पास करने की क्षमता है kubectl logs और इन "पॉड्स" के इन लॉग को देखें। लेकिन, शायद, यह बहुत अच्छा विकल्प नहीं है - लॉग के साथ कुछ और करने की ज़रूरत है।

अभी के लिए, आइए एक ही समय में बात करें, क्योंकि हमने लॉग के विषय पर बात की है, लॉग जैसी चीज़ के बारे में। यानी यह सीधे तौर पर कुबेरनेट्स पर लागू नहीं होता है, लेकिन जब हम यह सोचना शुरू करते हैं कि लॉग के साथ क्या करना है, तो इस बारे में भी सोचना अच्छा होगा।

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

सबसे महत्वपूर्ण विचार, मैं इसे फिर से दोहराना चाहता हूं, वह यह है कि डॉकर के अंदर, विशेष रूप से कुबेरनेट्स के अंदर, अपने लॉग को एक फ़ाइल में संग्रहीत करना एक बहुत बुरा विचार है।

क्योंकि सबसे पहले, फ़ाइल में कंटेनर के अंदर लॉग प्राप्त करना मुश्किल है। आपको पहले कंटेनर में जाना होगा, वहां निष्पादन करना होगा और फिर लॉग को देखना होगा। अगला बिंदु यह है कि यदि आपके पास किसी फ़ाइल में लॉग हैं, तो कंटेनरों में आमतौर पर न्यूनतम वातावरण होता है और ऐसी कोई उपयोगिता नहीं होती है जो आमतौर पर लॉग के साथ सामान्य काम के लिए आवश्यक होती है। उन्हें दफनाएं, उन्हें देखें, उन्हें टेक्स्ट एडिटर में खोलें। अगला क्षण तब होता है जब हमारे पास एक कंटेनर के अंदर एक फ़ाइल में लॉग होते हैं, यदि यह कंटेनर हटा दिया जाता है, तो आप समझते हैं, लॉग इसके साथ ही मर जाएंगे। तदनुसार, कंटेनर के किसी भी पुनरारंभ का मतलब है कि कोई और लॉग नहीं हैं। फिर, बुरा विकल्प.

और अंतिम बिंदु यह है कि कंटेनरों के अंदर आमतौर पर आपका एप्लिकेशन होता है और बस इतना ही - यह आमतौर पर चलने वाली एकमात्र प्रक्रिया है। ऐसी किसी भी प्रक्रिया के बारे में कोई चर्चा नहीं है जो आपके लॉग के साथ फ़ाइलों को घुमाएगी। जैसे ही लॉग किसी फ़ाइल में लिखे जाने लगते हैं, इसका मतलब है कि, क्षमा करें, हम उत्पादन सर्वर खोना शुरू कर देंगे। क्योंकि, सबसे पहले, उन्हें ढूंढना मुश्किल है, कोई भी उन्हें ट्रैक नहीं करता है, साथ ही कोई भी उन्हें नियंत्रित नहीं करता है - तदनुसार, फ़ाइल अंतहीन रूप से बढ़ती है जब तक कि सर्वर पर जगह बस खत्म नहीं हो जाती। इसलिए, मैं फिर से कहता हूं कि डॉकर में, विशेष रूप से कुबेरनेट्स में, किसी फ़ाइल में लॉग इन करना एक बुरा विचार है।

अगला बिंदु, यहां मैं इस बारे में फिर से बात करना चाहता हूं - चूंकि हम लॉग के विषय पर बात कर रहे हैं, इसलिए इस बारे में बात करना अच्छा होगा कि लॉग कैसे दिखने चाहिए ताकि उनके साथ काम करना सुविधाजनक हो। जैसा कि मैंने कहा, विषय सीधे तौर पर कुबेरनेट्स से संबंधित नहीं है, लेकिन यह DevOps के विषय से बहुत अच्छी तरह से संबंधित है। इन दो अलग-अलग विभागों - देव और ऑप्स के बीच विकास संस्कृति और मित्रता के विषय पर, ताकि हर कोई सहज हो।

इसका मतलब यह है कि आदर्श रूप से, आज, लॉग JSON प्रारूप में लिखे जाने चाहिए। यदि आपके पास अपना स्वयं का कोई समझ से बाहर का एप्लिकेशन है, जो समझ से बाहर के प्रारूपों में लॉग लिखता है क्योंकि आप किसी प्रकार का प्रिंट या ऐसा कुछ डालते हैं, तो अब किसी प्रकार की रूपरेखा, किसी प्रकार के रैपर को गूगल करने का समय है जो आपको सामान्य लॉगिंग को लागू करने की अनुमति देता है; वहां JSON में लॉगिंग पैरामीटर सक्षम करें, क्योंकि JSON एक सरल प्रारूप है, इसे पार्स करना सरल है।

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

अंत में, मैं आग में घी डालना चाहता हूं कि, आदर्श रूप से, मल्टी-लाइन प्रारूप लॉग से बचा जाना चाहिए। यहाँ बात यह है, यदि आपने कभी लॉग कलेक्टरों के साथ काम किया है, तो सबसे अधिक संभावना है कि आपने देखा है कि वे आपसे क्या वादा करते हैं, कि वे मल्टी-लाइन लॉग के साथ काम कर सकते हैं, जानते हैं कि उन्हें कैसे एकत्र करना है, इत्यादि। वास्तव में, मेरी राय में, आज कोई भी संग्राहक सामान्य रूप से, पूरी तरह से और त्रुटियों के बिना मल्टी-लाइन लॉग एकत्र नहीं कर सकता है। मानवीय तरीके से, ताकि यह सुविधाजनक और त्रुटि रहित हो।

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

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

विन्यास

आगे हम कुबेरनेट्स में कॉन्फ़िगरेशन के बारे में बात करते हैं: इसके साथ क्या करना है और कुबेरनेट्स के अंदर अनुप्रयोगों को कैसे कॉन्फ़िगर किया जाना चाहिए। सामान्य तौर पर, मैं आमतौर पर कहता हूं कि डॉकर कंटेनरों के बारे में नहीं है। हर कोई जानता है कि डॉकर कंटेनरों के बारे में है, यहां तक ​​कि वे भी जिन्होंने डॉकर के साथ ज्यादा काम नहीं किया है। मैं दोहराता हूं, डॉकर कंटेनरों के बारे में नहीं है।

मेरी राय में, डॉकर मानकों के बारे में है। और व्यावहारिक रूप से हर चीज़ के लिए मानक हैं: आपके एप्लिकेशन के निर्माण के लिए मानक, आपके एप्लिकेशन को इंस्टॉल करने के लिए मानक।

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

ENV वेरिएबल का उपयोग करके सब कुछ कॉन्फ़िगर किया जा सकता है। जब हम कुबेरनेट्स के बारे में बात करते हैं, तो परिनियोजन के ठीक अंदर ENV चर घोषित करने का एक शानदार तरीका है। तदनुसार, यदि हम गुप्त डेटा के बारे में बात कर रहे हैं, तो हम तुरंत ENV चर (डेटाबेस के पासवर्ड, आदि) से गुप्त डेटा को एक गुप्त में धकेल सकते हैं, एक गुप्त क्लस्टर बना सकते हैं और परिनियोजन में ENV विवरण में इंगित कर सकते हैं कि हम सीधे घोषित नहीं कर रहे हैं इस वेरिएबल का मान, और इस डेटाबेस पासवर्ड वेरिएबल का मान गुप्त रूप से पढ़ा जाएगा। यह मानक कुबेरनेट्स व्यवहार है। और यह आपके एप्लिकेशन को कॉन्फ़िगर करने का सबसे आदर्श विकल्प है। बस कोड स्तर पर, यह फिर से डेवलपर्स पर लागू होता है। यदि आप DevOps हैं, तो आप पूछ सकते हैं: "दोस्तों, कृपया अपने एप्लिकेशन को पर्यावरण चर पढ़ना सिखाएं। और हम सब खुश रहेंगे।”

यदि कंपनी में हर कोई समान नामित पर्यावरण चर पढ़ता है, तो यह बहुत अच्छा है। ताकि ऐसा न हो कि कुछ पोस्टग्रेज डेटाबेस का इंतजार कर रहे हैं, दूसरे डेटाबेस नाम का इंतजार कर रहे हैं, दूसरे किसी और चीज का इंतजार कर रहे हैं, दूसरे किसी तरह के डीबीएन का इंतजार कर रहे हैं, ताकि, तदनुसार, एकरूपता हो।

समस्या तब आती है जब आपके पास इतने सारे पर्यावरण चर होते हैं कि आप बस परिनियोजन खोलते हैं - और पर्यावरण चर की पाँच सौ पंक्तियाँ होती हैं। इस मामले में, आपने पर्यावरण चर को आसानी से पार कर लिया है - और अब आपको खुद को यातना देने की आवश्यकता नहीं है। इस मामले में, कॉन्फ़िगरेशन का उपयोग शुरू करना उचित होगा। यानी, अपने एप्लिकेशन को कॉन्फ़िगरेशन का उपयोग करने के लिए प्रशिक्षित करें।

एकमात्र सवाल यह है कि कॉन्फ़िगरेशन वह नहीं है जो आप सोचते हैं। कॉन्फिग.पीआई ऐसा कॉन्फिगरेशन नहीं है जो उपयोग में सुविधाजनक हो। या आपके स्वयं के प्रारूप में कुछ कॉन्फ़िगरेशन, वैकल्पिक रूप से उपहार में दिया गया - यह भी वह कॉन्फ़िगरेशन नहीं है जिसका मेरा मतलब है।

मैं जिस बारे में बात कर रहा हूं वह स्वीकार्य प्रारूपों में कॉन्फ़िगरेशन है, यानी अब तक का सबसे लोकप्रिय मानक .yaml मानक है। यह स्पष्ट है कि इसे कैसे पढ़ा जाए, यह मानव पठनीय है, एप्लिकेशन से यह स्पष्ट है कि इसे कैसे पढ़ा जाए।

तदनुसार, YAML के अलावा, आप, उदाहरण के लिए, JSON का भी उपयोग कर सकते हैं, वहां से एप्लिकेशन कॉन्फ़िगरेशन को पढ़ने के मामले में पार्सिंग YAML जितनी ही सुविधाजनक है। लोगों के लिए इसे पढ़ना काफ़ी असुविधाजनक है। आप इस प्रारूप को आज़मा सकते हैं, ला इनी। मानवीय दृष्टिकोण से, इसे पढ़ना काफी सुविधाजनक है, लेकिन इसे स्वचालित रूप से संसाधित करना असुविधाजनक हो सकता है, इस अर्थ में कि यदि आप कभी भी अपनी स्वयं की कॉन्फ़िगरेशन उत्पन्न करना चाहते हैं, तो आईएनआई प्रारूप उत्पन्न करने के लिए पहले से ही असुविधाजनक हो सकता है।

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

यदि आपके पास एक कॉन्फिगमैप है, तो आप अपने एप्लिकेशन को बहुत अच्छी तरह से सिखा सकते हैं, उदाहरण के लिए, उस फ़ाइल में परिवर्तनों को स्वचालित रूप से ट्रैक करना जहां कॉन्फिगमैप माउंट किया गया है, और कॉन्फिगरेशन बदलने पर अपने एप्लिकेशन को स्वचालित रूप से पुनः लोड करना भी सिखा सकते हैं। यह आम तौर पर एक आदर्श विकल्प होगा.

फिर, मैंने पहले ही इस बारे में बात की है - गुप्त जानकारी कॉन्फिगमैप में नहीं है, गुप्त जानकारी वेरिएबल्स में नहीं है, गुप्त जानकारी रहस्यों में नहीं है। वहां से इस गुप्त जानकारी को कूटनीति से जोड़ दें. आमतौर पर हम Kubernetes ऑब्जेक्ट, परिनियोजन, कॉन्फ़िगरेशनमैप्स, सेवाओं के सभी विवरण git में संग्रहीत करते हैं। तदनुसार, डेटाबेस में पासवर्ड को git में डालना, भले ही वह आपका git हो, जो आपके पास कंपनी में आंतरिक रूप से है, एक बुरा विचार है। क्योंकि, कम से कम, git सब कुछ याद रखता है और वहां से पासवर्ड हटाना इतना आसान नहीं है।

स्वास्थ्य जांच

अगला बिंदु यह है जिसे स्वास्थ्य जांच कहा जाता है। सामान्य तौर पर, स्वास्थ्य जांच का मतलब केवल यह जांचना है कि आपका एप्लिकेशन काम कर रहा है। साथ ही, हम अक्सर कुछ वेब अनुप्रयोगों के बारे में बात कर रहे हैं, जिसके अनुसार, स्वास्थ्य जांच के दृष्टिकोण से (यहां और आगे अनुवाद न करना बेहतर है) यह कुछ विशेष यूआरएल होगा, जिसे वे संसाधित करते हैं एक मानक, वे आमतौर पर ऐसा करते हैं /health.

इस URL तक पहुँचने पर, तदनुसार, हमारा एप्लिकेशन या तो कहता है "हाँ, ठीक है, मेरे साथ सब कुछ ठीक है, 200" या "नहीं, मेरे साथ सब कुछ ठीक नहीं है, कुछ 500।" तदनुसार, यदि हमारा एप्लिकेशन http नहीं है, वेब एप्लिकेशन नहीं है, अब हम किसी प्रकार के डेमॉन के बारे में बात कर रहे हैं, तो हम यह पता लगा सकते हैं कि स्वास्थ्य जांच कैसे करें। यानी यह जरूरी नहीं है, अगर एप्लीकेशन http नहीं है तो सब कुछ बिना स्वास्थ्य जांच के काम करता है और ऐसा किसी भी तरह से नहीं किया जा सकता है. आप समय-समय पर फ़ाइल में कुछ जानकारी अपडेट कर सकते हैं, आप अपने डेमॉन के लिए कुछ विशेष कमांड लेकर आ सकते हैं, जैसे, daemon status, जो कहेगा "हाँ, सब कुछ ठीक है, डेमॉन काम कर रहा है, यह जीवित है।"

यह किस लिए है? पहली और सबसे स्पष्ट बात शायद यह है कि स्वास्थ्य जांच की आवश्यकता क्यों है - यह समझने के लिए कि एप्लिकेशन काम कर रहा है। मेरा मतलब है, यह बिल्कुल बेवकूफी है, जब यह अभी चालू है, तो ऐसा लगता है कि यह काम कर रहा है, इसलिए आप निश्चिंत हो सकते हैं कि यह काम कर रहा है। और यह पता चला कि एप्लिकेशन चल रहा है, कंटेनर चल रहा है, इंस्टेंस काम कर रहा है, सब कुछ ठीक है - और फिर उपयोगकर्ताओं ने पहले ही तकनीकी सहायता से सभी फ़ोन नंबर काट दिए हैं और कहते हैं, "आप क्या हैं..., आप सो गया, कुछ भी काम नहीं कर रहा है।”

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

फिर से, स्वास्थ्य जांच की मदद से और इस तथ्य की मदद से कि हम यहां मुड़ रहे हैं, हम कुबेरनेट्स में समझ सकते हैं कि न केवल कंटेनर एप्लिकेशन में बढ़ गया है, बल्कि एप्लिकेशन स्वयं शुरू हो गया है, यह पहले से ही प्रतिक्रिया देता है स्वास्थ्य जांच, जिसका अर्थ है कि हम वहां ट्रैफ़िक भेज सकते हैं।

मैं अब जिस बारे में बात कर रहा हूं उसे कुबेरनेट्स के भीतर तत्परता/लाइवनेस परीक्षण कहा जाता है, तदनुसार, हमारे तत्परता परीक्षण संतुलन में एप्लिकेशन की उपलब्धता के लिए जिम्मेदार हैं। यानी, यदि एप्लिकेशन में तत्परता परीक्षण किए जाते हैं, तो सब कुछ ठीक है, क्लाइंट ट्रैफ़िक एप्लिकेशन पर जा रहा है। यदि तत्परता परीक्षण नहीं किए जाते हैं, तो एप्लिकेशन बस भाग नहीं लेता है, यह विशेष उदाहरण संतुलन में भाग नहीं लेता है, इसे संतुलन से हटा दिया जाता है, क्लाइंट ट्रैफ़िक प्रवाहित नहीं होता है। तदनुसार, कुबेरनेट्स के भीतर लाइवनेस परीक्षणों की आवश्यकता है ताकि यदि एप्लिकेशन अटक जाता है, तो इसे फिर से शुरू किया जा सके। यदि कुबेरनेट्स में घोषित एप्लिकेशन के लिए जीवंतता परीक्षण काम नहीं करता है, तो एप्लिकेशन को केवल संतुलन से नहीं हटाया जाता है, इसे पुनरारंभ किया जाता है।

और यहां एक महत्वपूर्ण बिंदु है जिसका मैं उल्लेख करना चाहूंगा: व्यावहारिक दृष्टिकोण से, तत्परता परीक्षण आमतौर पर अधिक बार उपयोग किया जाता है और जीवंतता परीक्षण की तुलना में इसकी अधिक आवश्यकता होती है। अर्थात्, बिना सोचे-समझे तत्परता और जीवंतता दोनों परीक्षणों की घोषणा करना, क्योंकि कुबेरनेट्स ऐसा कर सकता है, और आइए वह सब कुछ उपयोग करें जो वह कर सकता है, यह बहुत अच्छा विचार नहीं है। मैं समझाऊंगा क्यों. क्योंकि परीक्षण में बिंदु संख्या दो यह है कि आपके स्वास्थ्य जांच में अंतर्निहित सेवा की जांच करना एक अच्छा विचार होगा। इसका मतलब यह है कि यदि आपके पास एक वेब एप्लिकेशन है जो कुछ जानकारी देता है, जो बदले में, स्वाभाविक रूप से, कहीं से लेनी होगी। उदाहरण के लिए, किसी डेटाबेस में। खैर, यह इस REST API में आने वाली जानकारी को उसी डेटाबेस में सहेजता है। फिर, तदनुसार, यदि आपका हेल्थचेक संपर्क किए गए स्लैशहेल्थ की तरह ही प्रतिक्रिया करता है, तो एप्लिकेशन कहता है "200, ठीक है, सब कुछ ठीक है," और साथ ही आपके एप्लिकेशन का डेटाबेस अप्राप्य है, और हेल्थचेक एप्लिकेशन कहता है "200, ठीक है, सब कुछ ठीक है" - यह एक खराब स्वास्थ्य जांच है। इसे इस तरह से काम नहीं करना चाहिए.

यानी आपका आवेदन, जब उसके पास कोई अनुरोध आता है /health, यह सिर्फ "200, ठीक" का जवाब नहीं देता है, यह पहले जाता है, उदाहरण के लिए, डेटाबेस पर, उससे जुड़ने की कोशिश करता है, वहां कुछ बहुत ही बुनियादी काम करता है, जैसे एक का चयन करें, बस यह जांचता है कि इसमें कोई कनेक्शन है या नहीं डेटाबेस और आप डेटाबेस से क्वेरी कर सकते हैं। यदि यह सब सफल रहा, तो उत्तर है "200, ठीक है।" यदि यह सफल नहीं होता है, तो यह कहता है कि कोई त्रुटि है, डेटाबेस अनुपलब्ध है।

इसलिए, इस संबंध में, मैं फिर से तत्परता/जीवितता परीक्षणों पर लौटता हूं - आपको तत्परता परीक्षण की सबसे अधिक आवश्यकता क्यों है, लेकिन जीवंतता परीक्षण प्रश्न में है। क्योंकि यदि आप स्वास्थ्य जांच का बिल्कुल वैसा ही वर्णन करते हैं जैसा मैंने अभी कहा, तो यह पता चलेगा कि यह उदाहरण भाग में उपलब्ध नहीं हैв или со всех instanceउदाहरण के लिए, किसी डेटाबेस में। जब आपने तत्परता परीक्षण की घोषणा की, तो हमारी स्वास्थ्य जांच विफल होने लगी, और तदनुसार सभी एप्लिकेशन जिनसे डेटाबेस तक पहुंच नहीं है, वे बस संतुलन से बंद हो गए और वास्तव में उपेक्षित स्थिति में "लटका" गए और अपने डेटाबेस के लिए प्रतीक्षा की काम।

यदि हमने जीवंतता परीक्षण की घोषणा की है, तो कल्पना कीजिए, हमारा डेटाबेस टूट गया है, और आपके कुबेरनेट्स में जीवंतता परीक्षण विफल होने के कारण आधी चीजें पुनः आरंभ होने लगती हैं। इसका मतलब है कि आपको पुनः आरंभ करने की आवश्यकता है। यह बिल्कुल वैसा नहीं है जैसा आप चाहते हैं, मुझे अभ्यास में व्यक्तिगत अनुभव भी है। हमारे पास एक चैट एप्लिकेशन था जो जेएस में लिखा गया था और मोंगो डेटाबेस में फीड किया गया था। और समस्या यह थी कि कुबेरनेट्स के साथ मेरे काम की शुरुआत में, हमने इस सिद्धांत पर परीक्षणों की तत्परता, जीवंतता का वर्णन किया था कि कुबेरनेट्स यह कर सकता है, इसलिए हम इसका उपयोग करेंगे। तदनुसार, कुछ बिंदु पर मोंगो थोड़ा "सुस्त" हो गया और नमूना विफल होने लगा। तदनुसार, वर्षा परीक्षण के अनुसार, फलियाँ "मरने" लगीं।

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

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

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

क्योंकि जीवंतता की परीक्षा, मोटे तौर पर, तब होती है जब हम "अटक" जाते हैं। एक अंतहीन लूप शुरू हो गया है या कुछ और - और कोई और अनुरोध संसाधित नहीं किया गया है। इसलिए, उन्हें अलग करना और उनमें अलग-अलग तर्क लागू करना भी समझ में आता है।

जब आपका परीक्षण होता है, जब आप स्वास्थ्य जांच करते हैं तो आपको क्या उत्तर देने की आवश्यकता होती है, इसके संबंध में। यह वास्तव में एक दर्द है. जो लोग इससे परिचित हैं वे शायद हँसेंगे - लेकिन गंभीरता से, मैंने अपने जीवन में ऐसी सेवाएँ देखी हैं जो 200% मामलों में "XNUMX" उत्तर देती हैं। यानी सफल कौन है. लेकिन साथ ही प्रतिक्रिया के मुख्य भाग में वे "ऐसी और ऐसी त्रुटि" लिखते हैं।

यानी रिस्पॉन्स स्टेटस आपके पास आता है- सब कुछ सफल है. लेकिन साथ ही, आपको मुख्य भाग को पार्स करना होगा, क्योंकि शरीर कहता है "क्षमा करें, अनुरोध एक त्रुटि के साथ समाप्त हुआ" और यह सिर्फ वास्तविकता है। मैंने इसे वास्तविक जीवन में देखा।

और इसलिए कि कुछ लोगों को यह हास्यास्पद न लगे, और दूसरों को यह बहुत कष्टदायक लगे, फिर भी एक सरल नियम का पालन करना उचित है। स्वास्थ्य जांच में, और सैद्धांतिक रूप से वेब अनुप्रयोगों के साथ काम करते समय।

यदि सब कुछ ठीक रहा, तो दो सौवें उत्तर के साथ उत्तर दें। सिद्धांत रूप में, कोई भी दो-सौवां उत्तर आपके अनुरूप होगा। यदि आप बहुत अच्छी तरह से रैग्सी पढ़ते हैं और जानते हैं कि कुछ प्रतिक्रिया स्थितियाँ दूसरों से भिन्न हैं, तो उचित उत्तर दें: 204, 5, 10, 15, जो भी हो। यदि यह बहुत अच्छा नहीं है, तो बस "दो शून्य शून्य।" यदि सब कुछ खराब हो जाता है और स्वास्थ्य जांच पर कोई प्रतिक्रिया नहीं मिलती है, तो कोई पांच सौवां भाग देकर उत्तर दें। फिर, यदि आप समझते हैं कि कैसे प्रतिक्रिया देनी है, तो विभिन्न प्रतिक्रिया स्थितियाँ एक-दूसरे से कैसे भिन्न होती हैं। यदि आप नहीं समझते हैं, तो कुछ गलत होने पर स्वास्थ्य जांच का जवाब देने के लिए 502 आपके पास विकल्प है।

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

इसलिए, मैं इसे फिर से दोहराना चाहता हूं कि आपको अंतर्निहित सेवाओं की जांच करने की आवश्यकता है, जिनके बिना सौ प्रतिशत मामलों में आपका एप्लिकेशन अपना काम नहीं कर सकता है। यानी, यह तर्कसंगत है कि यदि आपके पास एक REST API है जिसके माध्यम से उपयोगकर्ता डेटाबेस में सहेजता है या डेटाबेस से पुनर्प्राप्त करता है, तो डेटाबेस की अनुपस्थिति में, आप अपने उपयोगकर्ताओं के साथ काम करने की गारंटी नहीं दे सकते।

लेकिन यदि आपके उपयोगकर्ता, जब आप उन्हें डेटाबेस से बाहर निकालते हैं, तो किसी अन्य बैकएंड से कुछ अन्य मेटाडेटा के साथ अतिरिक्त रूप से समृद्ध होते हैं, जिसे आप फ्रंटएंड पर प्रतिक्रिया भेजने से पहले दर्ज करते हैं - और यह बैकएंड उपलब्ध नहीं है, इसका मतलब है कि आप अपना देते हैं मेटाडेटा के किसी भी भाग के बिना उत्तर दें।

इसके बाद, एप्लिकेशन लॉन्च करते समय हमारे सामने एक दर्दनाक समस्या भी आती है।

वास्तव में, यह केवल कुबेरनेट्स पर लागू नहीं होता है; यह सिर्फ इतना हुआ कि कुछ प्रकार के बड़े पैमाने पर विकास और विशेष रूप से DevOps की संस्कृति कुबेरनेट्स के समान ही फैलनी शुरू हुई। इसलिए, कुल मिलाकर, यह पता चलता है कि आपको कुबेरनेट्स के बिना अपने एप्लिकेशन को शालीनतापूर्वक बंद करने की आवश्यकता है। कुबेरनेट्स से पहले भी लोग ऐसा करते थे, लेकिन कुबेरनेट्स के आगमन के साथ, हमने इसके बारे में सामूहिक रूप से बात करना शुरू कर दिया।

ग्रेसफुल शटडाउन

सामान्य तौर पर, ग्रेसफुल शटडाउन क्या है और इसकी आवश्यकता क्यों है? यह तब होता है जब आपका एप्लिकेशन किसी कारण से क्रैश हो जाता है, आपको ऐसा करना होगा app stop - या उदाहरण के लिए, आपको ऑपरेटिंग सिस्टम से एक सिग्नल प्राप्त होता है, तो आपके एप्लिकेशन को इसे समझना होगा और इसके बारे में कुछ करना होगा। बेशक, सबसे खराब स्थिति तब होती है जब आपका एप्लिकेशन एक SIGTERM प्राप्त करता है और "SIGTERM, चलो रुकें, काम करें, कुछ न करें" जैसा होता है। यह एकदम ख़राब विकल्प है.

लगभग समान रूप से बुरा विकल्प तब होता है जब आपका एप्लिकेशन एक SIGTERM प्राप्त करता है और ऐसा होता है "उन्होंने कहा कि SIGTERM, इसका मतलब है कि हम समाप्त कर रहे हैं, मैंने नहीं देखा है, मुझे कोई उपयोगकर्ता अनुरोध नहीं पता है, मुझे नहीं पता कि किस प्रकार का जिन अनुरोधों पर मैं अभी काम कर रहा हूं, उन्होंने कहा कि SIGTERM, इसका मतलब है कि हम समाप्त कर रहे हैं " यह भी एक ख़राब विकल्प है.

कौन सा विकल्प अच्छा है? पहला बिंदु संचालन के पूरा होने को ध्यान में रखना है। आपके सर्वर के लिए एक अच्छा विकल्प यह है कि वह अभी भी इस बात को ध्यान में रखे कि यदि उसे SIGTERM प्राप्त होता है तो वह क्या करेगा।

SIGTERM एक सॉफ्ट शटडाउन है, इसे विशेष रूप से डिज़ाइन किया गया है, इसे कोड स्तर पर इंटरसेप्ट किया जा सकता है, इसे प्रोसेस किया जा सकता है, कहें कि अभी रुकें, पहले हमारे पास जो काम है उसे पूरा करेंगे, फिर हम बाहर निकलेंगे।

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

वहां हम विशेष रूप से कह सकते हैं कि एप्लिकेशन को SIGTERM भेजने के समय और जब हम समझते हैं कि एप्लिकेशन किसी चीज़ के लिए पागल हो गया है या "अटका हुआ" है और समाप्त नहीं होने वाला है - और हमें इसकी आवश्यकता है, के बीच हमें कितनी देर तक प्रतीक्षा करने की आवश्यकता है - और हमें इसकी आवश्यकता है इसे SIGKILL भेजो, यानी कड़ी मेहनत से इसका काम पूरा करो। अर्थात्, तदनुसार, हमारे पास किसी प्रकार का डेमॉन चल रहा है, यह संचालन को संसाधित करता है। हम समझते हैं कि औसतन हमारा ऑपरेशन, जिस पर डेमॉन काम करता है, एक समय में 30 सेकंड से अधिक नहीं चलता है। तदनुसार, जब SIGTERM आता है, तो हम समझते हैं कि हमारा डेमॉन, SIGTERM के अधिकतम 30 सेकंड बाद समाप्त हो सकता है। उदाहरण के लिए, हम इसे 45 सेकंड के लिए लिखते हैं और कहते हैं कि SIGTERM। उसके बाद हम 45 सेकंड इंतजार करते हैं। सैद्धान्तिक रूप से इतने समय में राक्षस को अपना कार्य पूरा कर स्वयं समाप्त हो जाना चाहिए था। लेकिन अगर अचानक यह नहीं हो सका, तो इसका मतलब है कि यह संभवतः अटक गया है - यह अब हमारे अनुरोधों को सामान्य रूप से संसाधित नहीं कर रहा है। और 45 सेकंड में आप वास्तव में सुरक्षित रूप से उसे मार गिरा सकते हैं।

और यहां, वास्तव में, 2 पहलुओं को भी ध्यान में रखा जा सकता है। सबसे पहले, यह समझें कि यदि आपको कोई अनुरोध प्राप्त हुआ, तो आपने किसी तरह उसके साथ काम करना शुरू कर दिया और उपयोगकर्ता को कोई प्रतिक्रिया नहीं दी, लेकिन उदाहरण के लिए, आपको SIGTERM प्राप्त हुआ। इसे परिष्कृत करना और उपयोगकर्ता को उत्तर देना समझ में आता है। इस संबंध में यह बिंदु नंबर एक है। यहां बिंदु संख्या दो यह है कि यदि आप अपना स्वयं का एप्लिकेशन लिखते हैं, तो आम तौर पर आर्किटेक्चर को इस तरह से बनाते हैं कि आपको अपने एप्लिकेशन के लिए अनुरोध प्राप्त होता है, फिर आप कुछ काम शुरू करते हैं, कहीं से फ़ाइलें डाउनलोड करना शुरू करते हैं, डेटाबेस डाउनलोड करना और भी बहुत कुछ। वह। सामान्य तौर पर, आपका उपयोगकर्ता, आपका अनुरोध आधे घंटे तक लटका रहता है और आपके उत्तर देने की प्रतीक्षा करता है - फिर, सबसे अधिक संभावना है, आपको आर्किटेक्चर पर काम करने की आवश्यकता है। यानी, सामान्य ज्ञान को भी ध्यान में रखें कि यदि आपके ऑपरेशन छोटे हैं, तो SIGTERM को अनदेखा करना और इसे संशोधित करना समझ में आता है। यदि आपका ऑपरेशन लंबा है, तो इस मामले में SIGTERM को अनदेखा करने का कोई मतलब नहीं है। ऐसे लंबे ऑपरेशन से बचने के लिए आर्किटेक्चर को फिर से डिज़ाइन करना समझ में आता है। ताकि उपयोगकर्ता बस इधर-उधर लटके न रहें और प्रतीक्षा न करें। मुझे नहीं पता, वहां किसी प्रकार का वेबसोकेट बनाएं, रिवर्स हुक बनाएं जो आपका सर्वर पहले ही क्लाइंट को भेज देगा, और कुछ भी, लेकिन उपयोगकर्ता को आधे घंटे तक रुकने के लिए मजबूर न करें और बस एक सत्र की प्रतीक्षा करें जब तक आप उसे उत्तर दो. क्योंकि यह अप्रत्याशित है कि यह कहां टूट सकता है।

जब आपका आवेदन समाप्त हो जाए, तो आपको कुछ उचित निकास कोड प्रदान करना चाहिए। अर्थात्, यदि आपके एप्लिकेशन को बंद करने, रोकने के लिए कहा गया था, और यह सामान्य रूप से स्वयं को रोकने में सक्षम था, तो आपको किसी प्रकार के निकास कोड 1,5,255 इत्यादि को वापस करने की आवश्यकता नहीं है। जो कुछ भी शून्य कोड नहीं है, कम से कम लिनक्स सिस्टम में, मुझे इस बात का यकीन है, उसे असफल माना जाता है। यानी यह माना जाएगा कि इस मामले में आपका आवेदन एक त्रुटि के साथ समाप्त हुआ। तदनुसार, सौहार्दपूर्ण तरीके से, यदि आपका आवेदन बिना किसी त्रुटि के पूरा हो जाता है, तो आप आउटपुट पर 0 कहते हैं। यदि आपका एप्लिकेशन किसी कारण से विफल हो जाता है, तो आप आउटपुट में नॉन-0 कहते हैं। और आप इस जानकारी के साथ काम कर सकते हैं.

और आखिरी विकल्प. यह बुरा है जब आपका उपयोगकर्ता एक अनुरोध भेजता है और इसे संसाधित करते समय आधे घंटे तक लटका रहता है। लेकिन सामान्य तौर पर, मैं यह भी कहना चाहूंगा कि ग्राहक की ओर से आम तौर पर इसके लायक क्या है। इससे कोई फर्क नहीं पड़ता कि आपके पास मोबाइल एप्लिकेशन, फ्रंट-एंड आदि है। यह ध्यान रखना आवश्यक है कि सामान्यतः उपयोगकर्ता का सत्र समाप्त किया जा सकता है, कुछ भी हो सकता है। उदाहरण के लिए, एक अनुरोध भेजा जा सकता है, जो संसाधित नहीं हुआ और कोई प्रतिक्रिया नहीं मिली। आपका फ्रंटएंड या आपका मोबाइल एप्लिकेशन - सामान्य तौर पर कोई भी फ्रंटएंड, इसे इस तरह से कहें - इसे ध्यान में रखना चाहिए। यदि आप वेबसॉकेट के साथ काम करते हैं, तो यह आम तौर पर मेरे लिए अब तक का सबसे बुरा दर्द है।

जब कुछ नियमित चैट के डेवलपर्स को यह नहीं पता होता है, तो पता चलता है कि वेबसोकेट टूट सकता है। उनके लिए, जब प्रॉक्सी पर कुछ होता है, तो हम बस कॉन्फ़िगरेशन बदलते हैं, और यह पुनः लोड होता है। स्वाभाविक रूप से, इस मामले में सभी दीर्घकालिक सत्र विफल हो जाते हैं। डेवलपर्स हमारे पास दौड़ते हुए आते हैं और कहते हैं: "दोस्तों, आप क्या कर रहे हैं, हमारे सभी ग्राहकों के लिए चैट टूट गई है!" हम उनसे कहते हैं: “आप क्या कर रहे हैं? क्या आपके ग्राहक पुनः कनेक्ट नहीं हो पा रहे हैं? वे कहते हैं: "नहीं, हमें चाहिए कि सत्र फटे नहीं।" संक्षेप में, यह वास्तव में बकवास है। ग्राहक पक्ष को ध्यान में रखना होगा. विशेष रूप से, जैसा कि मैं कहता हूं, वेबसोकेट जैसे लंबे समय तक चलने वाले सत्रों के साथ, यह टूट सकता है और, उपयोगकर्ता द्वारा ध्यान दिए बिना, आपको ऐसे सत्रों को फिर से स्थापित करने में सक्षम होने की आवश्यकता है। और फिर सब कुछ उत्तम है.

Ресурсы

दरअसल, यहां मैं आपको बस एक सीधी कहानी बताऊंगा। फिर असल जिंदगी से. संसाधनों के बारे में मैंने अब तक सबसे ख़राब बात सुनी है।

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

आखिर संसाधनों की आवश्यकता क्यों है? कुबेरनेट्स में 2 प्रकार के संसाधन हैं। कुछ को अनुरोध कहा जाता है, अन्य को सीमा कहा जाता है। संसाधनों से हम समझेंगे कि मूल रूप से हमेशा दो ही बुनियादी प्रतिबंध होते हैं। यानी, कुबेरनेट्स में चलने वाले कंटेनर के लिए सीपीयू समय सीमा और रैम सीमा।

एक सीमा इस बात पर ऊपरी सीमा लगाती है कि किसी संसाधन का उपयोग आपके एप्लिकेशन में कैसे किया जा सकता है। यानी इस हिसाब से अगर आप लिमिट में 1GB RAM कहते हैं तो आपका एप्लिकेशन 1GB से ज्यादा RAM का इस्तेमाल नहीं कर पाएगा. और यदि वह अचानक ऐसा चाहता है और ऐसा करने का प्रयास करता है, तो ओम किलर नामक एक प्रक्रिया, मेमोरी से बाहर, यानी आएगी और आपके एप्लिकेशन को मार देगी - अर्थात, यह बस पुनरारंभ हो जाएगी। सीपीयू के आधार पर एप्लिकेशन पुनः आरंभ नहीं होंगे। सीपीयू के संदर्भ में, यदि कोई एप्लिकेशन निर्दिष्ट सीमा से अधिक, बहुत अधिक उपयोग करने का प्रयास करता है, तो सीपीयू को सख्ती से चुना जाएगा। इससे पुनरारंभ नहीं होता है. यह सीमा है - यह ऊपरी सीमा है.

और एक निवेदन है. एक अनुरोध यह है कि कुबेरनेट्स कैसे समझता है कि आपके कुबेरनेट्स क्लस्टर में नोड्स अनुप्रयोगों से कैसे भरे हुए हैं। यानी एक अनुरोध आपके आवेदन का एक प्रकार का कमिटमेंट है। यह कहता है कि मैं क्या उपयोग करना चाहता हूं: "मैं चाहूंगा कि आप मेरे लिए इतना सीपीयू और इतनी मेमोरी आरक्षित रखें।" कितनी सरल सादृश्यता है. क्या होगा यदि हमारे पास एक नोड है जिसमें, मुझे नहीं पता, कुल मिलाकर 8 सीपीयू हैं। और एक पॉड वहां आता है, जिसके अनुरोध पर 1 सीपीयू लिखा होता है, जिसका मतलब है कि नोड में 7 सीपीयू बचे हैं। अर्थात्, तदनुसार, जैसे ही 8 पॉड्स इस नोड पर आते हैं, जिनमें से प्रत्येक के अनुरोधों में 1 सीपीयू होता है, नोड, जैसे कि कुबेरनेट्स के दृष्टिकोण से, सीपीयू से बाहर हो गया है और अनुरोधों के साथ अधिक पॉड्स नहीं हो सकते हैं इस नोड पर लॉन्च किया गया. यदि सभी नोड्स का सीपीयू खत्म हो जाता है, तो कुबेरनेट्स यह कहना शुरू कर देगा कि आपके पॉड्स को चलाने के लिए क्लस्टर में कोई उपयुक्त नोड नहीं हैं क्योंकि सीपीयू खत्म हो गया है।

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

और जब आपके पास अनुरोध होते हैं, तो सीमाएं बहुत अलग नहीं होती हैं, कम से कम सीमा या अनुरोधों से कई गुना अधिक नहीं होती हैं, तो आपके पास कुबेरनेट्स क्लस्टर के नोड्स में अनुप्रयोगों का ऐसा सामान्य, तर्कसंगत भरना हो सकता है। साथ ही, कुबेरनेट्स को लगभग इस बात की जानकारी है कि वह किस चीज को कितना कहां रखता है, किस चीज का कितना हिस्सा कहां उपयोग करता है। यानि कि ये एक ऐसा ही पल है. इसे समझना जरूरी है. और यह नियंत्रित करना महत्वपूर्ण है कि यह संकेत दिया गया है।

डेटा भंडारण

हमारा अगला बिंदु डेटा स्टोरेज के बारे में है। उनके साथ क्या करें और सामान्य तौर पर, कुबेरनेट्स में दृढ़ता के साथ क्या करें?

मुझे लगता है, फिर से, हमारे भीतर शाम का स्कूल, कुबेरनेट्स में डेटाबेस के बारे में एक विषय था। और मुझे ऐसा लगता है कि मुझे यह भी मोटे तौर पर पता है कि आपके सहकर्मियों ने आपसे क्या कहा था जब पूछा गया था: "क्या कुबेरनेट्स में डेटाबेस चलाना संभव है?" किसी कारण से, मुझे ऐसा लगता है कि आपके सहकर्मियों को आपको यह बताना चाहिए था कि यदि आप यह प्रश्न पूछ रहे हैं कि क्या कुबेरनेट्स में डेटाबेस चलाना संभव है, तो यह असंभव है।

यहाँ तर्क सरल है. बस मामले में, मैं एक बार फिर से समझाऊंगा, यदि आप वास्तव में एक अच्छे व्यक्ति हैं जो वितरित नेटवर्क स्टोरेज की काफी दोष-सहिष्णु प्रणाली का निर्माण कर सकते हैं, तो समझें कि इस मामले में डेटाबेस को कैसे फिट किया जाए, कंटेनरों में क्लाउड नेटिव को कैसे काम करना चाहिए सामान्य तौर पर डेटाबेस में। सबसे अधिक संभावना है, आपके पास इसे चलाने के तरीके के बारे में कोई प्रश्न नहीं है। यदि आपके पास ऐसा कोई प्रश्न है, और आप यह सुनिश्चित करना चाहते हैं कि यह सब सामने आए और उत्पादन में मृत्यु तक खड़ा रहे और कभी गिरे नहीं, तो ऐसा नहीं होता है। इस दृष्टिकोण से आपको अपने पैरों पर कुल्हाड़ी मारने की गारंटी दी जाती है। इसलिए ऐसा न करना ही बेहतर है.

हमें उस डेटा के साथ क्या करना चाहिए जिसे हमारा एप्लिकेशन संग्रहीत करना चाहता है, कुछ चित्र जो उपयोगकर्ता अपलोड करते हैं, कुछ चीजें जो हमारा एप्लिकेशन स्टार्टअप पर अपने संचालन के दौरान उत्पन्न करता है, उदाहरण के लिए? कुबेरनेट्स में उनके साथ क्या करें?

सामान्य तौर पर, आदर्श रूप से, हाँ, निश्चित रूप से, कुबेरनेट्स बहुत अच्छी तरह से डिज़ाइन किया गया है और आमतौर पर शुरुआत में स्टेटलेस अनुप्रयोगों के लिए कल्पना की गई थी। यानी उन एप्लिकेशन के लिए जो बिल्कुल भी जानकारी संग्रहीत नहीं करते हैं। यह आदर्श है.

लेकिन, निश्चित रूप से, आदर्श विकल्प हमेशा मौजूद नहीं होता है। तो क्या हुआ? पहला और सरल बिंदु किसी प्रकार का S3 लेना है, न कि घर में बना हुआ, जो यह भी स्पष्ट नहीं है कि यह कैसे काम करता है, लेकिन किसी प्रदाता से। एक अच्छा, सामान्य प्रदाता - और अपने एप्लिकेशन को S3 का उपयोग करना सिखाएं। अर्थात्, जब आपका उपयोगकर्ता कोई फ़ाइल अपलोड करना चाहता है, तो कहें "यहाँ, कृपया, इसे S3 पर अपलोड करें।" जब वह इसे प्राप्त करना चाहता है, तो कहें: "यहां S3 का लिंक है और इसे यहां से ले जाएं।" यह आदर्श है.

यदि अचानक किसी कारण से यह आदर्श विकल्प उपयुक्त नहीं है, आपके पास एक एप्लिकेशन है जिसे आपने नहीं लिखा है, आप विकसित नहीं कर रहे हैं, या यह किसी प्रकार की भयानक विरासत है, यह S3 प्रोटोकॉल का उपयोग नहीं कर सकता है, लेकिन स्थानीय निर्देशिकाओं के साथ काम करना चाहिए स्थानीय फ़ोल्डर. कुछ अधिक या कम सरल लें, कुबेरनेट्स को तैनात करें। यानी, मुझे ऐसा लगता है कि कुछ न्यूनतम कार्यों के लिए तुरंत सेफ की बाड़ लगाना एक बुरा विचार है। क्योंकि सेफ, बेशक, अच्छा और फैशनेबल है। लेकिन अगर आप वास्तव में यह नहीं समझ पा रहे हैं कि आप क्या कर रहे हैं, तो एक बार जब आप सेफ पर कुछ डाल देते हैं, तो आप बहुत आसानी से और आसानी से उसे फिर कभी वहां से नहीं हटा सकते हैं। क्योंकि, जैसा कि आप जानते हैं, सेफ़ अपने क्लस्टर में डेटा को बाइनरी रूप में संग्रहीत करता है, न कि साधारण फ़ाइलों के रूप में। इसलिए, यदि अचानक सेफ क्लस्टर टूट जाता है, तो पूरी और उच्च संभावना है कि आपको अपना डेटा वहां से दोबारा कभी नहीं मिलेगा।

हमारे पास सेफ पर एक कोर्स होगा, आप कर सकते हैं कार्यक्रम से परिचित हों और एक आवेदन जमा करें.

इसलिए, एनएफएस सर्वर जैसा कुछ सरल करना बेहतर है। कुबेरनेट्स उनके साथ काम कर सकते हैं, आप एनएफएस सर्वर के तहत एक निर्देशिका माउंट कर सकते हैं - आपका एप्लिकेशन बिल्कुल एक स्थानीय निर्देशिका की तरह है। उसी समय, स्वाभाविक रूप से, आपको यह समझने की आवश्यकता है कि, फिर से, आपको अपने एनएफएस के साथ कुछ करने की आवश्यकता है, आपको यह समझने की आवश्यकता है कि कभी-कभी यह अप्राप्य हो सकता है और इस प्रश्न पर विचार करें कि आप इस मामले में क्या करेंगे। शायद इसका बैकअप कहीं अलग मशीन पर रखा जाना चाहिए।

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

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

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

मिनियो को क्या समस्याएँ हैं? मिनियो के साथ मुख्य समस्या यह है कि इस चीज़ को काम करने के लिए, इसे कहीं न कहीं चलाने की आवश्यकता है, और इसमें किसी प्रकार की फ़ाइल प्रणाली, यानी स्टोरेज होनी चाहिए। और यहां हमें उन्हीं समस्याओं का सामना करना पड़ता है जो सेफ़ को होती हैं। यानि Minio को अपनी फ़ाइलें कहीं न कहीं संग्रहित करनी होंगी। यह आपकी फ़ाइलों के लिए बस एक HTTP इंटरफ़ेस है। इसके अलावा, कार्यक्षमता अमेज़ॅन के S3 की तुलना में स्पष्ट रूप से खराब है। पहले, यह उपयोगकर्ता को ठीक से अधिकृत करने में सक्षम नहीं था। अब, जहां तक ​​मुझे पता है, यह पहले से ही विभिन्न प्राधिकरणों के साथ बकेट बना सकता है, लेकिन फिर, मुझे ऐसा लगता है कि मुख्य समस्या, कम से कम अंतर्निहित भंडारण प्रणाली है।

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

मेघमूलनिभाव

और अंतिम उपविषय क्लाउडनेटिव क्या है। इसकी आवश्यकता क्यों है? क्लाउडनेटिवनेस इत्यादि।

यानी वे एप्लिकेशन जो आधुनिक क्लाउड इंफ्रास्ट्रक्चर में काम करने में सक्षम और लिखे गए हैं। लेकिन, वास्तव में, क्लाउडनेटिव का एक और पहलू भी है। यह न केवल एक एप्लिकेशन है जो आधुनिक क्लाउड इंफ्रास्ट्रक्चर की सभी आवश्यकताओं को ध्यान में रखता है, बल्कि यह भी जानता है कि इस आधुनिक क्लाउड इंफ्रास्ट्रक्चर के साथ कैसे काम करना है, इस तथ्य के फायदे और नुकसान का लाभ उठाना है कि यह इन क्लाउडों में काम करता है। केवल अति न करें और क्लाउड में काम न करें, बल्कि क्लाउड में काम करने के लाभों का लाभ उठाएं।

आइए कुबेरनेट्स को एक उदाहरण के रूप में लें। आपका एप्लिकेशन कुबेरनेट्स में चल रहा है। आपका एप्लिकेशन, या यूं कहें कि आपके एप्लिकेशन के व्यवस्थापक, हमेशा एक सेवा खाता बना सकते हैं। अर्थात्, Kubernetes में इसके सर्वर में ही प्राधिकरण के लिए एक खाता है। वहां कुछ अधिकार पेंच करें जिनकी हमें आवश्यकता है। और आप अपने एप्लिकेशन के भीतर से कुबेरनेट्स तक पहुंच सकते हैं। आप इस तरह क्या कर सकते हैं? उदाहरण के लिए, एप्लिकेशन से, इस बारे में डेटा प्राप्त करें कि आपके अन्य एप्लिकेशन, अन्य समान उदाहरण कहां स्थित हैं, और यदि ऐसी आवश्यकता है, तो किसी तरह कुबेरनेट्स के शीर्ष पर क्लस्टर करें।

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

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

स्केलिंग के लिए भी यही बात लागू होती है। नियमित कुबेरनेट्स क्लाउड प्रदाताओं के साथ एकीकृत हो सकते हैं। यह समझना जानता है कि यदि क्लस्टर में नोड्स खत्म हो गए हैं, यानी नोड स्थान समाप्त हो गया है, तो आपको जोड़ने की आवश्यकता है - कुबेरनेट्स स्वयं आपके क्लस्टर में नए नोड्स जोड़ देगा और उन पर पॉड्स लॉन्च करना शुरू कर देगा। यानी जब आपका लोड आता है तो चूल्हों की संख्या बढ़ने लगती है. जब क्लस्टर में इन पॉड्स के लिए नोड्स खत्म हो जाते हैं, तो कुबेरनेट्स नए नोड्स लॉन्च करता है और, तदनुसार, पॉड्स की संख्या अभी भी बढ़ सकती है। और यह बहुत सुविधाजनक है. यह तुरंत क्लस्टर को स्केल करने का एक सीधा अवसर है। बहुत तेज़ नहीं, इस अर्थ में कि यह एक सेकंड नहीं है, बल्कि नए नोड्स जोड़ने के लिए एक मिनट की तरह है।

लेकिन मेरे अनुभव से, फिर से, यह सबसे बढ़िया चीज़ है जो मैंने कभी देखी है। जब क्लाउडनेटिव क्लस्टर को दिन के समय के आधार पर बढ़ाया गया। यह एक बैकएंड सेवा थी जिसका उपयोग बैक ऑफिस में लोग करते थे। यानी, वे सुबह 9 बजे काम पर आते हैं, सिस्टम में लॉग इन करना शुरू करते हैं, और तदनुसार, क्लाउडनेटिव क्लस्टर, जहां यह सब चल रहा है, फूलना शुरू कर देता है, नए पॉड्स लॉन्च करता है ताकि काम पर आने वाला हर कोई एप्लिकेशन के साथ काम कर सके। जब वे रात 8 बजे या शाम 6 बजे काम छोड़ देते हैं, तो कुबेरनेट्स क्लस्टर नोटिस करते हैं कि अब कोई भी एप्लिकेशन का उपयोग नहीं कर रहा है और सिकुड़ना शुरू कर देता है। 30 प्रतिशत तक की बचत की गारंटी है। उस समय यह अमेज़ॅन में काम करता था; उस समय रूस में कोई भी नहीं था जो इसे इतनी अच्छी तरह से कर सके।

मैं आपको सीधे बताऊंगा, बचत केवल 30 प्रतिशत है क्योंकि हम कुबेरनेट्स का उपयोग करते हैं और क्लाउड की क्षमताओं का लाभ उठाते हैं। अब ये काम रूस में भी किया जा सकेगा. बेशक, मैं किसी को विज्ञापन नहीं दूँगा, लेकिन मान लीजिए कि ऐसे प्रदाता हैं जो ऐसा कर सकते हैं, इसे एक बटन के साथ बॉक्स से बाहर उपलब्ध करा सकते हैं।

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

और यही वह है जो आपको, सबसे पहले, हमेशा अपने बुनियादी ढांचे पर नियंत्रण रखने की अनुमति देता है, हमेशा यह समझने की कि यह किस स्थिति में है। दूसरे, त्रुटियों का कारण बनने वाले मैन्युअल संचालन से बचें। तीसरा, जिसे टर्नओवर कहा जाता है उससे बचें, जब आपको लगातार वही मैन्युअल कार्य करने की आवश्यकता होती है। चौथा, यह आपको विफलता की स्थिति में बहुत तेजी से ठीक होने की अनुमति देता है। रूस में, जब भी मैं इस बारे में बात करता हूं, तो हमेशा बड़ी संख्या में लोग होते हैं जो कहते हैं: "हां, यह स्पष्ट है, लेकिन आपके पास दृष्टिकोण हैं, संक्षेप में, कुछ भी ठीक करने की कोई आवश्यकता नहीं है।" लेकिन ये बिल्कुल सच है। यदि आपके बुनियादी ढांचे में कुछ टूटा हुआ है, तो क्लाउडनेटिव दृष्टिकोण के दृष्टिकोण से और एक कोड के रूप में बुनियादी ढांचे के दृष्टिकोण से, इसे ठीक करने के बजाय, सर्वर पर जाकर, यह पता लगाना कि क्या टूटा हुआ है और इसे ठीक करना आसान है सर्वर को हटाने और इसे फिर से बनाने के लिए। और मैं यह सब बहाल करवाऊंगा.

इन सभी मुद्दों पर अधिक विस्तार से चर्चा की गई है कुबेरनेट्स वीडियो पाठ्यक्रम: जूनियर, बेसिक, मेगा. लिंक का अनुसरण करके आप कार्यक्रम और शर्तों से परिचित हो सकते हैं। सुविधाजनक बात यह है कि आप घर से पढ़ाई करके या दिन में 1-2 घंटे काम करके कुबेरनेट्स में महारत हासिल कर सकते हैं।

स्रोत: www.habr.com