स्कूटरवर मुलगी. चित्रण फ्रीपिक, पासून भटक्या लोगो हॅशिकॉर्प

कुबर्नेट्स हा कंटेनर ऑर्केस्ट्रेशनचा 300-पाऊंड गोरिला आहे. हे जगातील काही सर्वात मोठ्या कंटेनर सिस्टममध्ये कार्य करते, परंतु ते महाग आहे.

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

तुम्हाला काय हवे आहे

आमचा कार्यसंघ अनेक सामान्य कार्यप्रदर्शन निरीक्षण आणि विश्लेषण सेवांना समर्थन देतो: Go मध्ये लिहिलेल्या मेट्रिक्ससाठी API एंडपॉइंट्स, Prometheus एक्सपोर्ट्स, लॉग पार्सर जसे की Logstash आणि गॉलम, तसेच डेटाबेस जसे की InfluxDB किंवा Elasticsearch. यापैकी प्रत्येक सेवा स्वतःच्या कंटेनरमध्ये चालते. हे सर्व चालू ठेवण्यासाठी आम्हाला एक साधी प्रणाली आवश्यक आहे.

आम्ही कंटेनर ऑर्केस्ट्रेशनच्या आवश्यकतांच्या सूचीसह सुरुवात केली:

• अनेक मशीनवर सेवांचा संच चालवणे.
• चालू सेवांचे विहंगावलोकन.
• सेवांमधील दुवे.
• सेवा कमी झाल्यास स्वयंचलित रीस्टार्ट.
• एका लहान टीमद्वारे पायाभूत सुविधांची देखभाल.

याव्यतिरिक्त, खालील गोष्टी छान असतील, परंतु जोडणे आवश्यक नाही:

• त्यांच्या क्षमतेवर आधारित मशीन टॅग करणे (उदाहरणार्थ, हेवी I/O सेवांसाठी वेगवान डिस्कसह मशीन टॅग करणे).
• ऑर्केस्ट्रेटरपासून स्वतंत्रपणे सेवा चालविण्याची क्षमता (उदाहरणार्थ, विकासादरम्यान).
• कॉन्फिगरेशन आणि गुपिते सामायिक करण्यासाठी एक सामान्य ठिकाण.
• मेट्रिक्स आणि लॉगसाठी एंडपॉइंट.

Kubernetes आमच्यासाठी योग्य का नाही

आम्ही Kubernetes सह प्रोटोटाइप करत असताना, आमच्या लक्षात आले की आम्ही तर्कशास्त्राचे अधिकाधिक जटिल स्तर जोडत आहोत ज्यावर आम्ही खूप अवलंबून आहोत.

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

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

Kubernetes कधी वापरावे

आमच्या कंपनीत, बरेच लोक कुबर्नेट्स वापरतात आणि त्याबद्दल खूप आनंदी आहेत. ही उदाहरणे Google किंवा Amazon द्वारे व्यवस्थापित केली जातात, ज्यांच्याकडे त्यांचे समर्थन करण्यासाठी संसाधने आहेत.

Kubernetes सोबत येतो आश्चर्यकारक वैशिष्ट्ये, जे मोठ्या प्रमाणावर कंटेनर ऑर्केस्ट्रेशन अधिक आटोपशीर बनवते:

• तपशीलवार अधिकार व्यवस्थापन.
• सानुकूल नियंत्रक क्लस्टरमध्ये तर्क जोडा. हे फक्त प्रोग्राम आहेत जे कुबर्नेट्स API शी बोलतात.
• ऑटोस्केलिंग! Kubernetes सेवा मेट्रिक्स वापरून आणि मॅन्युअल हस्तक्षेप न करता मागणीनुसार सेवा मोजू शकतात.

आपल्याला या सर्व वैशिष्ट्यांची खरोखर गरज आहे का हा प्रश्न आहे. आपण केवळ अमूर्ततेवर अवलंबून राहू शकत नाही; तुम्हाला हुड अंतर्गत काय चालले आहे ते शोधणे आवश्यक आहे.

आमचा कार्यसंघ दूरस्थपणे (मुख्य पायाभूत सुविधांशी जवळच्या कनेक्शनमुळे) बर्‍याच सेवा प्रदान करतो, म्हणून आम्हाला आमचा स्वतःचा कुबर्नेट्स क्लस्टर वाढवायचा नव्हता. आम्हाला फक्त सेवा द्यायची होती.

बॅटरी समाविष्ट नाहीत

भटक्या हे 20% ऑर्केस्ट्रेशन आहे जे आवश्यक असलेल्या 80% पुरवते. ते फक्त तैनाती व्यवस्थापित करते. नोमॅड डिप्लॉयमेंटची काळजी घेतो, त्रुटी आढळल्यास कंटेनर रीस्टार्ट करतो... आणि तेच.

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

