टी एल; डॉ

हम क्यूब्सप्राय, कुबेदम और किसी भी अन्य जैसे स्वचालन उपकरण का उपयोग किए बिना, निगलना , Letencrypt के साथ स्टेटलेस वेब एप्लिकेशन परोसने के लिए क्लस्टर बढ़ाते हैं।
पढ़ने का समय: ~ 45-60 मिनट, प्लेबैक समय: 3 घंटे से।

प्रस्तावना

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

घटकों

निम्नलिखित घटक लेख में दिखाई देंगे:

- आपका पसंदीदा लिनक्स - मैंने जेंटू (नोड -1: सिस्टमड / नोड -2: ओपन आर्क), उबंटू 18.04.1 का उपयोग किया।
- कुबेरनेट्स सर्वर - क्यूब-एपेसेवर, क्यूब-कंट्रोलर-मैनेजर, क्यूब-शेड्यूलर, क्यूबलेट, क्यूब-प्रॉक्सी।
- कंटेनर + सीएनआई प्लगइन्स (0.7.4) - कंटेनरीकरण को व्यवस्थित करने के लिए, हम डॉकटर के बजाय कंटेनर + सीएनआई लेंगे (हालांकि शुरुआत में पूरे कॉन्फ़िगरेशन को डॉकटर पर अपलोड किया गया था, इसलिए कुछ भी इसे आवश्यक होने पर उपयोग करने से नहीं रोकेगा)।
- कोरडएनएस - कुबेरनेट क्लस्टर के अंदर काम करने वाले घटकों की सेवा खोज के आयोजन के लिए। 1.2.5 से कम संस्करण की सिफारिश नहीं की गई है, क्योंकि इस संस्करण के साथ क्लस्टर के बाहर चलने वाली प्रक्रिया के रूप में काम करने के लिए कोरडन्स के लिए समर्थन है।
- फलालैन - एक नेटवर्क स्टैक के आयोजन के लिए, आपस में चूल्हा और कंटेनरों का संचार करना।
- आपका पसंदीदा डी.बी.

सीमाएँ और मान्यताएँ

• लेख बाजार पर vps / vds समाधानों की लागत की जांच नहीं करता है, साथ ही इन सेवाओं पर मशीनों को तैनात करने की संभावना भी है। यह माना जाता है कि आपके पास पहले से ही कुछ विस्तारित है, या आप इसे स्वयं करने में सक्षम हैं। इसके अलावा, आपके पसंदीदा डेटाबेस और निजी डॉकर्स रिपॉजिटरी की स्थापना / कॉन्फ़िगरेशन, यदि आपको एक की आवश्यकता है, तो कवर नहीं किया गया है।
• हम दोनों कंटेनड + cni plugins और docker का उपयोग कर सकते हैं। यह लेख डॉकटर को एक कंटेनरीकरण उपकरण के रूप में उपयोग करने पर विचार नहीं करता है। यदि आप डॉकटर का उपयोग करना चाहते हैं, तो आप स्वयं के अनुसार फलालैन को कॉन्फ़िगर करने में सक्षम होंगे, इसके अलावा आपको क्यूबलेट को कॉन्फ़िगर करने की आवश्यकता होगी, अर्थात्, कंटेनर से संबंधित सभी विकल्पों को हटा दें। जैसा कि मेरे प्रयोगों ने दिखाया है, कंटेनर के रूप में विभिन्न नोड्स पर डॉकटर और कंटेनर सही ढंग से काम करेंगे।
• हम फलालैन के लिए host-gw बैकएंड का उपयोग नहीं कर सकते हैं, अधिक विवरण के लिए फलालैन कॉन्फ़िगरेशन अनुभाग पढ़ें
• हम निगरानी, ​​बैकअप, उपयोगकर्ता फ़ाइलों (स्थिति) को बचाने, कॉन्फ़िगरेशन फ़ाइलों और एप्लिकेशन कोड (git / hg / svn / etc) को संग्रहीत करने के लिए कुछ भी उपयोग नहीं करेंगे।

परिचय

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

नेटवर्क वास्तुकला समाधान

क्लस्टर बढ़ाने की प्रक्रिया में, मैंने प्रति माह $ 20 के बजट में फिट होने के लिए लोहे के संसाधनों को इस तरह से अनुकूलित करने का कार्य निर्धारित नहीं किया। कम से कम दो काम करने वाले नोड्स (नोड्स) के साथ एक कार्यशील क्लस्टर को इकट्ठा करना आवश्यक था। इसलिए, शुरू में क्लस्टर इस तरह दिखता था:

