माइक्रोसर्विसेज के लिए इन्फ्रास्ट्रक्चर। K8s और ऑल-ऑल-ऑल

एक बार जब मैंने एशिया से यूरोप जाने के बारे में यहां पहले ही लिखा था, और अब मैं यह लिखना चाहता हूं कि मैं इस यूरोप में क्या कर रहा हूं। ऐसा एक पेशा है - DevOps , या नहीं, लेकिन ऐसा हुआ कि यह वही है जो मैं अभी कर रहा हूं। अब डॉकटर में चलने वाली हर चीज के ऑर्केस्ट्रेशन के लिए, हम एक रैंचर का उपयोग करते हैं, जिसके बारे में मैंने भी लिखा था । लेकिन फिर एक भयानक बात हुई, Rancher 2.0 बाहर आया और kubernetes (इसके बाद बस k8s) में चला गया और चूंकि k8s अब वास्तव में क्लस्टर के प्रबंधन के लिए मानक है, इसलिए ब्लैकहैक और लाइब्रेरियन के साथ फिर से पूरे बुनियादी ढांचे के निर्माण की इच्छा थी। जोड़-घटाव यह है कि कंपनी लगातार अलग-अलग देशों के और अलग-अलग परंपराओं से अलग-अलग विशेषज्ञों को काम पर रखती है, और कोई puppet लाता puppet , कोई व्यक्ति किसी भी तरह की तुलना में ansible है, और कोई आम तौर पर मानता है कि Makefile + bash हमारी सब कुछ है। इसलिए, सब कुछ कैसे काम करना चाहिए, इस बारे में कोई असमान राय नहीं है, लेकिन मैं वास्तव में चाहता हूं।

प्रौद्योगिकियों और उपकरणों का ऐसा चिड़ियाघर पहले इकट्ठा किया गया था:

इन्फ्रास्ट्रक्चर प्रबंधन

• Minikube
• RKE
• terraform
• कोप्स
• Kubespray
• Ansible

अनुप्रयोग प्रबंधन

• Kubernetes
• क्षेत्र लगानेवाला
• Kubectl
• पतवार
• Confd
• Kompose
• जेनकींस

लॉगिंग और मॉनिटरिंग

• Elasticsearch
• Kibana
• धाराप्रवाह सा
• Telegraf
• Influxdb
• Zabbix
• प्रोमेथियस
• Grafana
• Kapacitor

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

कुबेरनेट्स सब कुछ का केंद्र होगा क्योंकि अब यह वास्तव में एक समाधान है जिसमें बस विकल्प नहीं हैं, जो कि Amazon और Microsoft के सभी प्रदाताओं द्वारा mail.ru को समर्थित है। कैसे विकल्प पर विचार किया गया

• Swarm - जो कभी नहीं लिया
• Nomad - जो कि शिकारियों के लिए अजनबियों द्वारा लिखा गया लगता है
• Cattle रेंजर 1.x से इंजन है, जिस पर अब हम रहते हैं, सिद्धांत रूप में, सब कुछ ठीक है, लेकिन रैंचर ने पहले ही इसे k8 के पक्ष में छोड़ दिया है, इसलिए कोई विकास नहीं होगा।

आधारभूत संरचना का निर्माण

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

मिनिक्यूब परीक्षण के उद्देश्यों के लिए एक डेवलपर की मशीन पर क्लस्टर शुरू करने के लिए एक बढ़िया विकल्प है।

Rke - Rancher kubernetes इंजन, एक दरवाजे के रूप में सरल; क्लस्टर दिखने के लिए न्यूनतम कॉन्फिग

 nodes: - address: localhost role: [controlplane,worker,etcd] 

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

कोप्स - न केवल आपको एक क्लस्टर बनाने की अनुमति देता है, बल्कि एवर्स या गेस में पूर्व-निर्मित उदाहरण भी देता है। यह आपको टेराफॉर्म के लिए एक कॉन्फ़िगरेशन उत्पन्न करने की भी अनुमति देता है। एक दिलचस्प उपकरण, लेकिन हमने अभी तक रूट नहीं लिया है। यह पूरी तरह से terraform + rke द्वारा प्रतिस्थापित किया गया है जबकि यह सरल और अधिक लचीला है।

कुबेस्प्रय - वास्तव में, यह सिर्फ एक महत्वपूर्ण भूमिका है जो k8s क्लस्टर बनाता है, बहुत शक्तिशाली, लचीला, विन्यास योग्य है। यह व्यावहारिक रूप से k8s को तैनात करने के लिए डिफ़ॉल्ट समाधान है।

