केटी स्कुटरमा। दृष्टान्त freepik, घुमन्ते लोगो बाट HashiCorp

Kubernetes कन्टेनर आर्केस्ट्रा को 300-पाउंड गोरिल्ला हो। यसले विश्वको सबैभन्दा ठूलो कन्टेनर प्रणालीहरूमा काम गर्दछ, तर महँगो छ।

साना टोलीहरूका लागि विशेष रूपमा महँगो, जसलाई धेरै समर्थन समय र एक ठाडो सिकाइ वक्र आवश्यक पर्दछ। यो हाम्रो चार जनाको टोलीको लागि धेरै ओभरहेड हो। त्यसैले हामीले विकल्प खोज्न थाल्यौं - र प्रेममा पर्यौं Nomad.

तपाई के चाहनुहुन्छ

हाम्रो टोलीले धेरै सामान्य कार्यसम्पादन अनुगमन र विश्लेषण सेवाहरूलाई समर्थन गर्दछ: Go मा लेखिएका मेट्रिक्सका लागि API अन्त्य बिन्दुहरू, Prometheus निर्यातहरू, लग पार्सरहरू जस्तै Logstash र Gollum, साथै डाटाबेसहरू जस्तै InfluxDB वा Elasticsearch। यी प्रत्येक सेवाहरू आफ्नै कन्टेनरमा चल्छन्। हामीलाई यो सबै चलाउनको लागि एक सरल प्रणाली चाहिन्छ।

हामीले कन्टेनर अर्केस्ट्रेसनको लागि आवश्यकताहरूको सूचीको साथ सुरु गर्यौं:

• धेरै मेसिनहरूमा सेवाहरूको सेट चलाउँदै।
• चलिरहेको सेवाहरूको अवलोकन।
• सेवाहरू बीच लिङ्कहरू।
• यदि सेवा तल जान्छ भने स्वचालित पुन: सुरु गर्नुहोस्।
• सानो टोलीद्वारा पूर्वाधार मर्मतसम्भार।

थप रूपमा, निम्न चीजहरू राम्रो हुनेछ, तर आवश्यक थपिने छैन:

• ट्याग गर्ने मेसिनहरू तिनीहरूको क्षमताहरूमा आधारित छन् (उदाहरणका लागि, भारी I/O सेवाहरूको लागि द्रुत डिस्कहरू भएका मेसिनहरू ट्याग गर्ने)।
• अर्केस्ट्रेटरबाट स्वतन्त्र रूपमा सेवाहरू चलाउने क्षमता (उदाहरणका लागि, विकासको क्रममा)।
• कन्फिगरेसन र गोप्य साझा गर्न साझा ठाउँ।
• मेट्रिक्स र लगहरूको लागि अन्तिम बिन्दु।

किन Kubernetes हाम्रो लागि सही छैन

हामीले Kubernetes सँग प्रोटोटाइप गर्दा, हामीले ध्यान दियौं कि हामीले तर्कको बढ्दो जटिल तहहरू थप्दैछौं जसमा हामी धेरै निर्भर छौं।

उदाहरणको रूपमा, Kubernetes ले बिल्ट-इन सेवा कन्फिगरेसनहरू मार्फत समर्थन गर्दछ कन्फिगम्याप्स। विशेष गरी धेरै कन्फिगरेसन फाइलहरू मर्ज गर्दा वा पोडमा थप सेवाहरू थप्दा तपाईं चाँडै अलमलमा पर्न सक्नुहुन्छ। Kubernetes (वा हेलम यस अवस्थामा) ले तपाईंलाई चासोहरू अलग गर्न बाह्य कन्फिगरेसनहरू गतिशील रूपमा लागू गर्न अनुमति दिन्छ। तर यसले तपाईंको परियोजना र कुबर्नेट्स बीचको कडा, लुकेको युग्मनमा परिणाम दिन्छ। यद्यपि, Helm र ConfigMaps अतिरिक्त विकल्पहरू हुन्, त्यसैले तपाईंले तिनीहरूलाई प्रयोग गर्नुपर्दैन। तपाईं केवल डकर छविमा कन्फिगरेसन प्रतिलिपि गर्न सक्नुहुन्छ। जे होस्, यो यो बाटो तल जान र अनावश्यक अमूर्तताहरू निर्माण गर्न प्रलोभन हो जुन तपाइँ पछि पछुताउन सक्नुहुन्छ।