• 2 वीसीपीयू / 4 जी रैम के साथ मशीन: एपीआई-सर्वर + नोड -1 [20 $]
• 2 वीसीपीयू / 4 जी रैम के साथ मशीन: नोड -2 [$ 20]

क्लस्टर के पहले संस्करण के काम करने के बाद, मैंने इसे फिर से बनाने का फैसला किया ताकि क्लस्टर (कार्य नोड्स, वे भी श्रमिक हैं) और मास्टर सर्वर के एपीआई के भीतर चल रहे अनुप्रयोगों के लिए जिम्मेदार नोड्स के बीच अंतर कर सकें।

नतीजतन, मुझे इस सवाल का जवाब मिला: "यदि कम या ज्यादा सस्ती, लेकिन कामकाजी क्लस्टर कैसे प्राप्त करना है, अगर मैं वहां सबसे मोटे अनुप्रयोगों को नहीं रखना चाहता हूं।"

अवयव और उनका प्रदर्शन

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

तो:

• मास्टर सर्वर / सर्वर कॉन्फ़िगरेशन (मास्टर नोड्स):
  
  • अन्डर (3.2.17): 80 - 100 मीटर, मेट्रिक्स को यादृच्छिक रूप से चयनित समय पर लिया गया था। Etcd औसत मेमोरी की खपत 300M से अधिक नहीं थी;
  • क्यूब-एपेस्वर (1.12.x - 1.13.0): 237.6M ~ 300M;
  • क्यूब-कंट्रोलर-मैनेजर (1.12.x - 1.13.0): लगभग 90M, 100M से ऊपर नहीं बढ़ा;
  • क्यूब-शेड्यूलर (1.12.x - 1.13.0): लगभग 20M, 30-50M से ऊपर की खपत तय नहीं है।
• वर्कर सर्वर कॉन्फ़िगरेशन (वर्कर नोड्स):
  
  • क्यूबलेट (1.12.3 - 1.13.1): लगभग 35 एमबी, 50M से ऊपर की खपत तय नहीं है;
  • क्यूब-प्रॉक्सी (1.12.3 - 1.13.1): लगभग 7.5 - 10M;
  • फलालैन (0.10.0): लगभग 15-20 मीटर;
  • coredns (1.3.0): लगभग 25M;
  • कंटेनर (1.2.1): कंटेनर की खपत कम है, लेकिन आंकड़े भी डेमन द्वारा शुरू किए गए कंटेनर प्रक्रियाओं को दर्शाते हैं।

घर की परियोजनाओं के लिए एक परीक्षण क्लस्टर या क्लस्टर बनाने के लिए, 1vCPU / 1G RAM मास्टर नोड को कार्य करने के लिए पर्याप्त होगा। बेशक, मास्टर नोड पर लोड शामिल श्रमिकों की संख्या, साथ ही एपीआई-सर्वर के लिए तीसरे पक्ष के अनुरोधों की उपलब्धता और मात्रा के आधार पर अलग-अलग होगा।

मैंने मास्टर और वर्कर कॉन्फ़िगरेशन को निम्नानुसार विस्फोट किया:

• स्थापित घटकों के साथ 1x मास्टर: वगैरह, क्यूब-एपेस्वर, क्यूब-कंट्रोलर-मैनेजर, क्यूब-शेड्यूलर
• स्थापित घटकों के साथ 2x श्रमिक: कंटेनर, कोरडन्स, फलालैन, क्यूबलेट, क्यूब-प्रॉक्सी

विन्यास

विज़ार्ड को कॉन्फ़िगर करने के लिए, निम्नलिखित घटकों की आवश्यकता होती है:

• आदि - एपीआई-सर्वर के लिए डेटा संग्रहीत करने के लिए, साथ ही फलालैन के लिए;

  
  

• kube-apiserver - वास्तव में, एपीआई-सर्वर;

  
  

• क्यूब-नियंत्रक-प्रबंधक - घटनाओं के निर्माण और प्रसंस्करण के लिए;

  
  

• क्यूब-शेड्यूलर - एपीआई-सर्वर के माध्यम से पंजीकृत संसाधनों के वितरण के लिए - उदाहरण के लिए, चूल्हा ।
  वर्कहॉर्स के कॉन्फ़िगरेशन के लिए, निम्नलिखित घटकों की आवश्यकता होती है:

  
  

• क्यूबलेट - नेटवर्क सेटिंग्स को कॉन्फ़िगर करने के लिए चूल्हा चलाने के लिए;

  
  

