Kubernetes मध्ये अनुप्रयोग विकसित करण्यासाठी आवश्यकता

आज मी ऍप्लिकेशन्स कसे लिहायचे आणि कुबर्नेट्समध्ये चांगले काम करण्यासाठी तुमच्या ऍप्लिकेशनसाठी कोणत्या आवश्यकता आहेत याबद्दल बोलण्याची योजना आखली आहे. जेणेकरून अनुप्रयोगासह कोणतीही डोकेदुखी होऊ नये, जेणेकरून आपल्याला त्याभोवती कोणतेही "क्रॅच" शोधून काढण्याची आणि तयार करण्याची गरज नाही - आणि सर्व काही कुबरनेटेसच्या इच्छेनुसार कार्य करते.

हे व्याख्यान "कुबर्नेट्सवरील स्लर्म नाईट स्कूल" संध्याकाळच्या शाळेची मुक्त सैद्धांतिक व्याख्याने तुम्ही पाहू शकता YouTube वर, प्लेलिस्टमध्ये गटबद्ध केले आहे. ज्यांना व्हिडीओ ऐवजी मजकूर आवडतो त्यांच्यासाठी आम्ही हा लेख तयार केला आहे.

माझे नाव पावेल सेलिवानोव आहे, सध्या मी Mail.ru क्लाउड सोल्युशन्समध्ये अग्रगण्य DevOps अभियंता आहे, आम्ही क्लाउड बनवतो, आम्ही मॅनेजमेंट कुबर्नेट्स बनवतो आणि असेच बरेच काही. माझ्या कार्यांमध्ये आता विकासात सहाय्य करणे, हे ढग रोल आउट करणे, आम्ही लिहित असलेले ऍप्लिकेशन रोल आउट करणे आणि आम्ही आमच्या वापरकर्त्यांसाठी प्रदान केलेली साधने थेट विकसित करणे समाविष्ट आहे.

मी DevOps करत आहे, मला वाटतं, गेल्या तीन वर्षांपासून. परंतु, तत्त्वतः, मी कदाचित सुमारे पाच वर्षांपासून DevOps जे करते ते करत आहे. त्यापूर्वी, मी मुख्यतः प्रशासक सामग्रीमध्ये गुंतलो होतो. मी कुबेरनेट्ससोबत खूप पूर्वीपासून काम करायला सुरुवात केली होती - कदाचित मी त्याच्यासोबत काम करायला सुरुवात करून सुमारे चार वर्षे उलटून गेली आहेत.

सर्वसाधारणपणे, कुबर्नेट्सची आवृत्ती 1.3, बहुधा, आणि कदाचित 1.2 - जेव्हा ती अद्याप बाल्यावस्थेत होती तेव्हा मी सुरुवात केली. आता ते बाल्यावस्थेत राहिलेले नाही - आणि हे उघड आहे की ज्या अभियंत्यांना कुबर्नेट्स करायला आवडेल त्यांना बाजारात मोठी मागणी आहे. आणि कंपन्यांमध्ये अशा लोकांना खूप मागणी असते. त्यामुळे प्रत्यक्षात हे व्याख्यान दिसू लागले.

मी ज्याबद्दल बोलणार आहे त्या योजनेबद्दल जर आपण बोललो तर ते असे दिसते, कंसात लिहिलेले आहे (TL;DR) - “खूप लांब; वाचू नका" माझ्या आजच्या सादरीकरणात अंतहीन याद्या असतील.

खरं तर, मला स्वतःला अशी सादरीकरणे बनवताना आवडत नाहीत, परंतु हा एक असा विषय आहे की जेव्हा मी हे सादरीकरण तयार करत होतो तेव्हा ही माहिती वेगळ्या पद्धतीने कशी व्यवस्थित करावी हे मला खरोखरच समजले नाही.

कारण, मोठ्या प्रमाणावर, ही माहिती “ctrl+c, ctrl+v” आहे, इतर गोष्टींबरोबरच, DevOps विभागातील आमच्या Wiki मधून, जिथे आम्ही विकसकांसाठी आवश्यकता लिहिल्या आहेत: “मित्रांनो, जेणेकरून आम्ही तुमचा अर्ज लाँच करू. कुबर्नेट्स, हे असे असले पाहिजे."

म्हणूनच सादरीकरण इतकी मोठी यादी बनली. क्षमस्व. मी शक्य तितके सांगण्याचा प्रयत्न करेन जेणेकरून शक्य असल्यास ते कंटाळवाणे होणार नाही.

आता आपण काय पाहणार आहोत:

• हे आहेत, प्रथम, लॉग (अॅप्लिकेशन लॉग?), कुबर्नेट्समध्ये त्यांचे काय करावे, त्यांचे काय करावे, ते काय असावे;
• Kubernetes मधील कॉन्फिगरेशनचे काय करावे, Kubernetes साठी अनुप्रयोग कॉन्फिगर करण्याचे सर्वोत्तम आणि सर्वात वाईट मार्ग कोणते आहेत;
• सर्वसाधारणपणे प्रवेशयोग्यता तपासण्या काय आहेत, ते कशासारखे दिसले पाहिजेत याबद्दल बोलूया;
• ग्रेसफुल शटडाउन म्हणजे काय याबद्दल बोलूया;
• संसाधनांबद्दल पुन्हा बोलूया;
• चला डेटा स्टोरेजच्या विषयावर पुन्हा एकदा स्पर्श करूया;
• आणि शेवटी मी तुम्हाला सांगेन की या रहस्यमय क्लाउड-नेटिव्ह ऍप्लिकेशनचा शब्द काय आहे. Cloudnativeness, या संज्ञेचे विशेषण म्हणून.

नोंदी

मी लॉगसह प्रारंभ करण्याचे सुचवितो - ज्यासह हे लॉग कुबर्नेट्समध्ये हलवावे लागतील. आता तुम्ही Kubernetes मध्ये एक अॅप्लिकेशन लाँच केले आहे. क्लासिक्सनुसार, पूर्वी अनुप्रयोग नेहमी फाईलमध्ये कुठेतरी लॉग लिहित असत. खराब अॅप्लिकेशन्सने अॅप्लिकेशन लॉन्च करणाऱ्या डेव्हलपरच्या होम डिरेक्टरीमधील फाइलवर लॉग लिहिले. चांगल्या ऍप्लिकेशन्सने कुठेतरी फाईलवर लॉग लिहिले /var/log.

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

जेव्हा आपण कुबर्नेट्सच्या जगात जातो आणि तिथे तीच गोष्ट चालवतो, तेव्हा आपण ज्या गोष्टीकडे लक्ष देऊ शकता ते म्हणजे लोक, जसे त्यांनी फाईलमध्ये लॉग लिहिले आहेत, ते लिहिणे सुरू ठेवा.

असे दिसून येते की जर आपण कुबर्नेट्सबद्दल बोललो तर, डॉकर कंटेनरमधून कुठेतरी लॉग लिहिण्याची योग्य जागा म्हणजे त्यांना ऍप्लिकेशनमधून तथाकथित Stdout/Stderr, म्हणजेच ऑपरेटिंग सिस्टमच्या मानक आउटपुट स्ट्रीमवर लिहिणे, मानक त्रुटी आउटपुट डॉकरमध्ये आणि विशेषत: कुबेरनेटिसमध्ये तत्त्वानुसार लॉग ठेवण्याचा हा सर्वात योग्य, सोपा आणि सर्वात तार्किक मार्ग आहे. कारण तुमचा ऍप्लिकेशन Stdout/Stderr वर लॉग लिहित असल्यास, या लॉगचे काय करायचे हे डॉकर आणि कुबर्नेट्स ऍड-ऑनवर अवलंबून आहे. डॉकर डीफॉल्टनुसार त्याच्या विशेष फाइल्स JSON फॉरमॅटमध्ये तयार करेल.

इथे प्रश्न पडतो, या नोंदींचे पुढे काय कराल? सर्वात सोपा मार्ग स्पष्ट आहे, आमच्याकडे करण्याची क्षमता आहे kubectl logs आणि या “शेंगा” च्या नोंदी पहा. परंतु, कदाचित, हा एक चांगला पर्याय नाही - लॉगसह काहीतरी वेगळे करणे आवश्यक आहे.

आत्तासाठी, आपण लॉगच्या विषयाला स्पर्श केल्यामुळे, लॉग कसे दिसले पाहिजेत अशा गोष्टीबद्दल आपण त्याच वेळी बोलूया. म्हणजेच, हे कुबर्नेट्सवर थेट लागू होत नाही, परंतु जेव्हा आपण लॉगचे काय करावे याबद्दल विचार करू लागतो, तेव्हा याबद्दल देखील विचार करणे चांगले होईल.

आम्हाला अशा प्रकारच्या साधनाची गरज आहे, ज्यात मैत्रीपूर्ण मार्गाने, आमचे डॉकर त्याच्या फायलींमध्ये ठेवणारे हे लॉग घेईल आणि ते कुठेतरी पाठवेल. सर्वसाधारणपणे, आम्ही कुबर्नेट्समध्ये डेमनसेटच्या रूपात काही प्रकारचे एजंट लाँच करतो - एक लॉग कलेक्टर, ज्याला डॉकरने गोळा केलेले लॉग कोठे आहेत हे फक्त सांगितले जाते. आणि हा गोळा करणारा एजंट त्यांना सहजपणे घेऊन जातो, कदाचित त्यांचे वाटेत विश्लेषण देखील करतो, कदाचित त्यांना काही अतिरिक्त मेटा-माहिती देऊन समृद्ध करतो आणि शेवटी, त्यांना कुठेतरी स्टोरेजसाठी पाठवतो. तेथे तफावत आधीच शक्य आहे. सर्वात सामान्य म्हणजे कदाचित Elasticsearch, जिथे तुम्ही नोंदी ठेवू शकता आणि तेथून तुम्ही ते सोयीस्करपणे पुनर्प्राप्त करू शकता. मग, विनंती वापरून, किबाना वापरून, उदाहरणार्थ, त्यावर आधारित आलेख तयार करा, त्यावर आधारित सूचना तयार करा आणि असेच.