मला वाटते की नोमॅडला वापरातील सुलभता आणि उपयुक्तता यांच्यात योग्य तडजोड आढळली आहे. हे लहान, स्वतंत्र सेवांसाठी चांगले आहे. तुम्हाला अधिक नियंत्रण हवे असल्यास, तुम्हाला ते स्वतः वाढवावे लागतील किंवा वेगळा दृष्टिकोन वापरावा लागेल. भटक्या आहेत फक्त वाद्यवृंद

Nomad बद्दल सर्वात चांगली गोष्ट म्हणजे ते सोपे आहे पुनर्स्थित करा. विक्रेत्याशी व्यावहारिकरित्या कोणतेही कनेक्शन नाही, कारण त्याची कार्ये सेवा व्यवस्थापित करणार्‍या इतर कोणत्याही प्रणालीमध्ये सहजपणे समाकलित केली जातात. हे क्लस्टरमधील प्रत्येक मशीनवर नेहमीच्या बायनरीसारखे चालते, इतकेच!

सैलपणे जोडलेल्या घटकांची भटक्या इकोसिस्टम

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

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

येथे आपण की वाचतो service/geo-api/log-verbosity Consul कडून आणि काम करत असताना आम्ही ते एका पर्यावरणीय व्हेरिएबलमध्ये उघड करतो LOG_LEVEL. आम्ही किल्ली देखील सादर करतो secret/geo-api-key वॉल्ट कडून म्हणून API_KEY. साधे पण शक्तिशाली!

त्याच्या साधेपणामुळे, Nomad हे API द्वारे इतर सेवांसह सहज विस्तारण्यायोग्य आहे. उदाहरणार्थ, कार्यांसाठी टॅग समर्थित आहेत. आम्ही सर्व सेवांना मेट्रिक्ससह टॅग करतो trv-metrics. अशा प्रकारे प्रोमिथियस या सेवा कॉन्सुलद्वारे सहजपणे शोधू शकतात आणि वेळोवेळी एंडपॉइंट तपासू शकतात /metrics नवीन डेटासाठी. हेच केले जाऊ शकते, उदाहरणार्थ, लॉगसाठी, वापरून लोकी.

विस्तारिततेची इतर अनेक उदाहरणे आहेत:

• हुक वापरून जेनकिन्स जॉब चालवा आणि सेवा कॉन्फिगरेशन बदलल्यावर कॉन्सुल नोमॅड जॉबच्या पुनर्नियोजनावर लक्ष ठेवतो.
• Ceph नोमॅडमध्ये वितरित फाइल सिस्टम जोडते.
• फॅबिओ भार संतुलनासाठी.

हे सर्व परवानगी देते सेंद्रियपणे पायाभूत सुविधा विकसित करा विक्रेत्याशी कोणत्याही विशेष कनेक्शनशिवाय.

वाजवी चेतावणी

कोणतीही यंत्रणा परिपूर्ण नसते. उत्पादनामध्ये नवीनतम वैशिष्ट्ये त्वरित सादर करण्याची मी शिफारस करत नाही. नक्कीच बग आणि गहाळ वैशिष्ट्ये आहेत, परंतु तेच Kubernetes ला लागू होते.

कुबेरनेटच्या तुलनेत भटक्या समाजाची संख्या फारशी नाही. Kubernetes कडे आधीच सुमारे 75 कमिट आणि 000 योगदानकर्ते आहेत, तर Nomad कडे सुमारे 2000 कमिट आणि 14 योगदानकर्ते आहेत. कुबर्नेट्सचा वेग राखणे भटक्यांना कठीण जाईल, परंतु कदाचित तसे करण्याची गरज नाही! ही एक अधिक विशेष प्रणाली आहे, आणि लहान समुदायाचा अर्थ असा आहे की कुबरनेटच्या तुलनेत तुमची पुल विनंती लक्षात येण्याची आणि स्वीकारली जाण्याची अधिक शक्यता असते.

सारांश

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

जर तुम्ही मोठ्या प्रमाणावर पायाभूत सुविधांवर टन एकसंध सेवा उपयोजित करण्याची योजना आखत असाल, तर कुबर्नेट्स हा एक चांगला पर्याय आहे. फक्त अतिरिक्त जटिलता आणि ऑपरेटिंग खर्चाची जाणीव ठेवा. व्यवस्थापित कुबर्नेट्स वातावरण वापरून काही खर्च टाळता येऊ शकतात जसे की गूगल कुबर्नेट्स इंजिन किंवा Amazon EKS.

जर तुम्ही फक्त एक विश्वासार्ह ऑर्केस्ट्रेटर शोधत असाल जो देखरेख करण्यास सोपा आणि वाढवता येईल, तर नोमॅडचा प्रयत्न का करू नये? तुम्हाला आश्चर्य वाटेल की हे तुम्हाला किती पुढे नेईल.

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

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