• क्यूब-प्रॉक्सी - कुबेरनेट सेवाओं के मार्ग / आयोजन को व्यवस्थित करने के लिए;

  
  

• coredns - रनिंग कंटेनर के अंदर सेवा खोज के लिए;

  
  

• फलालैन - विभिन्न नोड्स पर काम कर रहे कंटेनरों के नेटवर्क एक्सेस के आयोजन के लिए, साथ ही क्लस्टर नोड्स (कुबेरनेट्स नोड) के बीच नेटवर्क के गतिशील वितरण के लिए।

  
  

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

फ़ाइलें

विज़ार्ड और कार्य नोड्स के लिए क्लस्टर घटकों के कामकाज के लिए सभी फाइलें सुविधा के लिए / var / lib / kubernetes / में रखी गई हैं। यदि आवश्यक हो, तो आप उन्हें दूसरे तरीके से रख सकते हैं।

प्रमाणपत्र

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

आप नीचे दी गई लिपियों के उपयोग से अपनी आवश्यकताओं के लिए प्रमाण पत्र तैयार कर सकते हैं, कुबेरनेट्स के व्यंजनों को कठिन तरीका या अन्य उपयुक्त उपकरण।

 $ cd certs #:   certs$ ./generate-keys.sh # ... certificate generate output #:  kubeconfig     certs$ ./generate-configkube.sh 

गुरु

मास्टर नोड पर सेवाएं शुरू करने के लिए आवश्यक प्रमाण पत्र को /var/lib/kubernetes/ : में रखा जाना चाहिए।

• ca.pem - यह प्रमाण पत्र हर जगह उपयोग किया जाता है, इसे केवल एक बार उत्पन्न किया जा सकता है और फिर बिना बदलाव के उपयोग किया जा सकता है, इसलिए सावधान रहें। जब आप इसे पुनर्जीवित करते हैं, तो आपको इसे सभी नोड्स पर कॉपी करने की आवश्यकता होगी, साथ ही साथ इसे (सभी मशीनों पर भी) का उपयोग करके कुबेकॉन्ग फ़ाइलों को अपडेट करना होगा।
• ca-key.pem नोड्स पर नकल करने के समान है।
• क्यूब-कंट्रोलर- manager.pem - केवल क्यूब-कंट्रोलर-मैनेजर के लिए आवश्यक है।
• क्यूब-कंट्रोलर-मैनेजर- key.pem - केवल क्यूब-कंट्रोलर-मैनेजर के लिए आवश्यक है।

• kubernetes.pem - फलालैन के लिए आवश्यक है, कॉर्ड-क्युड-एवेर्वर से कनेक्ट करते समय कॉर्डन।

  
  
  सैद्धांतिक पीछे हटना

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

  
  

  मेरी व्यक्तिगत राय है कि etcd के लिए आपको अलग-अलग प्रमाणपत्रों की आवश्यकता होती है जो kubernetes के लिए उपयोग किए गए प्रमाणपत्रों के साथ ओवरलैप नहीं होते हैं।

  
  
  
  

• kubernetes-key.pem - मास्टर सर्वर पर रहता है।
• सेवा- account.pem - केवल घन-नियंत्रक-प्रबंधक डेमॉन के लिए आवश्यक है।
• service-account-key.pem - इसी तरह।

काम की इकाइयाँ

• ca.pem - काम नोड्स (क्यूबलेट, क्यूब-प्रॉक्सी) पर शामिल सभी सेवाओं के लिए आवश्यक है, साथ ही फलालैन, कोरडन्स के लिए भी। अन्य चीजों के अलावा, इसकी सामग्री को कुबेकॉन्फ फाइल में शामिल किया जाता है, जब वे कुब्लेट का उपयोग करके उत्पन्न होते हैं।
• kubernetes-key.pem - को फेल्ड और कॉर्डन के लिए केवल कॉर्ड से कनेक्ट करने की आवश्यकता है, जो एपी मास्टर नोड पर स्थित है।
• kubernetes.pem - पिछले एक के समान, केवल फलालैन और कॉर्डन के लिए आवश्यक।
• kubelet / node-1.pem - प्राधिकरण नोड -1 के लिए कुंजी।
• kubelet / node-1-key.pem - प्राधिकरण नोड -1 के लिए कुंजी।