सर्वात महत्त्वाची कल्पना, मला ती पुन्हा पुन्हा सांगायची आहे, ती म्हणजे डॉकरच्या आत, विशेषत: कुबर्नेट्समध्ये, तुमचे लॉग फाइलमध्ये संग्रहित करणे ही अतिशय वाईट कल्पना आहे.

कारण प्रथम, कंटेनरमधील लॉग फाइलमध्ये मिळवणे कठीण आहे. आपण प्रथम कंटेनरमध्ये जावे, तेथे कार्यान्वित केले पाहिजे आणि नंतर लॉग पहा. पुढील मुद्दा असा आहे की जर तुमच्याकडे फाईलमध्ये लॉग्स असतील तर कंटेनरमध्ये सामान्यत: किमान वातावरण असते आणि लॉगसह सामान्य कामासाठी आवश्यक असलेल्या कोणत्याही उपयुक्तता नसतात. त्यांना दफन करा, त्यांच्याकडे पहा, त्यांना मजकूर संपादकात उघडा. पुढचा क्षण असा आहे की जेव्हा आमच्याकडे कंटेनरच्या आत फाइलमध्ये लॉग असतात, जर हा कंटेनर हटवला गेला तर, तुम्हाला समजेल, लॉग त्यासह मरतील. त्यानुसार, कंटेनरचा कोणताही रीस्टार्ट म्हणजे आणखी लॉग नाहीत. पुन्हा, वाईट पर्याय.

आणि शेवटचा मुद्दा असा आहे की कंटेनरमध्ये तुमच्याकडे सहसा तुमचा अर्ज असतो आणि तेच - सामान्यतः ही एकमेव प्रक्रिया चालू असते. तुमच्या लॉगसह फाइल्स फिरवणाऱ्या कोणत्याही प्रक्रियेबद्दल अजिबात चर्चा नाही. फाइलवर नोंदी लिहिल्या जाऊ लागताच, याचा अर्थ, माफ करा, आम्ही उत्पादन सर्व्हर गमावण्यास सुरवात करू. कारण, प्रथम, ते शोधणे कठीण आहे, कोणीही त्यांचा मागोवा घेत नाही, तसेच त्यांच्यावर कोणीही नियंत्रण ठेवत नाही - त्यानुसार, सर्व्हरवरील जागा संपेपर्यंत फाइल अविरतपणे वाढते. म्हणून, मी पुन्हा सांगतो की डॉकरमध्ये लॉग इन करणे, विशेषत: कुबर्नेट्समध्ये, फाइलमध्ये लॉग करणे ही वाईट कल्पना आहे.

पुढील मुद्दा, येथे मला याबद्दल पुन्हा बोलायचे आहे - आम्ही लॉगच्या विषयाला स्पर्श करत असल्याने, त्यांच्यासह कार्य करणे सोयीस्कर होण्यासाठी लॉग कसे दिसले पाहिजे याबद्दल बोलणे चांगले होईल. मी म्हटल्याप्रमाणे, हा विषय थेट कुबर्नेट्सशी संबंधित नाही, परंतु तो DevOps च्या विषयाशी खूप चांगला संबंधित आहे. डेव्हलपमेंट कल्चर आणि या दोन वेगवेगळ्या विभागांमधील मैत्री या विषयावर - देव आणि ऑप्स, जेणेकरून प्रत्येकाला सोयीस्कर वाटेल.

याचा अर्थ असा की आदर्शपणे, आज, लॉग जेएसओएन फॉरमॅटमध्ये लिहिले जावेत. जर तुमचा स्वतःचा काही न समजण्याजोगा अनुप्रयोग असेल, जो न समजण्याजोग्या फॉरमॅटमध्ये लॉग लिहितो कारण तुम्ही काही प्रकारचे प्रिंट किंवा असे काहीतरी टाकले असेल, तर आता काही प्रकारचे फ्रेमवर्क, काही प्रकारचे रॅपर गुगल करण्याची वेळ आली आहे जी तुम्हाला सामान्य लॉगिंग लागू करू देते; तेथे JSON मध्ये लॉगिंग पॅरामीटर्स सक्षम करा, कारण JSON हे साधे स्वरूप आहे, त्याचे पार्सिंग करणे सोपे आहे.

जर तुमचा JSON काही निकषांनुसार कार्य करत नसेल, तर कोणाला काय माहित नाही, तर किमान लॉग इन फॉरमॅटमध्ये लिहा ज्याचे विश्लेषण केले जाऊ शकते. येथे, त्याऐवजी, या वस्तुस्थितीबद्दल विचार करणे योग्य आहे की, उदाहरणार्थ, जर तुम्ही कंटेनरचा एक समूह चालवत असाल किंवा फक्त nginx सह प्रक्रिया करत असाल आणि प्रत्येकाची स्वतःची लॉगिंग सेटिंग्ज आहेत, तर कदाचित असे दिसते की ते तुमच्यासाठी खूप गैरसोयीचे असेल. त्यांचे विश्लेषण करा. कारण प्रत्येक नवीन nginx उदाहरणासाठी तुम्हाला तुमचा स्वतःचा पार्सर लिहावा लागेल, कारण ते लॉग वेगळ्या पद्धतीने लिहितात. पुन्हा, या सर्व nginx उदाहरणांमध्ये समान लॉगिंग कॉन्फिगरेशन आहे आणि त्यांचे सर्व लॉग पूर्णपणे एकसारखे लिहिले आहेत याची खात्री करण्याबद्दल विचार करणे योग्य आहे. हेच पूर्णपणे सर्व अनुप्रयोगांना लागू होते.

सरतेशेवटी, मला आगीत इंधन देखील जोडायचे आहे की, आदर्शपणे, मल्टी-लाइन फॉरमॅट लॉग टाळले पाहिजेत. ही गोष्ट आहे, जर तुम्ही कधीही लॉग कलेक्टर्ससोबत काम केले असेल, तर बहुधा ते तुम्हाला काय वचन देतात ते तुम्ही पाहिले असेल, की ते मल्टी-लाइन लॉगसह काम करू शकतात, ते कसे गोळा करायचे ते जाणून घेऊ शकतात. खरं तर, माझ्या मते, आज एकही कलेक्टर बहु-लाइन लॉग सामान्यपणे, पूर्णपणे आणि त्रुटींशिवाय गोळा करू शकत नाही. मानवी मार्गाने, जेणेकरून ते सोयीस्कर आणि त्रुटी-मुक्त असेल.

परंतु स्टॅक ट्रेस हे नेहमीच मल्टी-लाइन लॉग असतात आणि ते कसे टाळायचे. येथे प्रश्न असा आहे की लॉग हा इव्हेंटचा रेकॉर्ड असतो आणि स्टॅक्ट्रेस हा प्रत्यक्षात लॉग नाही. जर आम्ही लॉग गोळा केले आणि ते इलास्टिकसर्चमध्ये कुठेतरी ठेवले आणि नंतर त्यांच्याकडून आलेख काढले, तुमच्या साइटवर वापरकर्त्याच्या क्रियाकलापांचे काही अहवाल तयार केले, तर तुम्हाला स्टॅक ट्रेस मिळाल्यावर याचा अर्थ असा होतो की काहीतरी अनपेक्षित घडत आहे. तुमच्या अनुप्रयोगात एक न हाताळलेली परिस्थिती. आणि ते ट्रॅक करू शकणार्‍या सिस्टममध्ये कुठेतरी स्टॅक ट्रेस स्वयंचलितपणे अपलोड करणे अर्थपूर्ण आहे.

हे सॉफ्टवेअर (समान सेन्ट्री) आहे जे विशेषतः स्टॅक ट्रेससह कार्य करण्यासाठी बनवले आहे. ते ताबडतोब स्वयंचलित कार्ये तयार करू शकते, ती एखाद्याला नियुक्त करू शकते, स्टॅक्टट्रेसेस आल्यावर अलर्ट करू शकते, या स्टॅक्टट्रेसेस एका प्रकारानुसार गटबद्ध करू शकतात, इत्यादी. तत्त्वतः, जेव्हा आपण लॉगबद्दल बोलतो तेव्हा स्टॅक्ट्रेसेसबद्दल बोलण्यात फारसा अर्थ नाही, कारण या सर्व भिन्न हेतू असलेल्या भिन्न गोष्टी आहेत.

कॉन्फिगरेशन

पुढे आम्ही कुबर्नेट्समधील कॉन्फिगरेशनबद्दल बोलू: त्याचे काय करावे आणि कुबर्नेट्समधील अनुप्रयोग कसे कॉन्फिगर केले जावेत. सर्वसाधारणपणे, मी सहसा म्हणतो की डॉकर कंटेनरबद्दल नाही. प्रत्येकाला माहित आहे की डॉकर कंटेनरबद्दल आहे, अगदी ज्यांनी डॉकरसोबत जास्त काम केले नाही. मी पुन्हा सांगतो, डॉकर कंटेनरबद्दल नाही.

डॉकर, माझ्या मते, मानकांबद्दल आहे. आणि व्यावहारिकदृष्ट्या प्रत्येक गोष्टीसाठी मानके आहेत: आपला अनुप्रयोग तयार करण्यासाठी मानके, आपला अनुप्रयोग स्थापित करण्यासाठी मानके.

आणि ही गोष्ट - आम्ही ती आधी वापरली होती, ती फक्त कंटेनरच्या आगमनाने विशेषतः लोकप्रिय झाली - या गोष्टीला ENV (पर्यावरण) व्हेरिएबल्स म्हणतात, म्हणजेच तुमच्या ऑपरेटिंग सिस्टममध्ये असलेले पर्यावरणीय चल. तुमचा अॅप्लिकेशन कॉन्फिगर करण्याचा हा साधारणपणे एक आदर्श मार्ग आहे, कारण तुमच्याकडे JAVA, Python, Go, Perl, God forbid मधील अॅप्लिकेशन्स असतील आणि ते सर्व डेटाबेस होस्ट, डेटाबेस वापरकर्ता, डेटाबेस पासवर्ड व्हेरिएबल्स वाचू शकतील, तर ते आदर्श आहे. तुमच्याकडे डेटाबेस प्लॅनमध्ये चार वेगवेगळ्या भाषांमधील अॅप्लिकेशन्स त्याच प्रकारे कॉन्फिगर केलेले आहेत. आणखी भिन्न कॉन्फिगरेशन नाहीत.