थप रूपमा, Kubernetes इकोसिस्टम द्रुत रूपमा विकसित हुँदैछ। उत्कृष्ट अभ्यासहरू र नवीनतम उपकरणहरूसँग अद्यावधिक रहन धेरै समय र ऊर्जा लाग्छ। Kubectl, minikube, kubeadm, हेल्म, टिलर, kops, oc - सूची जारी र जारी छ। यी सबै उपकरणहरू आवश्यक पर्दैन जब तपाइँ सुरु गर्दै हुनुहुन्छ, तर तपाइँलाई थाहा छैन तपाइँ के चाहिन्छ, त्यसैले तपाइँ सबै कुरा बारे सचेत हुन आवश्यक छ। यस कारणले गर्दा, सिकाइ वक्र धेरै ठाडो छ।

Kubernetes कहिले प्रयोग गर्ने

हाम्रो कम्पनीमा, धेरै मानिसहरू Kubernetes प्रयोग गर्छन् र यससँग धेरै खुसी छन्। यी उदाहरणहरू Google वा Amazon द्वारा व्यवस्थित छन्, जससँग तिनीहरूलाई समर्थन गर्ने स्रोतहरू छन्।

Kubernetes सँग आउँछ आश्चर्यजनक सुविधाहरू, जसले स्केलमा कन्टेनर अर्केस्ट्रेसनलाई अझ व्यवस्थित बनाउँछ:

• विस्तृत अधिकार व्यवस्थापन.
• अनुकूलन नियन्त्रकहरू क्लस्टरमा तर्क थप्नुहोस्। यी कुबेरनेट एपीआईसँग कुरा गर्ने कार्यक्रमहरू मात्र हुन्।
• स्वतः स्केलिङ! Kubernetes सेवा मेट्रिक्स प्रयोग गरेर र म्यानुअल हस्तक्षेप आवश्यक बिना माग मा सेवा मापन गर्न सक्नुहुन्छ।

प्रश्न यो हो कि तपाईलाई साँच्चै यी सबै सुविधाहरू चाहिन्छ। तपाईं केवल अमूर्तहरूमा भर पर्न सक्नुहुन्न; तपाईंले हुड मुनि के भइरहेको छ पत्ता लगाउनु पर्छ.

हाम्रो टोलीले धेरैजसो सेवाहरू टाढाबाट प्रदान गर्दछ (मुख्य पूर्वाधारसँग नजिकको जडानको कारण), त्यसैले हामीले हाम्रो आफ्नै Kubernetes क्लस्टर बढाउन चाहँदैनौं। हामी केवल सेवा प्रदान गर्न चाहन्छौं।

ब्याट्रीहरू समावेश छैनन्

घुमन्ते आर्केस्ट्राको 20% हो जसले आवश्यक पर्ने 80% प्रदान गर्दछ। यसले गर्ने सबै डिप्लोयमेन्टहरू व्यवस्थापन गर्ने हो। Nomad ले डिप्लोयमेन्टको ख्याल राख्छ, त्रुटिहरूको अवस्थामा कन्टेनरहरू पुन: सुरु गर्दछ ... र यो हो।

Nomad को सम्पूर्ण बिन्दु यो के गर्छ न्यूनतम: कुनै दानेदार अधिकार व्यवस्थापन वा विस्तारित नेटवर्क नीतिहरू, यो विशेष रूपमा डिजाइन गरिएको छ। यी कम्पोनेन्टहरू बाह्य रूपमा प्रदान गरिएका छन् वा होइनन्।

मलाई लाग्छ Nomad ले प्रयोगको सहजता र उपयोगिता बीचको उत्तम सम्झौता फेला पारेको छ। यो साना, स्वतन्त्र सेवाहरूको लागि राम्रो छ। यदि तपाईंलाई थप नियन्त्रण चाहिन्छ भने, तपाईंले तिनीहरूलाई आफैं उठाउनु पर्ने हुन्छ वा फरक दृष्टिकोण प्रयोग गर्नुपर्छ। घुमन्ते हो बस अर्केस्ट्रेटर।

Nomad को बारे मा सबै भन्दा राम्रो कुरा यो सजिलो छ बदल्नुहोस्। त्यहाँ विक्रेतासँग व्यावहारिक रूपमा कुनै जडान छैन, किनकि यसको कार्यहरू सजिलैसँग सेवाहरू व्यवस्थापन गर्ने कुनै पनि अन्य प्रणालीमा एकीकृत हुन्छन्। यो क्लस्टरमा हरेक मेसिनमा नियमित बाइनरी जस्तै चल्छ, यति मात्र!

ढिलो जोडिएको कम्पोनेन्टको घुमन्ते इकोसिस्टम