महत्वपूर्ण! यदि आपके पास एक से अधिक नोड हैं, तो प्रत्येक नोड में node-X.kubeconfig अंदर नोड- node-X-key.pem , node-X.pem और node-X.kubeconfig फाइलें शामिल होंगी।

 $ cfssl-certinfo -cert node-1.pem 

 { "subject": { "common_name": "system:node:node-1", "country": "RU", "organization": "system:nodes", "organizational_unit": "Infrastructure Unit", "locality": "Moscow", "province": "Moscow", "names": [ "RU", "Moscow", "Moscow", "system:nodes", "Infrastructure Unit", "system:node:node-1" ] }, "issuer": { "common_name": "Kubernetes", "country": "RU", "organization": "Kubernetes", "organizational_unit": "Infrastructure", "locality": "Moscow", "province": "Moscow", "names": [ "RU", "Moscow", "Moscow", "Kubernetes", "Infrastructure", "Kubernetes" ] }, "serial_number": "161113741562559533299282037709313751074033027073", "sans": [ "w40k.net", "node-1", "178.79.168.130", "192.168.164.230" ], "not_before": "2019-01-04T14:24:00Z", "not_after": "2029-01-01T14:24:00Z", "sigalg": "SHA256WithRSA", "authority_key_id": "6:C8:94:67:59:55:19:82:AD:ED:6D:50:F1:89:B:8D:46:78:FD:9A", "subject_key_id": "A1:5E:B3:3C:45:14:3D:C6:C:A:97:82:1:D5:2B:75:1A:A6:9D:B0", "pem": "<pem content>" } 

क्यूबलेट और क्यूब-प्रॉक्सी के लिए अन्य सभी प्रमाण पत्र सीधे संबंधित kubeconfig में एम्बेडेड हैं।

kubeconfig

सभी आवश्यक कुबेकॉन्फिग को कुबेरनेट्स का उपयोग करके कठिन तरीके से किया जा सकता है, हालांकि, यहां कुछ मतभेद शुरू होते हैं। मैनुअल kubedns और cni bridge kubedns कॉन्फ़िगरेशन का उपयोग करता है, इसमें coredns और flannel भी शामिल हैं। बदले में, ये दोनों सेवाएं क्लस्टर में kubeconfig इन करने के लिए kubeconfig का उपयोग kubeconfig ।

 $ cd certs #:  kubeconfig     certs$ ./generate-configkube.sh 

गुरु

विज़ार्ड के लिए, निम्न kubeconfig फ़ाइलों की आवश्यकता होती है (जैसा कि ऊपर बताया गया है, पीढ़ी के बाद उन्हें certs/kubeconfig में लिया जा सकता है):

 master /var/lib/kubernetes/$ tree -L 2 . +-- kube-controller-manager.kubeconfig L-- kube-scheduler  L-- kube-scheduler.kubeconfig 

इन फ़ाइलों को सेवा घटकों में से प्रत्येक को चलाने के लिए आवश्यक होगा।

काम की इकाइयाँ

काम नोड्स के लिए, निम्न कुबेकॉन्फ़िग फ़ाइलों की आवश्यकता होती है:

 node-1 /var/lib/kubernetes/$ tree -L 2 . +-- coredns ¦  L-- coredns.kubeconfig +-- flanneld ¦  L-- flanneld.kubeconfig +-- kubelet ¦  L-- node-1.kubeconfig L-- kube-proxy  L-- kube-proxy.kubeconfig 

सेवा का शुभारंभ

सेवाओं को शुरू करने के लिए, आपको service-name.service को /lib/systemd/system/ या किसी अन्य निर्देशिका में कॉपी करने की आवश्यकता है जहाँ systemd के लिए सेवाएँ स्थित हैं, और फिर चालू करें और सेवा शुरू करें। क्यूब-अपीज़र के लिए उदाहरण:

 $ systemctl enable kube-apiserver.service $ systemctl start kube-apiserver.service 

बेशक, सभी सेवाओं को हरा होना चाहिए (यानी, चल रहा है और कार्य कर रहा है)। यदि आप कोई गलती करते हैं, तो journal -f -t kube-apiserver journalct -xe या journal -f -t kube-apiserver आपको यह समझने में मदद करेगा कि वास्तव में क्या गलत है।

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

गुरु

आप सिस्टमड सेटिंग्स का उपयोग कर सकते हैं या आपके द्वारा उपयोग किए जा रहे कॉन्फ़िगरेशन के लिए इनिट स्क्रिप्ट उत्पन्न कर सकते हैं। जैसा कि पहले ही उल्लेख किया गया है, गुरु के लिए:

- systemd / etcd
- systemd / kube-apiserver
- सिस्टमड / क्यूब-कंट्रोलर-मैनेजर
- systemd / kube-अनुसूचक

काम की इकाइयाँ