टेराफॉर्म , अर्स, एज़ुर या अन्य स्थानों के झुंड में बुनियादी ढांचे के निर्माण के लिए एक उपकरण है। लचीला, स्थिर - मैं सलाह देता हूं।

Ansible वास्तव में k8s के बारे में नहीं है, लेकिन हम इसे हर जगह और यहां भी उपयोग करते हैं: ट्वीक कॉन्फिग, सॉफ़्टवेयर इंस्टॉल / अपडेट करें, प्रमाण पत्र वितरित करें। सस्ता और खुशमिजाज।

अनुप्रयोग प्रबंधन

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

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

क्षेत्र लगानेवाला

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

कोड के रूप में सब कुछ की बहुत सही अवधारणा अब लोकप्रिय है। उदाहरण के लिए, कोड के रूप में इंफ्रास्ट्रक्चर को terraform , असेंबली के उपयोग से कार्यान्वित किया जाता है क्योंकि कोड को jenkins pipeline माध्यम से लागू किया जाता है। अब आवेदन की बारी आई है। एप्लिकेशन की स्थापना और कॉन्फ़िगरेशन को कुछ प्रकट में भी वर्णित किया जाना चाहिए और गिट में बचाया जाना चाहिए। Rancher संस्करण 1.x ने मानक docker-compose.yml उपयोग किया और सबकुछ ठीक था, लेकिन जब वे k8 में चले गए तो वे हेलमेट helm charts बदल गए। Helm , मेरे दृष्टिकोण से, अजीब तर्क और वास्तुकला के साथ एक बिल्कुल भयानक साझाकरण है। यह उन परियोजनाओं में से एक है जहां से यह भावना बनी हुई है कि यह अजनबियों या इसके विपरीत के लिए शिकारियों द्वारा लिखा गया था। केवल समस्या यह है कि k8s पतवार की दुनिया में बस कोई विकल्प नहीं है और यह वास्तविक मानक है। इसलिए, हम रोने के लिए चुभेंगे, लेकिन पतवार का उपयोग करना जारी रखेंगे। संस्करण 3.x में, डेवलपर्स इसे खरोंच से फिर से लिखने का वादा करते हैं, इसमें से सभी विषमताओं को फेंकते हैं और वास्तुकला को सरल करते हैं। यह तो है कि हम ठीक कर देंगे, लेकिन अब हम वही खाएंगे जो है।

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

निगरानी

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

Grafana

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

धाराप्रवाह-बिट

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

प्रोमेथियस

एक निगरानी प्रणाली जिसे विशेष रूप से माइक्रोसैस आर्किटेक्चर के लिए लिखा गया है। उद्योग में वास्तविक मानक, इसके अलावा, Prometheus Operator नामक एक परियोजना भी है, जिसे विशेष रूप से k8 के लिए लिखा गया है। हर कोई फैसला करता है कि क्या चुनना है, लेकिन नंगे प्रोमेथियस के साथ शुरू करना बेहतर है, बस अपने काम के तर्क को समझने के लिए, यह सामान्य प्रणालियों से काफी अलग है। हमें node-exporter भी उल्लेख करने की आवश्यकता है जो आपको मशीन स्तर के मैट्रिक्स और प्रोमेथियस-रंचर-निर्यातक को इकट्ठा करने की अनुमति देता है जो आपको रैंचर एपी के माध्यम से मैट्रिक्स इकट्ठा करने की अनुमति देता है। सामान्य तौर पर, यदि आपके पास कुबेरनेट पर एक क्लस्टर है, तो प्रोमेथियस एक होना चाहिए।

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

एक विकल्प के रूप में, आप TIG (telegraf + influxdb + grafana) उपयोग कर सकते हैं TIG (telegraf + influxdb + grafana) कॉन्फ़िगर करना आसान है, यह स्थिर रूप से काम करता है, यह आपको कंटेनर, एप्लिकेशन, नोड आदि द्वारा मेट्रिक्स को एकत्रित करने की अनुमति देता है, लेकिन अनिवार्य रूप से प्रोमेथियस कार्यक्षमता को डुप्लिकेट करता है, और केवल एक ही होना चाहिए।

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

और आप आदर्श बुनियादी ढांचे को कैसे देखते हैं?
यदि आपकी राय है, तो कृपया टिप्पणियों में लिखें, या शायद हमारी टीम में भी शामिल हों और इसे एक साथ रखने में मदद करें।