घुमन्तेको वास्तविक शक्ति यसको इकोसिस्टम हो। यो अन्य - पूर्ण रूपमा वैकल्पिक - उत्पादनहरू जस्तै धेरै राम्रोसँग एकीकृत हुन्छ कन्सुलर (कुञ्जी-मूल्य स्टोर) वा वाल्ट (गोप्य प्रशोधन)। 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 कन्सुलबाट र यसलाई सञ्चालनको क्रममा वातावरणीय चरमा उजागर गर्नुहोस् LOG_LEVEL। हामी चाबी पनि प्रस्तुत गर्दछौं secret/geo-api-key को रूपमा भल्ट बाट API_KEY। सरल तर शक्तिशाली!

यसको सरलताको कारण, Nomad एपीआई मार्फत अन्य सेवाहरूसँग सजिलै विस्तार गर्न सकिन्छ। उदाहरणका लागि, कार्यहरूको लागि ट्यागहरू समर्थित छन्। हामी मेट्रिक्सको साथ सबै सेवाहरू ट्याग गर्छौं trv-metrics। यस तरीकाले प्रोमेथियसले कन्सुल मार्फत यी सेवाहरू सजिलै फेला पार्न सक्छन् र आवधिक रूपमा अन्तिम बिन्दु जाँच गर्न सक्छन् /metrics नयाँ डाटाको लागि। उही गर्न सकिन्छ, उदाहरण को लागी, लग को लागी, प्रयोग गरेर लोकी.

एक्स्टेन्सिबिलिटीका धेरै अन्य उदाहरणहरू छन्:

• हुक प्रयोग गरेर जेनकिन्सको काम चलाउनुहोस्, र सेवा कन्फिगरेसन परिवर्तन हुँदा कन्सुलले Nomad कामको पुन: प्रयोगको निगरानी गर्दछ।
• Ceph ले Nomad मा वितरित फाइल प्रणाली थप्छ।
• fabio लोड सन्तुलनको लागि।

यो सबै अनुमति दिन्छ जैविक रूपमा पूर्वाधार विकास विक्रेतासँग कुनै विशेष जडान बिना।

उचित चेतावनी

कुनै पनि प्रणाली पूर्ण हुँदैन। म तुरुन्तै उत्पादनमा नयाँ सुविधाहरू प्रस्तुत गर्न सिफारिस गर्दिन। निस्सन्देह त्यहाँ बगहरू र हराइरहेको सुविधाहरू छन्, तर उही Kubernetes मा लागू हुन्छ।

कुबेरनेटको तुलनामा घुमन्ते समुदाय त्यति ठूलो छैन। Kubernetes सँग पहिले नै लगभग 75 कमिट र 000 योगदानकर्ताहरू छन्, जबकि Nomad सँग लगभग 2000 कमिट र 14 योगदानकर्ताहरू छन्। घुमन्तेलाई Kubernetes को गति संग राख्न कठिन समय हुनेछ, तर सायद यो आवश्यक छैन! यो एक अधिक विशेष प्रणाली हो, र सानो समुदाय को मतलब यो पनि हो कि तपाइँको पुल अनुरोध कुबेरनेटको तुलनामा ध्यान दिइने र स्वीकृत हुने सम्भावना बढी छ।

सारांश

तल्लो रेखा: कुबेरनेटहरू प्रयोग नगर्नुहोस् किनभने अरू सबैले यो गरिरहेका छन्। आफ्नो आवश्यकताहरू सावधानीपूर्वक मूल्याङ्कन गर्नुहोस् र कुन उपकरण बढी लाभदायक छ जाँच गर्नुहोस्।

यदि तपाइँ ठूला-ठूला पूर्वाधारहरूमा एक टन एकसमान सेवाहरू तैनाथ गर्ने योजना बनाउनुहुन्छ भने, कुबर्नेट्स एक राम्रो विकल्प हो। थप जटिलता र सञ्चालन लागत बारे मात्र सचेत रहनुहोस्। केही लागतहरू व्यवस्थित Kubernetes वातावरण प्रयोग गरेर जोगिन सकिन्छ जस्तै गुगल कुबर्नेट इञ्जिन वा अमेजन EKS.

यदि तपाइँ भरपर्दो अर्केस्ट्रेटरको खोजी गर्दै हुनुहुन्छ जुन मर्मत गर्न सजिलो र विस्तार गर्न सकिन्छ, किन Nomad प्रयास नगर्ने? तपाईं आश्चर्यचकित हुन सक्नुहुन्छ कि यसले तपाईंलाई कति टाढा लैजान्छ।

यदि Kubernetes को कार संग तुलना गरिन्छ, Nomad एक स्कूटर हुनेछ। कहिले एउटा कुरा चाहिन्छ त कहिले अर्को चाहिन्छ । दुवैको अस्तित्वको अधिकार छ।

स्रोत: www.habr.com