ENV व्हेरिएबल्स वापरून सर्व काही कॉन्फिगर केले जाऊ शकते. जेव्हा आपण Kubernetes बद्दल बोलतो, तेव्हा डिप्लॉयमेंटमध्ये ENV व्हेरिएबल्स घोषित करण्याचा एक चांगला मार्ग आहे. त्यानुसार, जर आम्ही गुप्त डेटाबद्दल बोलत आहोत, तर आम्ही ताबडतोब ENV व्हेरिएबल्समधील गुप्त डेटा (संकेतशब्द ते डेटाबेस इ.) गुप्त मध्ये ढकलू शकतो, एक गुप्त क्लस्टर तयार करू शकतो आणि तैनातीमधील ENV वर्णनात सूचित करू शकतो की आम्ही थेट घोषणा करत नाही. या व्हेरिएबलचे मूल्य आणि या डेटाबेस पासवर्ड व्हेरिएबलचे मूल्य गुप्ततेतून वाचले जाईल. हे मानक कुबर्नेट्स वर्तन आहे. आणि तुमचे अॅप्लिकेशन कॉन्फिगर करण्याचा हा सर्वात आदर्श पर्याय आहे. फक्त कोड स्तरावर, हे पुन्हा विकसकांना लागू होते. तुम्ही DevOps असल्यास, तुम्ही विचारू शकता: “मित्रांनो, कृपया तुमच्या अॅप्लिकेशनला पर्यावरण व्हेरिएबल्स वाचायला शिकवा. आणि आपण सर्व आनंदी होऊ.”

जर कंपनीतील प्रत्येकाने समान नामांकित पर्यावरण व्हेरिएबल्स वाचले तर ते छान आहे. जेणेकरुन असे होणार नाही की काही पोस्टग्रेस डेटाबेसची वाट पाहत आहेत, इतर डेटाबेस नावाची वाट पाहत आहेत, इतर कशाची तरी वाट पाहत आहेत, इतर काही प्रकारच्या डीबीएनची वाट पाहत आहेत, जेणेकरून त्यानुसार, एकसमानता येईल.

समस्या तेव्हा येते जेव्हा तुमच्याकडे इतके पर्यावरण व्हेरिएबल्स असतात की तुम्ही फक्त डिप्लॉयमेंट उघडता - आणि पर्यावरण व्हेरिएबल्सच्या पाचशे ओळी असतात. या प्रकरणात, तुमच्याकडे फक्त पर्यावरणीय चलने वाढलेली आहेत - आणि तुम्हाला यापुढे स्वत: ला छळण्याची गरज नाही. या प्रकरणात, कॉन्फिग्स वापरणे सुरू करणे अर्थपूर्ण होईल. म्हणजेच, कॉन्फिगन्स वापरण्यासाठी तुमच्या अॅप्लिकेशनला प्रशिक्षित करा.

फक्त प्रश्न असा आहे की कॉन्फिगन्स हे तुम्हाला वाटत नाही. Config.pi हे वापरण्यास सोयीचे असलेले कॉन्फिगरेशन नाही. किंवा तुमच्या स्वतःच्या फॉरमॅटमधील काही कॉन्फिगरेशन, वैकल्पिकरित्या गिफ्टेड - हे देखील मला म्हणायचे आहे ते कॉन्फिगरेशन नाही.

मी ज्याबद्दल बोलत आहे ते स्वीकार्य स्वरूपातील कॉन्फिगरेशन आहे, म्हणजेच आतापर्यंत सर्वात लोकप्रिय मानक .yaml मानक आहे. ते कसे वाचायचे ते स्पष्ट आहे, ते मानवी वाचनीय आहे, ते अनुप्रयोगावरून कसे वाचायचे ते स्पष्ट आहे.

त्यानुसार, YAML व्यतिरिक्त, तुम्ही देखील, उदाहरणार्थ, JSON वापरू शकता, तेथून ऍप्लिकेशन कॉन्फिगरेशन वाचण्याच्या दृष्टीने पार्सिंग YAML प्रमाणेच सोयीचे आहे. लोकांना वाचणे अधिक गैरसोयीचे आहे. तुम्ही फॉरमॅट वापरून पाहू शकता, a la ini. मानवी दृष्टिकोनातून हे वाचणे खूप सोयीचे आहे, परंतु त्यावर आपोआप प्रक्रिया करणे गैरसोयीचे असू शकते, या अर्थाने की जर तुम्हाला तुमची स्वतःची कॉन्फिग्स व्युत्पन्न करायची असेल तर, ini फॉरमॅट तयार करणे आधीच गैरसोयीचे असू शकते.

परंतु कोणत्याही परिस्थितीत, आपण कोणतेही स्वरूप निवडा, मुद्दा असा आहे की कुबर्नेट्सच्या दृष्टिकोनातून ते अतिशय सोयीचे आहे. तुम्ही तुमची संपूर्ण कॉन्फिगरेशन ConfigMap मध्ये कुबर्नेट्समध्ये ठेवू शकता. आणि मग हा कॉन्फिगमॅप घ्या आणि काही विशिष्ट निर्देशिकेत तुमच्या पॉडमध्ये बसवायला सांगा, जिथे तुमचा अॅप्लिकेशन या कॉन्फिगमॅपवरील कॉन्फिगरेशन वाचेल जणू ती फाइल आहे. तुमच्या ऍप्लिकेशनमध्ये तुमच्याकडे बरेच कॉन्फिगरेशन पर्याय असतात तेव्हा हे करणे चांगले असते. किंवा ही फक्त एक प्रकारची जटिल रचना आहे, घरटे आहे.

जर तुमच्याकडे कॉन्फिगमॅप असेल, तर तुम्ही तुमचा अॅप्लिकेशन खूप चांगल्या प्रकारे शिकवू शकता, उदाहरणार्थ, कॉन्फिगमॅप माउंट केलेल्या फाइलमधील बदलांचा स्वयंचलितपणे मागोवा घेण्यासाठी आणि कॉन्फिगरेशन बदलल्यावर तुमचा अॅप्लिकेशन स्वयंचलितपणे रीलोड करा. हा साधारणपणे एक आदर्श पर्याय असेल.

पुन्हा, मी याबद्दल आधीच बोललो आहे - गुप्त माहिती कॉन्फिगमॅपमध्ये नाही, गुप्त माहिती व्हेरिएबल्समध्ये नाही, गुप्त माहिती गुपितांमध्ये नाही. तिथून ही गुप्त माहिती मुत्सद्देगिरीशी जोडा. सहसा आम्ही कुबर्नेट्स ऑब्जेक्ट्स, डिप्लॉयमेंट्स, कॉन्फिगमॅप्स, सर्व्हिसेसचे सर्व वर्णन गिटमध्ये संग्रहित करतो. त्यानुसार, git मधील डेटाबेसमध्ये पासवर्ड टाकणे, जरी ते तुमचे git असले तरीही, जे तुमच्याकडे कंपनीमध्ये आहे, ही एक वाईट कल्पना आहे. कारण, कमीतकमी, git सर्वकाही लक्षात ठेवते आणि तेथून पासवर्ड काढून टाकणे इतके सोपे नाही.

आरोग्य तपासणी

पुढचा मुद्दा म्हणजे आरोग्य तपासणी. सर्वसाधारणपणे, आरोग्य तपासणी म्हणजे तुमचा अर्ज कार्यरत आहे की नाही हे तपासणे. त्याच वेळी, आम्ही बर्‍याचदा विशिष्ट वेब अनुप्रयोगांबद्दल बोलत असतो, ज्यासाठी, त्यानुसार, आरोग्य तपासणीच्या दृष्टिकोनातून (येथे आणि पुढे भाषांतर न करणे चांगले आहे) ही काही खास URL असेल, ज्यावर ते प्रक्रिया करतात. एक मानक, ते सहसा करतात /health.

या URL मध्ये प्रवेश करताना, त्यानुसार, आमचा अनुप्रयोग एकतर "होय, ठीक आहे, माझ्याबरोबर सर्वकाही ठीक आहे, 200" किंवा "नाही, माझ्याबरोबर सर्व काही ठीक नाही, काही 500" असे म्हणतात. त्यानुसार, जर आमचा ऍप्लिकेशन http नसेल, वेब ऍप्लिकेशन नसेल, तर आम्ही आता काही प्रकारच्या डिमनबद्दल बोलत आहोत, आम्ही आरोग्य तपासणी कशी करावी हे शोधू शकतो. म्हणजेच, हे आवश्यक नाही, जर अनुप्रयोग http नसेल, तर सर्व काही आरोग्य तपासणीशिवाय कार्य करते आणि हे कोणत्याही प्रकारे केले जाऊ शकत नाही. तुम्ही फाईलमधील काही माहिती अधूनमधून अपडेट करू शकता, तुम्ही तुमच्या डिमनसाठी काही खास कमांड घेऊन येऊ शकता, जसे की, daemon status, जे म्हणेल "होय, सर्व काही ठीक आहे, डिमन कार्यरत आहे, तो जिवंत आहे."

ते कशासाठी आहे? प्रथम आणि सर्वात स्पष्ट गोष्ट म्हणजे आरोग्य तपासणी का आवश्यक आहे - अनुप्रयोग कार्य करत आहे हे समजण्यासाठी. म्हणजे, हे फक्त मूर्खपणाचे आहे, जेव्हा ते आता चालू आहे, असे दिसते की ते कार्य करत आहे, म्हणून आपण खात्री बाळगू शकता की ते कार्य करत आहे. आणि असे दिसून आले की अनुप्रयोग चालू आहे, कंटेनर चालू आहे, उदाहरण कार्य करत आहे, सर्व काही ठीक आहे - आणि नंतर वापरकर्त्यांनी आधीच तांत्रिक समर्थनातून सर्व फोन नंबर कापले आहेत आणि म्हणतात “तू काय आहेस..., तू झोपी गेलो, काहीही काम करत नाही.”