- सिस्टमड / कंटेनर
- सिस्टमड / क्यूबलेट
- सिस्टमड / क्यूब-प्रॉक्सी
- सिस्टमड / कोरडन्स
- सिस्टमड / फलालैन

ग्राहक

क्लाइंट के काम करने के लिए, ${HOME}/.kube/config केवल certs/kubeconfig/admin.kubeconfig (इसे जेनरेट करने या इसे खुद लिखने के बाद) कॉपी करें ${HOME}/.kube/config

Kubectl डाउनलोड करें और kube-apiserver के संचालन की जांच करें। मैं आपको एक बार फिर याद दिला दूं कि इस स्तर पर, काम करने के लिए क्यूब-एपेसेरवर के लिए, केवल आदि को कार्य करना चाहिए। थोड़ी देर बाद क्लस्टर के पूर्ण संचालन के लिए शेष घटकों की आवश्यकता होगी।

जाँच करें कि क्यूब-अपीज़र और कुबेटल कार्य:

 $ kubectl version Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", "extra info": "..."} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", "extra info": "..."} 

फलालैन विन्यास

एक फलालैन विन्यास के रूप में, मैं vxlan बैकेंड पर बस गया। यहां बैकएंड के बारे में और पढ़ें।

 node1$ ip route add 10.200.12.0/24 via 192.168.1.2 node2$ ip route add 10.200.8.0/24 via 192.168.1.1 

 [10.200.80.23 container-1]->[192.168.1.1 node-1]->[192.168.1.2 node-2]->[10.200.12.5 container-2] 

आप वांछित फलालैन विन्यास सेट करने के लिए आदि / फलालैन से set-flannel-config.sh उपयोग कर सकते हैं। यह याद रखना महत्वपूर्ण है : यदि आप बैकएंड को बदलने का निर्णय लेते हैं, तो आपको कॉन्टर्ड में कॉन्फ़िगरेशन को हटाने और सभी नोड्स पर सभी फ़्लेनलाइन डेमॉन को पुनरारंभ करने की आवश्यकता होगी, इसलिए इसे बुद्धिमानी से चुनें। डिफ़ॉल्ट vxlan है।

 master$ export ETCDCTL_CA_FILE='/var/lib/kubernetes/ca.pem' master$ export ETCDCTL_CERT_FILE='/var/lib/kubernetes/kubernetes.pem' master$ export ETCDCTL_KEY_FILE='/var/lib/kubernetes/kubernetes-key.pem' master$ export ETCDCTL_ENDPOINTS='https://127.0.0.1:2379' master$ etcdctl ls /coreos.com/network/subnets/ /coreos.com/network/subnets/10.200.8.0-24 /coreos.com/network/subnets/10.200.12.0-24 master$ etcdctl get /coreos.com/network/subnets/10.200.8.0-24 {"PublicIP":"178.79.168.130","BackendType":"vxlan","BackendData":{"VtepMAC":"22:ca:ac:15:71:59"}} 

जब आप etcd में वांछित कॉन्फ़िगरेशन पंजीकृत कर लेते हैं, तो आपको प्रत्येक कार्य नोड पर इसे चलाने के लिए सेवा को कॉन्फ़िगर करने की आवश्यकता होती है।

flannel.service

सेवा के लिए एक उदाहरण यहां लिया जा सकता है: systemd / flannel

 [Unit] Description=Flanneld overlay address etcd agent After=network.target [Service] Type=notify #: current host ip. don't change if ip have not changed Environment=PUBLIC_IP=178.79.168.130 Environment=FLANNEL_ETCD=https://192.168.153.60:2379 ExecStart=/usr/bin/flanneld \ -etcd-endpoints=${FLANNEL_ETCD} -etcd-prefix=${FLANNEL_ETCD_KEY} \ -etcd-cafile=/var/lib/kubernetes/ca.pem \ -etcd-certfile=/var/lib/kubernetes/kubernetes.pem \ -etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \ -etcd-prefix=/coreos.com/network \ -healthz-ip=127.0.0.1 \ -subnet-file=/run/flannel/subnet.env \ -public-ip=${PUBLIC_IP} \ -kubeconfig-file=/var/lib/kubernetes/config/kubeconfig/flanneld.kubeconfig \ $FLANNEL_OPTIONS ExecStartPost=/usr/libexec/flannel/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/docker Restart=on-failure RestartSec=5 [Install] RequiredBy=docker.service 

समायोजन