आरोग्य तपासणी हा वापरकर्त्याच्या दृष्टिकोनातून पाहण्याचा एक मार्ग आहे की ते कार्य करते. पद्धतींपैकी एक. चला हे असे ठेवूया. Kubernetes च्या दृष्टिकोनातून, अनुप्रयोग केव्हा सुरू होतो हे समजून घेण्याचा हा एक मार्ग आहे, कारण आम्हाला समजते की कंटेनर कधी लॉन्च केला गेला, तयार केला गेला आणि सुरू झाला आणि अनुप्रयोग थेट या कंटेनरमध्ये कधी लॉन्च केला गेला यात फरक आहे. कारण जर आपण काही सरासरी जावा ऍप्लिकेशन घेतले आणि ते डॉकमध्ये सुरू करण्याचा प्रयत्न केला, तर चाळीस सेकंद, किंवा अगदी एक मिनिट, किंवा अगदी दहा, ते अगदी चांगले सुरू होऊ शकते. या प्रकरणात, आपण कमीतकमी त्याच्या पोर्टवर ठोठावू शकता, ते तेथे उत्तर देणार नाही, म्हणजेच ते अद्याप रहदारी प्राप्त करण्यास तयार नाही.

पुन्हा, आरोग्य तपासणीच्या मदतीने आणि आम्ही येथे वळत आहोत या वस्तुस्थितीच्या मदतीने, आम्ही कुबर्नेट्समध्ये समजू शकतो की अनुप्रयोगात केवळ कंटेनरच वाढला नाही तर अनुप्रयोग स्वतःच सुरू झाला आहे, तो आधीच प्रतिसाद देतो. आरोग्य तपासणी, याचा अर्थ आम्ही तेथे रहदारी पाठवू शकतो.

मी आता ज्याबद्दल बोलत आहे त्याला Kubernetes मधील रेडीनेस/लाइव्हनेस चाचण्या म्हणतात; त्यानुसार, आमच्या तयारी चाचण्या या ऍप्लिकेशनच्या बॅलन्सिंगच्या उपलब्धतेसाठी जबाबदार आहेत. म्हणजेच, जर ऍप्लिकेशनमध्ये तत्परता चाचण्या केल्या गेल्या असतील तर सर्व काही ठीक आहे, क्लायंट रहदारी ऍप्लिकेशनवर जात आहे. जर तत्परता चाचण्या केल्या गेल्या नाहीत, तर अनुप्रयोग फक्त भाग घेत नाही, हे विशिष्ट उदाहरण संतुलनात भाग घेत नाही, ते संतुलनातून काढून टाकले जाते, क्लायंट रहदारी प्रवाहित होत नाही. त्यानुसार, Kubernetes मध्ये लाइव्हनेस चाचण्या आवश्यक आहेत जेणेकरून ऍप्लिकेशन अडकल्यास, ते पुन्हा सुरू करता येईल. Kubernetes मध्ये घोषित केलेल्या ऍप्लिकेशनसाठी लाइव्हनेस टेस्ट काम करत नसल्यास, ऍप्लिकेशन फक्त बॅलन्सिंगमधून काढून टाकले जात नाही, ते पुन्हा सुरू केले जाते.

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

म्हणजेच तुमचा अर्ज, जेव्हा एखादी विनंती येते /health, तो फक्त प्रतिसाद देत नाही, “200, ok”, तो प्रथम जातो, उदाहरणार्थ, डेटाबेसला, त्याच्याशी कनेक्ट करण्याचा प्रयत्न करतो, तेथे काहीतरी मूलभूत करतो, जसे की एक निवडा, फक्त तपासते की तेथे कनेक्शन आहे डेटाबेस आणि आपण डेटाबेस क्वेरी करू शकता. जर हे सर्व यशस्वी झाले, तर उत्तर "200, ठीक आहे." जर ते यशस्वी झाले नाही, तर ते म्हणतात की एक त्रुटी आहे, डेटाबेस अनुपलब्ध आहे.

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

जर आम्ही लाइव्हनेस टेस्ट घोषित केली असेल, तर कल्पना करा, आमचा डेटाबेस तुटला आहे आणि तुमच्या कुबर्नेट्समध्ये अर्ध्या गोष्टी रीस्टार्ट होऊ लागतात कारण लिव्हनेस टेस्ट अयशस्वी होते. याचा अर्थ तुम्हाला रीस्टार्ट करणे आवश्यक आहे. हे तुम्हाला हवे आहे असे अजिबात नाही, मला सरावाचा वैयक्तिक अनुभव देखील होता. आमच्याकडे एक चॅट ऍप्लिकेशन आहे जे जेएसमध्ये लिहिलेले होते आणि मोंगो डेटाबेसमध्ये दिले गेले होते. आणि समस्या अशी होती की कुबरनेटसह माझ्या कामाच्या सुरूवातीस, आम्ही कुबर्नेट्स हे करू शकतो या तत्त्वावर चाचणीची तयारी, जिवंतपणा वर्णन केले, म्हणून आम्ही ते वापरू. त्यानुसार, काही क्षणी मोंगो थोडा "निस्तेज" झाला आणि नमुना अयशस्वी होऊ लागला. त्यानुसार, पावसाच्या चाचणीनुसार, शेंगा "मारायला" लागल्या.

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

जर ही सजीवता चाचणी जाहीर केली नसती, जी हे सर्व पुन्हा सुरू करण्यास भाग पाडते, तर अनुप्रयोगाने ते अगदी चांगले हाताळले असते. परंतु समतोल राखण्यापासून सर्वकाही आमच्यासाठी अक्षम केले आहे, कारण डेटाबेस दुर्गम आहेत आणि सर्व वापरकर्ते "पडले" आहेत. त्यानंतर, जेव्हा हा डेटाबेस उपलब्ध होतो, तेव्हा सर्व काही बॅलन्सिंगमध्ये समाविष्ट केले जाते, परंतु अनुप्रयोगांना पुन्हा सुरू करण्याची आवश्यकता नाही आणि यासाठी वेळ आणि संसाधने वाया घालवण्याची गरज नाही. ते सर्व आधीच येथे आहेत, ते रहदारीसाठी तयार आहेत, म्हणून रहदारी उघडते, सर्व काही ठीक आहे - अनुप्रयोग ठिकाणी आहे, सर्वकाही कार्य करत आहे.

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

कारण जिवंतपणाची चाचणी, मोठ्या प्रमाणावर, जेव्हा आपण “अडकलो” असतो. एक अंतहीन लूप सुरू झाला आहे किंवा आणखी काही - आणि आणखी विनंत्यांवर प्रक्रिया केली जात नाही. म्हणून, त्यांना वेगळे करणे - आणि त्यांच्यामध्ये भिन्न तर्क लागू करणे अर्थपूर्ण आहे.

तुमची चाचणी झाल्यावर, तुम्ही आरोग्य तपासणी करता तेव्हा तुम्हाला काय उत्तर द्यावे लागेल याविषयी. हे फक्त खरोखर एक वेदना आहे. ज्यांना हे माहित आहे ते कदाचित हसतील - परंतु गंभीरपणे, मी माझ्या आयुष्यात अशा सेवा पाहिल्या आहेत ज्या 200% प्रकरणांमध्ये "XNUMX" उत्तर देतात. म्हणजेच कोण यशस्वी आहे. परंतु त्याच वेळी प्रतिसादाच्या मुख्य भागामध्ये ते "अशी आणि अशी त्रुटी" लिहितात.

म्हणजेच, प्रतिसाद स्थिती तुमच्याकडे येते - सर्वकाही यशस्वी होते. परंतु त्याच वेळी, आपण शरीराचे विश्लेषण करणे आवश्यक आहे, कारण शरीर म्हणते "माफ करा, विनंती त्रुटीसह संपली" आणि हे फक्त वास्तव आहे. हे मी प्रत्यक्ष आयुष्यात पाहिलं.

आणि म्हणून काही लोकांना ते मजेदार वाटत नाही आणि इतरांना ते खूप वेदनादायक वाटतात, तरीही एका साध्या नियमाचे पालन करणे योग्य आहे. आरोग्य तपासणीमध्ये, आणि तत्त्वतः वेब अनुप्रयोगांसह कार्य करताना.

जर सर्व काही ठीक झाले असेल, तर दोनशेव्या उत्तरासह प्रतिसाद द्या. तत्वतः, कोणतेही दोन-शतवा उत्तर आपल्यास अनुकूल असेल. जर तुम्ही रॅग्सी चांगलं वाचलं असेल आणि तुम्हाला माहीत असेल की काही प्रतिसाद स्थिती इतरांपेक्षा वेगळ्या आहेत, तर योग्य उत्तरे द्या: 204, 5, 10, 15, काहीही असो. जर ते फार चांगले नसेल, तर फक्त "दोन शून्य शून्य." जर सर्व काही बिघडले आणि आरोग्य तपासणीला प्रतिसाद मिळाला नाही तर कोणत्याही पाचशेवा उत्तर द्या. पुन्हा, तुम्हाला प्रतिसाद कसा द्यायचा हे समजल्यास, वेगवेगळ्या प्रतिसाद स्थिती एकमेकांपेक्षा किती भिन्न आहेत. तुम्हाला समजत नसेल, तर काही चूक झाल्यास आरोग्य तपासणीला प्रतिसाद देण्याचा तुमचा पर्याय ५०२ आहे.

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

म्हणून, मी हे पुन्हा पुन्हा सांगू इच्छितो की तुम्हाला अंतर्निहित सेवा तपासण्याची आवश्यकता आहे, ज्याशिवाय तुमचा अर्ज शंभर टक्के प्रकरणांमध्ये त्याचे कार्य करू शकत नाही. म्हणजेच, हे तार्किक आहे की जर तुमच्याकडे REST API असेल ज्याद्वारे वापरकर्ता डेटाबेसमध्ये जतन करतो किंवा डेटाबेसमधून पुनर्प्राप्त करतो, तर डेटाबेस नसताना, तुम्ही तुमच्या वापरकर्त्यांसोबत काम करण्याची हमी देऊ शकत नाही.

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

पुढे, ऍप्लिकेशन्स लॉन्च करताना आमच्याकडे एक वेदनादायक समस्या देखील आहे.

खरं तर, हे केवळ कुबर्नेट्सलाच लागू होत नाही; हे असेच घडले की काही प्रकारच्या मोठ्या प्रमाणात विकासाची संस्कृती आणि विशेषतः DevOps कुबर्नेट्स सारख्याच काळात पसरू लागली. म्हणून, मोठ्या प्रमाणावर, असे दिसून आले आहे की आपल्याला कुबर्नेट्सशिवाय आपला अनुप्रयोग कृपापूर्वक बंद करणे आवश्यक आहे. कुबर्नेट्सच्या आधीही, लोकांनी हे केले होते, परंतु कुबर्नेट्सच्या आगमनाने आम्ही त्याबद्दल मोठ्या प्रमाणावर बोलू लागलो.

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

सर्वसाधारणपणे, ग्रेसफुल शटडाउन म्हणजे काय आणि त्याची आवश्यकता का आहे? जेव्हा तुमचा अनुप्रयोग काही कारणास्तव क्रॅश होतो तेव्हा तुम्हाला हे करण्याची आवश्यकता असते app stop - किंवा तुम्हाला, उदाहरणार्थ, ऑपरेटिंग सिस्टमकडून सिग्नल प्राप्त झाला, तुमच्या अनुप्रयोगाने ते समजून घेतले पाहिजे आणि त्याबद्दल काहीतरी केले पाहिजे. सर्वात वाईट परिस्थिती, अर्थातच, जेव्हा तुमच्या अर्जाला SIGTERM प्राप्त होतो आणि "SIGTERM, चला थांबूया, काम करूया, काहीही करू नका." हा एक पूर्णपणे वाईट पर्याय आहे.

एक जवळजवळ तितकाच वाईट पर्याय आहे जेव्हा तुमच्या अर्जाला SIGTERM प्राप्त होतो आणि "ते segterm म्हणाले, याचा अर्थ आम्ही संपत आहोत, मी पाहिले नाही, मला कोणत्याही वापरकर्त्याच्या विनंत्या माहित नाहीत, मला माहित नाही की कोणत्या प्रकारच्या मी सध्या ज्या विनंत्यांवर काम करत आहे, ते म्हणाले SIGTERM, याचा अर्थ आम्ही संपत आहोत " हा देखील एक वाईट पर्याय आहे.

कोणता पर्याय चांगला आहे? पहिला मुद्दा म्हणजे ऑपरेशन्स पूर्ण करणे विचारात घेणे. तुमच्या सर्व्हरला SIGTERM मिळाल्यास तो काय करतो याचा विचार करणे हा एक चांगला पर्याय आहे.

SIGTERM हे एक सॉफ्ट शटडाउन आहे, ते खास डिझाइन केलेले आहे, ते कोड स्तरावर रोखले जाऊ शकते, त्यावर प्रक्रिया केली जाऊ शकते, म्हणा की आता थांबा, आम्ही आधी आमच्याकडे असलेले काम पूर्ण करू, नंतर आम्ही बाहेर पडू.

कुबर्नेट्सच्या दृष्टीकोनातून, हे असे दिसते. जेव्हा आम्ही कुबर्नेट्स क्लस्टरमध्ये चालू असलेल्या पॉडला म्हणतो, “कृपया थांबा, निघून जा,” किंवा आम्ही रीस्टार्ट होतो किंवा कुबर्नेट्स पॉड्स पुन्हा तयार करतो तेव्हा अपडेट येतो, कुबर्नेट्स पॉडला तोच SIGTERM संदेश पाठवतो, त्याची वाट पाहतो. काही वेळ, आणि , हीच वेळ आहे ज्याची तो वाट पाहत आहे, हे देखील कॉन्फिगर केले आहे, डिप्लोमामध्ये असे एक विशेष पॅरामीटर आहे आणि त्याला ग्रेसफुल शटडाउनटाइमआउट म्हणतात. तुम्ही समजता त्याप्रमाणे, याला विनाकारण असे म्हटले जात नाही आणि आम्ही आता त्याबद्दल बोलत आहोत.

तेथे आम्ही विशेषपणे सांगू शकतो की आम्ही अर्जावर SIGTERM पाठवण्याच्या कालावधी दरम्यान आम्हाला किती वेळ प्रतीक्षा करावी लागेल आणि जेव्हा आम्हाला समजेल की अनुप्रयोग एखाद्या गोष्टीसाठी वेडा झाला आहे किंवा "अडकला" आहे आणि तो संपणार नाही - आणि आम्हाला त्याला SIGKILL पाठवा, म्हणजेच त्याचे काम कठोरपणे पूर्ण करा. म्हणजेच, त्यानुसार, आमच्याकडे एक प्रकारचा डिमन चालू आहे, तो ऑपरेशन्सवर प्रक्रिया करतो. आम्‍ही समजतो की आमच्‍या ऑपरेशन्स ज्‍यावर डिमन कार्य करते ते एका वेळी 30 सेकंदांपेक्षा जास्त काळ टिकत नाही. त्यानुसार, SIGTERM आल्यावर, आम्हाला समजते की आमचा डिमन, जास्तीत जास्त SIGTERM नंतर 30 सेकंद पूर्ण करू शकतो. आम्ही ते लिहू, उदाहरणार्थ, 45 सेकंद फक्त बाबतीत आणि म्हणतो की SIGTERM. त्यानंतर आम्ही 45 सेकंद थांबतो. सैद्धांतिकदृष्ट्या, या काळात राक्षसाने त्याचे कार्य पूर्ण केले पाहिजे आणि स्वतःला संपवले पाहिजे. पण जर अचानक ते शक्य झाले नाही, तर याचा अर्थ बहुधा ते अडकले आहे—ते यापुढे आमच्या विनंत्यांवर सामान्यपणे प्रक्रिया करत नाही. आणि 45 सेकंदात तुम्ही सुरक्षितपणे, खरं तर, त्याला खाली खिळू शकता.

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

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

आणि शेवटचा पर्याय. जेव्हा तुमचा वापरकर्ता विनंती पाठवतो आणि तुम्ही त्यावर प्रक्रिया करत असताना अर्धा तास थांबतो तेव्हा ते वाईट असते. परंतु सर्वसाधारणपणे, क्लायंटच्या बाजूने सामान्यत: काय फायदेशीर आहे याबद्दल देखील मला सांगायचे आहे. तुमच्याकडे मोबाईल ऍप्लिकेशन, फ्रंट-एंड इत्यादी असल्यास काही फरक पडत नाही. हे लक्षात घेणे आवश्यक आहे की सर्वसाधारणपणे वापरकर्त्याचे सत्र समाप्त केले जाऊ शकते, काहीही होऊ शकते. विनंती पाठवली जाऊ शकते, उदाहरणार्थ, प्रक्रिया कमी झाली आणि कोणताही प्रतिसाद परत आला नाही. तुमचा फ्रंटएंड किंवा तुमचा मोबाईल ऍप्लिकेशन - सर्वसाधारणपणे कोणताही फ्रंटएंड, तो तसा ठेवूया - हे लक्षात घेतले पाहिजे. जर तुम्ही वेबसॉकेट्ससह काम करत असाल तर, हे साधारणपणे मला झालेली सर्वात वाईट वेदना आहे.

जेव्हा काही नियमित चॅटच्या विकसकांना हे माहित नसते, तेव्हा असे दिसून येते की वेबसॉकेट खंडित होऊ शकते. त्यांच्यासाठी, जेव्हा प्रॉक्सीमध्ये काहीतरी घडते, तेव्हा आम्ही फक्त कॉन्फिगरेशन बदलतो आणि ते रीलोड होते. स्वाभाविकच, या प्रकरणात सर्व दीर्घकालीन सत्र फाटलेले आहेत. डेव्हलपर धावत आमच्याकडे येतात आणि म्हणतात: "मित्रांनो, तुम्ही काय करत आहात, आमच्या सर्व क्लायंटसाठी गप्पा तुटल्या आहेत!" आम्ही त्यांना सांगतो: “तुम्ही काय करत आहात? तुमचे क्लायंट पुन्हा कनेक्ट करण्यात अक्षम आहेत? ते म्हणतात: "नाही, आम्हाला सत्रे फाटण्याची गरज नाही." थोडक्यात, हे खरोखर मूर्खपणा आहे. ग्राहकाची बाजू विचारात घेणे आवश्यक आहे. विशेषत:, जसे मी म्हणतो, वेबसॉकेट्स सारख्या दीर्घकालीन सत्रांसह, ते खंडित होऊ शकते आणि वापरकर्त्याच्या लक्षात न आल्याने, आपल्याला अशी सत्रे पुन्हा स्थापित करण्यास सक्षम असणे आवश्यक आहे. आणि मग सर्वकाही परिपूर्ण आहे.

संसाधने

खरं तर, इथे मी तुम्हाला एक सरळ गोष्ट सांगेन. पुन्हा खऱ्या आयुष्यातून. संसाधनांबद्दल मी कधीही ऐकलेली सर्वात आजारी गोष्ट.