जैसा कि पहले बताया गया है, हमें cad.pem, kubernetes.pem और kubernetes-key.pem फ़ाइलों को प्राधिकरण में प्राधिकृत करने की आवश्यकता है। अन्य सभी पैरामीटर कोई भी पवित्र अर्थ नहीं रखते हैं। केवल एक चीज जो वास्तव में महत्वपूर्ण है, वह वैश्विक आईपी पते को कॉन्फ़िगर करना है जिसके माध्यम से नेटवर्क पैकेट नेटवर्क के बीच जाएंगे:

( फलालैन के साथ मल्टी-होस्ट नेटवर्किंग ओवरले )

 #:   node-1$ systemctl enable flanneld.service #:  node-1$ systemctl start flanneld 

फलालैन सफलतापूर्वक शुरू होने के बाद, आपको अपने सिस्टम पर फलालैन.एन नेटवर्क इंटरफ़ेस खोजना चाहिए:

 node-1$ ifconfig flannel.100: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450 inet 10.200.8.0 netmask 255.255.255.255 broadcast 0.0.0.0 inet6 fe80::20ca:acff:fe15:7159 prefixlen 64 scopeid 0x20<link> ether 22:ca:ac:15:71:59 txqueuelen 0 (Ethernet) RX packets 18853 bytes 1077085 (1.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 11856 bytes 264331154 (252.0 MiB) TX errors 0 dropped 47 overruns 0 carrier 0 collisions 0 

जाँचना कि आपके इंटरफेस सभी नोड्स पर सही तरीके से काम कर रहे हैं, काफी सरल है। मेरे मामले में, नोड -1 और नोड -2 में क्रमशः 10.200.8.0/24 और 10.200.12.0/24 नेटवर्क हैं, इसलिए एक नियमित icmp अनुरोध के साथ हम उनकी उपलब्धता की जांच करते हैं:

 #:  node-2  node-1 node-1 $ ping -c 1 10.200.12.0 PING 10.200.12.0 (10.200.12.0) 56(84) bytes of data. 64 bytes from 10.200.12.0: icmp_seq=1 ttl=64 time=4.58 ms #:  node-1  node-2 node-2 $ ping -c 1 10.200.8.0 PING 10.200.8.0 (10.200.8.0) 56(84) bytes of data. 64 bytes from 10.200.8.0: icmp_seq=1 ttl=64 time=1.44 ms 

किसी भी समस्या के मामले में, यह जांचने की सिफारिश की जाती है कि क्या मेजबानों के बीच यूडीपी पर iptables में कोई काटने के नियम हैं।

कंटेनर कॉन्फ़िगरेशन

जगह आदि / कंटेनर / config.toml in /etc/containerd/config.toml या जहाँ भी आपके लिए सुविधाजनक हो, मुख्य बात यह है कि सेवा में कॉन्फ़िगरेशन फ़ाइल का पथ बदलने के लिए याद रखें (कंटेनरड . सेवा, नीचे वर्णित)।

मानक के कुछ संशोधनों के साथ कॉन्फ़िगरेशन। यह महत्वपूर्ण enable_tls_streaming = true कि आप enable_tls_streaming = true को सेट न करें यदि आप यह नहीं समझते हैं कि आप ऐसा क्यों कर रहे हैं। kubectl exec , .

containerd.service

 [Unit] Description=containerd container runtime Documentation=https://containerd.io After=network.target [Service] ; uncomment this if your overlay module are built as module ; ExecStartPre=/sbin/modprobe overlay ExecStart=/usr/bin/containerd \ -c /etc/containerd/config.toml Restart=always RestartSec=5 Delegate=yes KillMode=process OOMScoreAdjust=-999 LimitNOFILE=1048576 LimitNPROC=infinity LimitCORE=infinity [Install] WantedBy=multi-user.target 

समायोजन

, , cri-tools .
etc/crictl.yaml /etc/crictl.yaml . :

 node-1$ CONTAINERD_NAMESPACE=k8s.io crictl ps CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID 

, - kubernetes , crictl , , .

CNI Plugins

CNI , , , .

समायोजन

cni plugins /opt/cni/bin/

/etc/cni/net.d :

 { "cniVersion": "0.3.0", "name": "cbr0", "plugins": [ { "type": "flannel", "name": "kubenet", "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", "capabilities": { "portMappings": true }, "externalSetMarkChain": "KUBE-MARK-MASQ" } ] } 

 { "cniVersion": "0.3.0", "type": "loopback" } 

, . , , Red Hat Docker Podman , Intro to Podman

Kubelet

kubelet ( cni) — . kubelet hostname. , "" kubectl logs , kubectl exec , kubectl port-forward .

 systemReserved: cpu: 200m memory: 600Mi 

kubelet.service

service : systemd/kubelet

 [Unit] Description=Kubernetes Kubelet Documentation=https://github.com/kubernetes/kubernetes Requires=containerd.service [Service] #Environment=NODE_IP=192.168.164.230 Environment=NODE_IP=178.79.168.130 #: node name given by env Environment=NODE_NAME=w40k.net ExecStart=kubelet \ --allow-privileged \ --root-dir=/var/lib/kubernetes/kubelet \ --config=/var/lib/kubernetes/kubelet/kubelet-config.yaml \ --kubeconfig=/var/lib/kubernetes/kubelet/node-1.kubeconfig \ --cni-bin-dir=/opt/cni/bin \ --cni-conf-dir=/etc/cni/net.d/ \ --network-plugin=cni \ --container-runtime=remote \ --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \ --image-pull-progress-deadline=10m \ --node-ip=${NODE_IP} \ --hostname-override=${NODE_NAME} \ --v=1 Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target 

समायोजन

, RBAC , kubelet.

etc/kubelet-default-rbac.yaml , kubelet :

 user$ kubectl apply -f etc/kubelet-default-rbac.yaml 

, , .

 #:   node-1$ systemctl enable kubelet.service #:  node-1$ systemctl start kubelet 

, api :

 $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME w40k.net Ready <none> 5m v1.13.1 178.79.168.130 <none> Gentoo/Linux 4.18.16-x86_64-linode118 containerd://1.2.1 

Kube Proxy

: systemd/kubelet . , , kube-proxy-config.yaml : etc/kube-proxy

kube-proxy.service

 [Unit] Description=Kubernetes Proxy Documentation=https://github.com/kubernetes/kubernetes After=network.target [Service] ExecStart=kube-proxy \ --config=/var/lib/kubernetes/kube-proxy/kube-proxy-config.yaml Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target 

समायोजन

 #:   node-1$ systemctl enable kube-proxy.service #:  node-1$ systemctl start kube-proxy 

kube-proxy "" iptables, , - kubernetes (- ). .

CoreDNS

Corefile : etc/coredns/Corefile , :

 .:53 { errors log stdout health :8081 kubernetes cluster.local 10.200.0.0/16 { endpoint https://178.79.148.185:6443 tls /var/lib/kubernetes/kubernetes.pem /var/lib/kubernetes/kubernetes-key.pem /var/lib/kubernetes/ca.pem pods verified upstream /etc/resolv.conf kubeconfig /var/lib/kubernetes/config/kubeconfig/coredns.kubeconfig default } proxy . /etc/resolv.conf cache 30 } 

coredns.kubeconfig pem- ( ) worker . , coredns systemd-resolved. , Ubuntu , , , , . .

coredns.service

 [Unit] Description=CoreDNS Documentation=https://coredns.io/ After=network.target [Service] ExecStart=/usr/bin/coredns -conf /etc/coredns/Corefile Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target 

समायोजन

 #:   node-1$ systemctl enable coredns.service #:  node-1$ systemctl start coredns 

, , :

 node-1$ dig kubernetes.default.svc.cluster.local @127.0.0.1 #:    ;kubernetes.default.svc.cluster.local. IN A ;; ANSWER SECTION: kubernetes.default.svc.cluster.local. 5 IN A 10.32.0.1 

, coredns ip kubernetes .
, kubernetes.default kube-controller-manager, :

 $ kubectl get svc -n default NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.32.0.1 <none> 443/TCP 26h 

nginx-ingress & cert-manager

, . nginx-ingress cert-manager.

— nginx kubernetes ingress (master), :

  user$ git clone https://github.com/nginxinc/kubernetes-ingress.git user$ cd kubernetes-ingress/deployments user$ kubectl apply -f common/ns-and-sa.yaml user$ kubectl apply -f common/nginx-config.yaml user$ kubectl apply -f common/default-server-secret.yaml user$ kubectl apply -f daemon-set/nginx-ingress.yaml user$ kubectl apply -f rbac/rbac.yaml 

— cert manager (v0.5.2)

  user$ git clone https://github.com/jetstack/cert-manager.git user$ cd cert-manager && git co v0.5.2 user$ cd contrib/manifests/cert-manager user$ kubectl apply -f with-rbac.yaml 

, , , :

 NAMESPACE NAME READY STATUS RESTARTS AGE cert-manager cert-manager-554c76fbb7-t9762 1/1 Running 0 3h38m nginx-ingress nginx-ingress-sdztf 1/1 Running 0 10h nginx-ingress nginx-ingress-vrf85 1/1 Running 0 10h 

cert-manager nginx-ingress running state, , . , Running . .

, . , kubernetes resource : app/k8s

 user$ kube apply -f ns-and-sa.yaml user$ kube apply -f configmap.yaml #:  secret-example.yaml       #: secret.yaml user$ kube apply -f secret.yaml user$ kube apply -f tls-production.yaml user$ kube apply -f deployment.yaml user$ kube apply -f service.yaml user$ kube apply -f ingress-production.yaml 

, - . , ( kubernetes-example.w40k.net), , , cert-manager nginx-ingress . , ingress tls/ssl.

:

• http://no-https.kubernetes-example.w40k.net/ — ssl; , - , .
• https://kubernetes-example.w40k.net/ — (, , ), , , kubernetes .

, - . - , , .

संदर्भ

, , :

— Kubernetes the hard way
— Multi-Host Networking Overlay with Flannel
— Intro to Podman
— Stateless Applications
— What is ingress

:

— Kubernetes Networking: Behind the scenes ( )
— A Guide to the Kubernetes Networking Model
— Understanding kubernetes networking: services ( )

Q&A

<tbd>, .

, , . , , - , , .

 curl -H "Authorization: Bearer e5qXNAtwwCHUUwyLilZmAoFPozrQwUpw" -k -L https://<api-server-address>:6443/api/v1/ 

 $ kubectl get sa NAME SECRETS AGE default 1 19h 

 #:   job user$ kubectl apply -f debug/job.yaml job.batch/app created #:  ,   job user$ kubectl get pods -l job-name=app NAME READY STATUS RESTARTS AGE app-9kr9z 0/1 Completed 0 54s #: ,        #:   user$ kubectl describe pods app-9kr9z # ...   ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 12s default-scheduler Successfully assigned example/app-9kr9z to w40k.net 

 #:    user$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE backend ClusterIP 10.32.0.195 <none> 80/TCP 5m #:     user$ kubectl get pods -o wide #:     ' NAME READY STATUS RESTARTS AGE IP NODE backend-896584448-4r94s 1/1 Running 0 11h 10.200.8.105 w40k.net backend-896584448-np992 1/1 Running 0 11h 10.200.12.68 docker.grart.net #:  10   /status/ endpoint ,       #:       node-1$ for i in `seq 10`; do curl -L http://10.32.0.195/status/; done okokokokokokokokokok node-1$ conntrack -L -d 10.32.0.195 tcp 6 62 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62158 dport=80 src=10.200.12.68 dst=10.200.8.0 sport=8000 dport=62158 [ASSURED] mark=0 use=1 tcp 6 60 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62144 dport=80 src=10.200.12.68 dst=10.200.8.0 sport=8000 dport=62144 [ASSURED] mark=0 use=1 tcp 6 58 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62122 dport=80 src=10.200.12.68 dst=10.200.8.0 sport=8000 dport=62122 [ASSURED] mark=0 use=1 tcp 6 59 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62142 dport=80 src=10.200.8.105 dst=10.200.8.1 sport=8000 dport=62142 [ASSURED] mark=0 use=1 tcp 6 58 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62130 dport=80 src=10.200.8.105 dst=10.200.8.1 sport=8000 dport=62130 [ASSURED] mark=0 use=1 tcp 6 61 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62150 dport=80 src=10.200.12.68 dst=10.200.8.0 sport=8000 dport=62150 [ASSURED] mark=0 use=1 tcp 6 56 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62116 dport=80 src=10.200.8.105 dst=10.200.8.1 sport=8000 dport=62116 [ASSURED] mark=0 use=1 tcp 6 57 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62118 dport=80 src=10.200.12.68 dst=10.200.8.0 sport=8000 dport=62118 [ASSURED] mark=0 use=1 tcp 6 59 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62132 dport=80 src=10.200.12.68 dst=10.200.8.0 sport=8000 dport=62132 [ASSURED] mark=0 use=1 tcp 6 56 TIME_WAIT src=178.79.168.130 dst=10.32.0.195 sport=62114 dport=80 src=10.200.8.105 dst=10.200.8.1 sport=8000 dport=62114 [ASSURED] mark=0 use=1 

 #: node-1   10.200.8.105, node-2 10.200.12.68, #:      8000  #:  node-1 node-1$ curl -L http://10.200.8.105:8000/status/ ok node-1$ curl -L http://10.200.12.68:8000/status/ ok #:  node-2 node-2$ curl -L http://10.200.8.105:8000/status/ ok node-2$ curl -L http://10.200.12.68:8000/status/ ok