या प्रकरणात संसाधने, म्हणजे, काही प्रकारच्या विनंत्या, मर्यादा ज्या तुम्ही तुमच्या कुबर्नेट्स क्लस्टर्समध्ये पॉड्सवर ठेवू शकता. मी विकसकाकडून ऐकलेली सर्वात मजेदार गोष्ट... पूर्वीच्या कामाच्या ठिकाणी माझ्या सहकारी विकासकांपैकी एकाने एकदा म्हटले: "माझा अर्ज क्लस्टरमध्ये सुरू होणार नाही." मी पाहिलं की ते सुरू होत नाहीये, पण एकतर ते संसाधनांमध्ये बसत नाही किंवा त्यांनी खूप लहान मर्यादा सेट केल्या आहेत. थोडक्यात, संसाधनांमुळे अनुप्रयोग सुरू होऊ शकत नाही. मी म्हणतो: "हे संसाधनांमुळे सुरू होणार नाही, तुम्हाला किती आवश्यक आहे ते तुम्ही ठरवा आणि पुरेसे मूल्य सेट करा." तो म्हणतो: "कोणत्या प्रकारची संसाधने?" मी त्याला समजावून सांगू लागलो की कुबर्नेट्स, विनंत्यांची मर्यादा आणि ब्ला, ब्ला, ब्ला सेट करणे आवश्यक आहे. त्या माणसाने पाच मिनिटे ऐकले, होकार दिला आणि म्हणाला: “मी येथे विकासक म्हणून काम करण्यासाठी आलो आहे, मला कोणत्याही संसाधनांबद्दल काहीही जाणून घ्यायचे नाही. मी इथे कोड लिहायला आलो आहे आणि तेच आहे.” हे दुःखदायक आहे. विकासकाच्या दृष्टिकोनातून ही अतिशय दुःखद संकल्पना आहे. विशेषत: आधुनिक जगात, पुरोगामी देवोपांचं.

संसाधनांची अजिबात गरज का आहे? कुबर्नेट्समध्ये 2 प्रकारची संसाधने आहेत. काहींना विनंत्या म्हणतात, तर काहींना मर्यादा म्हणतात. संसाधनांद्वारे आपण समजू शकतो की मुळात नेहमीच फक्त दोन मूलभूत निर्बंध असतात. म्हणजेच, कुबरनेटमध्ये चालणाऱ्या कंटेनरसाठी CPU वेळ मर्यादा आणि RAM मर्यादा.

तुमच्‍या अॅप्लिकेशनमध्‍ये संसाधन कसे वापरले जाऊ शकते यावर मर्यादा एक वरची मर्यादा ठेवते. म्हणजेच, त्यानुसार, जर तुम्ही मर्यादेत 1GB RAM म्हटल्यास, तुमचा अनुप्रयोग 1GB पेक्षा जास्त रॅम वापरू शकणार नाही. आणि जर त्याला अचानक हे हवे असेल आणि ते करण्याचा प्रयत्न केला, तर ओम किलर नावाची प्रक्रिया, मेमरीबाहेर, म्हणजे, येऊन तुमचा अनुप्रयोग नष्ट करेल - म्हणजेच ती पुन्हा सुरू होईल. CPU वर आधारित अनुप्रयोग रीस्टार्ट होणार नाहीत. CPU च्या संदर्भात, जर अनुप्रयोगाने मर्यादेत निर्दिष्ट केलेल्या पेक्षा जास्त वापरण्याचा प्रयत्न केला, तर CPU फक्त काटेकोरपणे निवडला जाईल. यामुळे रीस्टार्ट होत नाही. ही मर्यादा आहे - ही वरची मर्यादा आहे.

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

विनंत्या का आवश्यक आहेत आणि विनंत्यांशिवाय का, मला वाटते की कुबर्नेट्समध्ये काहीही लॉन्च करण्याची आवश्यकता नाही? काल्पनिक परिस्थितीची कल्पना करूया. तुम्ही तुमचा अॅप्लिकेशन विनंत्यांशिवाय लाँच करता, तुमच्याकडे किती आहे, कोणत्या नोड्सवर तुम्ही ते पुश करू शकता हे कुबर्नेट्सला माहीत नाही. बरं, तो नोड्सवर ढकलतो, फावतो, हलवतो. काही क्षणी, तुम्हाला तुमच्या अर्जावर रहदारी मिळणे सुरू होईल. आणि एक ऍप्लिकेशन अचानक त्याच्या मर्यादेनुसार असलेल्या मर्यादेपर्यंत संसाधने वापरण्यास सुरुवात करते. असे दिसून आले की जवळपास दुसरा अनुप्रयोग आहे आणि त्याला संसाधनांची देखील आवश्यकता आहे. नोड प्रत्यक्षात भौतिकरित्या संसाधने संपू लागतो, उदाहरणार्थ, ओपी. नोड प्रत्यक्षात भौतिकरित्या संसाधने संपुष्टात येऊ लागते, उदाहरणार्थ, यादृच्छिक प्रवेश मेमरी (RAM). जेव्हा नोडची शक्ती संपते, तेव्हा सर्व प्रथम डॉकर प्रतिसाद देणे थांबवेल, नंतर क्यूबलेट, नंतर OS. ते फक्त बेशुद्ध होतील आणि सर्व काही निश्चितपणे तुमच्यासाठी कार्य करणे थांबवेल. म्हणजेच, यामुळे तुमचा नोड अडकेल आणि तुम्हाला तो रीस्टार्ट करावा लागेल. थोडक्यात, परिस्थिती फारशी चांगली नाही.

आणि जेव्हा तुमच्याकडे विनंत्या असतात, तेव्हा मर्यादा फार वेगळ्या नसतात, किमान मर्यादेपेक्षा किंवा विनंत्यांपेक्षा कितीतरी पटीने जास्त नसतात, तेव्हा तुमच्याकडे कुबर्नेट्स क्लस्टर्सच्या नोड्समध्ये अनुप्रयोगांची अशी सामान्य, तर्कसंगत भरण असू शकते. त्याच वेळी, कुबर्नेट्सला अंदाजे माहित आहे की ते कुठे काय ठेवते, किती वापरले जाते. म्हणजेच, हा फक्त एक क्षण आहे. ते समजून घेणे महत्त्वाचे आहे. आणि हे सूचित केले आहे हे नियंत्रित करणे महत्वाचे आहे.

डेटा संचयन

आमचा पुढचा मुद्दा डेटा स्टोरेजबद्दल आहे. त्यांच्याशी काय करावे आणि सर्वसाधारणपणे, कुबर्नेट्समध्ये चिकाटीने काय करावे?

मला वाटतं, पुन्हा, आमच्या आत संध्याकाळची शाळा, Kubernetes मध्ये डेटाबेस बद्दल एक विषय होता. आणि मला असे वाटते की तुमच्या सहकार्‍यांनी तुम्हाला विचारले असता काय सांगितले हे मला अगदी अंदाजे माहीत आहे: "कुबर्नेट्समध्ये डेटाबेस चालवणे शक्य आहे का?" काही कारणास्तव, मला असे वाटते की तुमच्या सहकाऱ्यांनी तुम्हाला सांगितले असावे की जर तुम्ही प्रश्न विचारत असाल की कुबेरनेट्समध्ये डेटाबेस चालवणे शक्य आहे, तर ते अशक्य आहे.

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

आमचा ऍप्लिकेशन संचयित करू इच्छित असलेला डेटा, वापरकर्ते अपलोड केलेली काही चित्रे, आमच्या ऍप्लिकेशनच्या ऑपरेशन दरम्यान, स्टार्टअपच्या वेळी तयार केलेल्या काही गोष्टी, उदाहरणार्थ, आम्ही काय करावे? कुबर्नेट्समध्ये त्यांच्याशी काय करावे?

सर्वसाधारणपणे, आदर्शपणे, होय, अर्थातच, कुबर्नेट्स अतिशय चांगल्या प्रकारे डिझाइन केलेले आहेत आणि सामान्यत: सुरुवातीला स्टेटलेस ऍप्लिकेशन्ससाठी कल्पना केली गेली होती. म्हणजेच, त्या अनुप्रयोगांसाठी जे माहिती अजिबात साठवत नाहीत. हे आदर्श आहे.

परंतु, अर्थातच, आदर्श पर्याय नेहमीच अस्तित्वात नसतो. तर काय? पहिला आणि सर्वात सोपा मुद्दा म्हणजे काही प्रकारचा S3 घेणे, केवळ घरगुती नाही, जे ते कसे कार्य करते हे देखील स्पष्ट नाही, परंतु काही प्रदात्याकडून. एक चांगला, सामान्य प्रदाता - आणि तुमचा अनुप्रयोग S3 वापरण्यास शिकवा. म्हणजेच, जेव्हा तुमचा वापरकर्ता फाइल अपलोड करू इच्छितो तेव्हा म्हणा “येथे, कृपया, ती S3 वर अपलोड करा.” जेव्हा त्याला ते मिळवायचे असेल, तेव्हा म्हणा: "हा S3 ची परत लिंक आहे आणि येथून घ्या." हे आदर्श आहे.

जर अचानक काही कारणास्तव हा आदर्श पर्याय योग्य नसेल, तर तुमच्याकडे एखादा अनुप्रयोग आहे जो तुम्ही लिहिला नाही, तुम्ही विकसित होत नाही किंवा हा एक प्रकारचा भयंकर वारसा आहे, तो S3 प्रोटोकॉल वापरू शकत नाही, परंतु स्थानिक निर्देशिकांसह कार्य करणे आवश्यक आहे. स्थानिक फोल्डर्स. अधिक किंवा कमी सोपे काहीतरी घ्या, Kubernetes तैनात करा. म्हणजेच, काही किमान कामांसाठी सेफला ताबडतोब कुंपण घालणे, मला वाटते, ही एक वाईट कल्पना आहे. कारण Ceph अर्थातच चांगला आणि फॅशनेबल आहे. परंतु आपण काय करत आहात हे आपल्याला खरोखरच समजत नसल्यास, एकदा आपण Ceph वर काहीतरी ठेवले की, आपण तेथून पुन्हा कधीही बाहेर पडू शकता. कारण, तुम्हाला माहिती आहे की, Ceph त्याच्या क्लस्टरमध्ये बायनरी स्वरूपात डेटा साठवते, साध्या फाइल्सच्या स्वरूपात नाही. म्हणून, जर अचानक सेफ क्लस्टर तुटला, तर तुम्हाला तेथून तुमचा डेटा पुन्हा कधीही मिळणार नाही अशी पूर्ण आणि उच्च संभाव्यता आहे.

आम्ही Ceph वर एक कोर्स करू, तुम्ही करू शकता कार्यक्रमाशी परिचित व्हा आणि अर्ज सबमिट करा.

म्हणून, NFS सर्व्हरसारखे काहीतरी सोपे करणे चांगले आहे. Kubernetes त्यांच्यासोबत कार्य करू शकतात, तुम्ही NFS सर्व्हर अंतर्गत निर्देशिका माउंट करू शकता - तुमचा अनुप्रयोग स्थानिक निर्देशिकेसारखा आहे. त्याच वेळी, नैसर्गिकरित्या, आपल्याला हे समजून घेणे आवश्यक आहे की, पुन्हा, आपल्याला आपल्या NFS सह काहीतरी करण्याची आवश्यकता आहे, आपल्याला हे समजून घेणे आवश्यक आहे की काहीवेळा ते दुर्गम होऊ शकते आणि या प्रकरणात आपण काय कराल या प्रश्नाचा विचार करा. कदाचित वेगळ्या मशीनवर कुठेतरी त्याचा बॅकअप घ्यावा.

तुमच्या ऍप्लिकेशनने ऑपरेशन दरम्यान काही फाइल्स व्युत्पन्न केल्यास काय करावे याबद्दल मी बोललो पुढचा मुद्दा. उदाहरणार्थ, जेव्हा ते सुरू होते, तेव्हा ते काही स्थिर फाइल व्युत्पन्न करते, जी काही माहितीवर आधारित असते जी केवळ लॉन्चच्या वेळी अनुप्रयोगास प्राप्त होते. काय एक क्षण. जर असा जास्त डेटा नसेल, तर तुम्हाला अजिबात त्रास करण्याची गरज नाही, फक्त स्वतःसाठी हा अनुप्रयोग स्थापित करा आणि कार्य करा. इथे फक्त प्रश्न आहे काय, बघा. बर्‍याचदा, सर्व प्रकारच्या लीगेसी सिस्टीम, जसे की वर्डप्रेस आणि याप्रमाणे, विशेषत: सुधारित काही प्रकारच्या चतुर प्लगइनसह, हुशार PHP विकासक, त्यांना ते कसे बनवायचे हे माहित असते जेणेकरून ते स्वतःसाठी काही प्रकारची फाइल तयार करतात. त्यानुसार, एक फाईल जनरेट करते, दुसरी दुसरी फाइल तयार करते. ते वेगळे आहेत. क्लायंटच्या कुबर्नेट्स क्लस्टरमध्ये फक्त योगायोगाने बॅलन्सिंग होते. त्यानुसार, असे दिसून आले की त्यांना एकत्रितपणे कसे कार्य करावे हे माहित नाही. एक एक माहिती देतो, दुसरा वापरकर्त्याला दुसरी माहिती देतो. ही गोष्ट तुम्ही टाळली पाहिजे. म्हणजेच, Kubernetes मध्ये, तुम्ही लाँच करता त्या प्रत्येक गोष्टीची हमी अनेक उदाहरणांमध्ये कार्य करण्यास सक्षम असेल. कारण कुबर्नेट्स ही एक चालणारी गोष्ट आहे. त्यानुसार, तो कोणालाही न विचारता, त्याला पाहिजे तेव्हा काहीही हलवू शकतो. म्हणून, आपण यावर अवलंबून असणे आवश्यक आहे. एका प्रसंगात लॉन्च केलेली प्रत्येक गोष्ट लवकरच किंवा नंतर अयशस्वी होईल. तुमच्याकडे जितके जास्त आरक्षण असेल तितके चांगले. पण पुन्हा, मी म्हणतो, जर तुमच्याकडे अशा काही फाईल्स असतील तर तुम्ही त्या तुमच्या खाली ठेवू शकता, त्यांचे वजन कमी आहे. त्यापैकी थोडे अधिक असल्यास, आपण कदाचित त्यांना कंटेनरमध्ये ढकलू नये.

मी सल्ला देतो की कुबर्नेट्समध्ये अशी एक अद्भुत गोष्ट आहे, आपण व्हॉल्यूम वापरू शकता. विशेषतः, रिक्त दिर प्रकाराचा एक खंड आहे. म्हणजेच, कुबर्नेट्स तुम्ही ज्या सर्व्हरवर सुरुवात केली त्या सर्व्हर डिरेक्टरीमध्ये आपोआप एक निर्देशिका तयार करेल. आणि तो तुम्हाला देईल जेणेकरून तुम्ही ते वापरू शकाल. फक्त एक महत्त्वाचा मुद्दा आहे. म्हणजेच, तुमचा डेटा कंटेनरमध्ये संग्रहित केला जाणार नाही, तर तुम्ही ज्या होस्टवर चालत आहात त्या होस्टवर. शिवाय, Kubernetes सामान्य कॉन्फिगरेशन अंतर्गत अशा रिकाम्या dirs नियंत्रित करू शकतात आणि त्यांचा कमाल आकार नियंत्रित करू शकतात आणि ते ओलांडू देत नाहीत. मुद्दा एवढाच आहे की तुम्ही रिकाम्या दिरात जे लिहिले आहे ते पॉड रीस्टार्ट करताना गमावले जात नाही. म्हणजे चुकून तुमची पॉड पडली आणि पुन्हा उठली तर रिकाम्या दिरातील माहिती कुठेही जाणार नाही. तो ते पुन्हा एका नवीन सुरुवातीस वापरू शकतो - आणि ते चांगले आहे. जर तुमची पॉड कुठेतरी सोडली तर नैसर्गिकरित्या तो डेटाशिवाय निघून जाईल. म्हणजेच, रिकाम्या डिरसह लॉन्च केलेल्या नोडमधील पॉड गायब होताच, रिक्त दिर हटविला जातो.

रिकाम्या दिरांमध्ये आणखी काय चांगले आहे? उदाहरणार्थ, ते कॅशे म्हणून वापरले जाऊ शकते. चला कल्पना करूया की आमचा ऍप्लिकेशन फ्लायवर काहीतरी तयार करतो, वापरकर्त्यांना देतो आणि ते बर्याच काळासाठी करतो. म्हणून, ॲप्लिकेशन, उदाहरणार्थ, व्युत्पन्न करते आणि वापरकर्त्यांना देते, आणि त्याच वेळी ते कुठेतरी साठवते, जेणेकरुन पुढच्या वेळी वापरकर्ता त्याच गोष्टीसाठी येतो तेव्हा ते त्वरित जनरेट केलेले देणे जलद होईल. मेमरीमध्ये तयार करण्यासाठी रिकामे दिर कुबरनेटेसला सांगितले जाऊ शकते. आणि अशा प्रकारे, तुमचे कॅशे सामान्यतः विजेच्या वेगाने कार्य करू शकतात - डिस्क ऍक्सेस गतीच्या दृष्टीने. म्हणजेच, तुमच्याकडे मेमरीमध्ये रिक्त डिर आहे, OS मध्ये ते मेमरीमध्ये संग्रहित आहे, परंतु तुमच्यासाठी, पॉडमधील वापरकर्त्यासाठी, ते फक्त स्थानिक निर्देशिकेसारखे दिसते. तुम्हाला विशेषत: कोणतीही जादू शिकवण्यासाठी अॅपची आवश्यकता नाही. तुम्ही तुमची फाईल थेट एका डिरेक्टरीमध्ये घ्या आणि ठेवता, परंतु, खरं तर, OS वर मेमरीमध्ये. कुबर्नेट्सच्या दृष्टीने हे देखील एक अतिशय सोयीचे वैशिष्ट्य आहे.

Minio ला कोणत्या समस्या आहेत? Minio ची मुख्य समस्या अशी आहे की ही गोष्ट कार्य करण्यासाठी, ती कुठेतरी कार्यरत असणे आवश्यक आहे, आणि तेथे काही प्रकारची फाइल सिस्टम असणे आवश्यक आहे, म्हणजेच स्टोरेज. आणि येथे आपल्याला सेफच्या समान समस्या येतात. म्हणजेच, Minio त्याच्या फायली कुठेतरी संग्रहित केल्या पाहिजेत. हा फक्त तुमच्या फाइल्सचा HTTP इंटरफेस आहे. शिवाय, कार्यक्षमता Amazon च्या S3 पेक्षा स्पष्टपणे गरीब आहे. पूर्वी, ते वापरकर्त्यास योग्यरित्या अधिकृत करण्यास सक्षम नव्हते. आता, माझ्या माहितीनुसार, ते आधीपासूनच वेगवेगळ्या अधिकृततेसह बादल्या तयार करू शकते, परंतु पुन्हा, मला असे दिसते की मुख्य समस्या म्हणजे, कमीत कमी अंतर्निहित स्टोरेज सिस्टम आहे.

मेमरीमधील रिक्त दिर मर्यादांवर कसा परिणाम करते? कोणत्याही प्रकारे मर्यादा प्रभावित करत नाही. ते होस्टच्या स्मृतीत असते, तुमच्या कंटेनरच्या स्मरणात नाही. म्हणजेच, आपल्या कंटेनरला त्याच्या व्यापलेल्या मेमरीचा भाग म्हणून मेमरीमधील रिक्त दिर दिसत नाही. यजमान हे पाहतो. त्यानुसार, होय, कुबर्नेट्सच्या दृष्टिकोनातून, जेव्हा तुम्ही हे वापरण्यास सुरुवात करता, तेव्हा हे समजून घेणे चांगले होईल की तुम्ही तुमच्या स्मरणशक्तीचा काही भाग रिकाम्या दिरासाठी समर्पित करत आहात. आणि त्यानुसार, हे समजून घ्या की मेमरी केवळ अनुप्रयोगांमुळेच संपुष्टात येऊ शकत नाही, तर कोणीतरी या रिक्त दिरांना लिहिते म्हणून देखील.

ढगाळपणा

आणि अंतिम उपविषय Cloudnative काय आहे. त्याची गरज का आहे? Cloudnativeness आणि त्यामुळे वर.

म्हणजेच, आधुनिक क्लाउड इन्फ्रास्ट्रक्चरमध्ये कार्य करण्यासाठी सक्षम आणि लिखित अनुप्रयोग. पण, खरं तर, क्लाउडनेटिव्हला असा आणखी एक पैलू आहे. हे केवळ आधुनिक क्लाउड इन्फ्रास्ट्रक्चरच्या सर्व गरजा लक्षात घेणारा अनुप्रयोग नाही, तर या आधुनिक क्लाउड इन्फ्रास्ट्रक्चरसह कसे कार्य करावे हे देखील माहित आहे, या क्लाउडमध्ये कार्य करते याचे फायदे आणि तोटे यांचा फायदा घ्या. फक्त ओव्हरबोर्डवर जाऊन ढगांमध्ये काम करू नका, तर क्लाउडमध्ये काम करण्याच्या फायद्यांचा फायदा घ्या.

कुबर्नेट्सचे उदाहरण घेऊ. तुमचा अर्ज Kubernetes मध्ये चालू आहे. तुमचा ॲप्लिकेशन नेहमी, किंवा त्याऐवजी तुमच्या ऍप्लिकेशनचे प्रशासक नेहमी सेवा खाते तयार करू शकतात. म्हणजेच, त्याच्या सर्व्हरमध्ये कुबर्नेट्समध्येच अधिकृततेसाठी खाते. आम्हाला तेथे आवश्यक असलेले काही अधिकार जोडा. आणि तुम्ही तुमच्या ऍप्लिकेशनमधून कुबर्नेट्समध्ये प्रवेश करू शकता. तुम्ही अशा प्रकारे काय करू शकता? उदाहरणार्थ, अॅप्लिकेशनमधून, तुमचे इतर अॅप्लिकेशन्स, इतर तत्सम उदाहरणे कोठे आहेत याबद्दल डेटा मिळवा आणि अशी गरज असल्यास, कुबर्नेट्सच्या शीर्षस्थानी एकत्रितपणे क्लस्टर करा.

पुन्हा, आम्ही अक्षरशः अलीकडे एक केस होते. आमच्याकडे एक नियंत्रक आहे जो रांगेचे निरीक्षण करतो. आणि जेव्हा या रांगेत काही नवीन कार्ये दिसतात, तेव्हा ते कुबर्नेट्सकडे जाते - आणि कुबर्नेट्सच्या आत ते एक नवीन पॉड तयार करते. या पॉडला काही नवीन कार्य देते आणि या पॉडच्या चौकटीत, पॉड कार्य करते, कंट्रोलरला स्वतः प्रतिसाद पाठवते आणि नंतर कंट्रोलर या माहितीसह काहीतरी करतो. उदाहरणार्थ, ते डेटाबेस जोडते. म्हणजेच, पुन्हा, आमचा अनुप्रयोग कुबर्नेट्समध्ये चालतो या वस्तुस्थितीचा हा एक प्लस आहे. आमच्या ऍप्लिकेशनची कार्यक्षमता अधिक सोयीस्कर बनवण्यासाठी आम्ही अंगभूत कुबर्नेट्स कार्यक्षमतेचा वापर करू शकतो. म्हणजेच, अॅप्लिकेशन कसे लॉन्च करायचे, कार्यकर्ता कसा लॉन्च करायचा याबद्दल काही प्रकारचे जादू लपवू नका. Kubernetes मध्ये, जर अनुप्रयोग Python मध्ये लिहिलेला असेल तर तुम्ही फक्त अॅपमध्ये विनंती पाठवता.

जर आपण कुबर्नेट्सच्या पलीकडे गेलो तर तेच लागू होते. आमच्याकडे आमचे कुबर्नेट्स कुठेतरी धावत आहेत - जर ते एखाद्या प्रकारच्या ढगात असेल तर ते चांगले आहे. पुन्हा, आपण जिथे धावत आहोत त्या क्लाउडच्या क्षमतांचा वापर करू शकतो, आणि मला विश्वास आहे की, वापरायलाही पाहिजे. मेघ आपल्याला पुरवत असलेल्या प्राथमिक गोष्टींमधून. बॅलन्सिंग, म्हणजेच आपण क्लाउड बॅलन्सर्स तयार करून त्यांचा वापर करू शकतो. आपण काय वापरू शकतो याचा हा थेट फायदा आहे. कारण क्लाउड बॅलन्सिंग, प्रथम, ते कसे कार्य करते, ते कसे कॉन्फिगर केले जाते याची जबाबदारी मूर्खपणाने काढून टाकते. शिवाय हे खूप सोयीचे आहे, कारण नियमित कुबर्नेट्स ढगांशी समाकलित होऊ शकतात.

स्केलिंगसाठीही तेच आहे. नियमित कुबर्नेट्स क्लाउड प्रदात्यांसह समाकलित होऊ शकतात. जर क्लस्टर नोड्स संपले, म्हणजे नोडची जागा संपली, तर तुम्हाला जोडणे आवश्यक आहे हे कसे समजून घ्यावे हे माहित आहे - कुबर्नेट्स स्वतःच तुमच्या क्लस्टरमध्ये नवीन नोड्स जोडेल आणि त्यावर पॉड लाँच करणे सुरू करेल. म्हणजेच जेव्हा तुमचा भार येतो तेव्हा चूलांची संख्या वाढू लागते. जेव्हा या पॉड्ससाठी क्लस्टरमधील नोड्स संपतात, तेव्हा कुबर्नेट्स नवीन नोड्स लाँच करते आणि त्यानुसार, पॉड्सची संख्या अजूनही वाढू शकते. आणि ते खूप सोयीस्कर आहे. फ्लायवर क्लस्टर स्केल करण्याची ही थेट संधी आहे. फार वेगवान नाही, या अर्थाने की ते एक सेकंद नाही, नवीन नोड जोडण्यासाठी ते एका मिनिटासारखे आहे.

पण माझ्या अनुभवावरून, पुन्हा, मी पाहिलेली ही सर्वात छान गोष्ट आहे. जेव्हा क्लाउडनेटिव्ह क्लस्टर दिवसाच्या वेळेनुसार मोजला जातो. ही बॅकएंड सेवा होती जी बॅक ऑफिसमधील लोक वापरत असत. म्हणजेच, ते सकाळी ९ वाजता कामावर येतात, सिस्टीममध्ये लॉग इन करण्यास सुरुवात करतात आणि त्यानुसार, क्लाउडनेटिव्ह क्लस्टर, जिथे हे सर्व चालू आहे, फुगण्यास सुरुवात होते, नवीन पॉड्स लाँच करतात जेणेकरून कामावर येणारा प्रत्येकजण अनुप्रयोगासह कार्य करू शकेल. जेव्हा ते रात्री 9 किंवा 8 वाजता काम सोडतात, तेव्हा कुबर्नेट्स क्लस्टर्सना लक्षात येते की यापुढे कोणीही ऍप्लिकेशन वापरत नाही आणि ते कमी होऊ लागतात. 6 टक्क्यांपर्यंत बचतीची हमी आहे. त्या वेळी ते Amazon मध्ये काम करत होते; त्या वेळी रशियामध्ये असे कोणीही नव्हते जे ते इतके चांगले करू शकेल.

मी तुम्हाला सरळ सांगेन, बचत 30 टक्के आहे कारण आम्ही कुबर्नेट्स वापरतो आणि क्लाउडच्या क्षमतांचा फायदा घेतो. आता हे रशियामध्ये केले जाऊ शकते. मी अर्थातच कोणासाठीही जाहिरात करणार नाही, परंतु असे म्हणूया की असे प्रदाते आहेत जे हे करू शकतात, ते बॉक्सच्या बाहेर बटणासह प्रदान करतात.

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

आणि हेच तुम्हाला, सर्वप्रथम, तुमच्या पायाभूत सुविधांवर नेहमी नियंत्रण ठेवण्याची, ती कोणत्या स्थितीत आहे हे नेहमी समजून घेण्याची परवानगी देते. दुसरे म्हणजे, मॅन्युअल ऑपरेशन टाळा ज्यामुळे त्रुटी निर्माण होतात. तिसरे, ज्याला टर्नओव्हर म्हणतात ते टाळा, जेव्हा तुम्हाला सतत समान मॅन्युअल कार्ये करण्याची आवश्यकता असते. चौथे, अयशस्वी झाल्यास ते आपल्याला अधिक जलद पुनर्प्राप्त करण्यास अनुमती देते. रशियामध्ये, प्रत्येक वेळी मी याबद्दल बोलतो तेव्हा असे लोक नेहमी मोठ्या संख्येने असतात जे म्हणतात: "हो, हे स्पष्ट आहे, परंतु आपल्याकडे दृष्टिकोन आहेत, थोडक्यात, काहीही निराकरण करण्याची आवश्यकता नाही." पण ते खरे आहे. तुमच्या इन्फ्रास्ट्रक्चरमध्ये काही बिघडले असेल, तर क्लाउडनेटिव्ह दृष्टिकोनाच्या दृष्टिकोनातून आणि इन्फ्रास्ट्रक्चरच्या दृष्टिकोनातून कोड म्हणून, ते दुरुस्त करण्याऐवजी, सर्व्हरवर जाऊन, काय बिघडले आहे ते शोधून काढणे आणि निराकरण करणे सोपे आहे. सर्व्हर हटवण्यासाठी आणि पुन्हा तयार करण्यासाठी. आणि मी हे सर्व पुनर्संचयित करीन.

या सर्व मुद्द्यांवर अधिक तपशीलवार चर्चा केली आहे कुबर्नेट्स व्हिडिओ कोर्स: ज्युनियर, बेसिक, मेगा. दुव्याचे अनुसरण करून आपण प्रोग्राम आणि अटींशी परिचित होऊ शकता. सोयीस्कर गोष्ट अशी आहे की तुम्ही घरून अभ्यास करून किंवा दिवसातून 1-2 तास काम करून कुबर्नेट्समध्ये प्रभुत्व मिळवू शकता.

स्त्रोत: www.habr.com