होम कुबेरनेट्स क्लस्टर के साथ एडवेंचर्स

लगभग। ट्रांस। : लेख के लेखक, मार्शल ब्रेका, फेयर डॉट कॉम में सिस्टम डिज़ाइन निदेशक के पद पर काबिज हैं, जो कार लीजिंग के लिए अपना आवेदन प्रस्तुत करता है। अपने खाली समय में, वह "घर" समस्याओं को हल करने के लिए अपने व्यापक अनुभव का उपयोग करना पसंद करते हैं जो किसी भी गीक को आश्चर्यचकित करने की संभावना नहीं है (इसलिए, सवाल "क्यों?" - नीचे वर्णित कार्यों के संबंध में - एक प्राथमिकता छोड़ी गई है)। इसलिए, अपने प्रकाशन में, मार्शल ने कुबेरनेट्स की हाल की तैनाती के परिणामों को साझा किया ... एआरएम बोर्ड।



कई अन्य geeks की तरह, पिछले कुछ वर्षों में मैंने रास्पबेरी पाई जैसे विभिन्न विकास बोर्डों को संचित किया है। और कई गीकों की तरह, उन्होंने खुद को इस सोच के साथ अलमारियों पर धूल दिया कि वे किसी दिन काम आएंगे। और अब मेरे लिए यह दिन आखिरकार आ गया है!

सर्दियों की छुट्टियों के दौरान, कई हफ्तों के बाहर काम दिखाई दिया, जिसके भीतर सभी संचित लोहे को सूचीबद्ध करने और इसके साथ क्या करना है, यह तय करने के लिए पर्याप्त समय था। यहाँ मेरे पास है:

• USB3 कनेक्शन के साथ 5-ड्राइव RAID संलग्नक;
• रास्पबेरी पाई मॉडल बी (ओजी मॉडल);
• क्यूबाईबोर्ड 1;
• बनाना पाई M1;
• एचपी नेटबुक (2012?)।

5 सूचीबद्ध लोहे के घटकों में से, मैंने तब तक उपयोग किया जब तक कि RAID और एक नेटबुक एक अस्थायी एनएएस के रूप में नहीं। हालाँकि, नेटबुक में USB3 सपोर्ट की कमी के कारण, RAID ने पूर्ण गति क्षमता का उपयोग नहीं किया।

जीवन लक्ष्य

चूंकि नेटबुक का उपयोग करते समय RAID के साथ काम करना इष्टतम नहीं था, इसलिए मैंने सर्वश्रेष्ठ कॉन्फ़िगरेशन प्राप्त करने के लिए निम्नलिखित लक्ष्य निर्धारित किए हैं:

1. यूएसबी 3 और गीगाबिट ईथरनेट के साथ एनएएस;
2. अपने डिवाइस पर सॉफ़्टवेयर का प्रबंधन करने का सबसे अच्छा तरीका
3. (बोनस) RAID से फायर टीवी तक मल्टीमीडिया सामग्री को स्ट्रीम करने की क्षमता।

चूंकि किसी भी उपलब्ध डिवाइस ने USB3 और गीगाबिट ईथरनेट का समर्थन नहीं किया, दुर्भाग्य से, मुझे अतिरिक्त खरीदारी करनी पड़ी। चुनाव ROC-RK3328-CC पर गिर गया। उसके पास सभी आवश्यक विनिर्देशों और ऑपरेटिंग सिस्टम के लिए पर्याप्त समर्थन था।

मेरी हार्डवेयर जरूरतों को हल करने (और इस समाधान के आने की प्रतीक्षा) के बाद, मैं दूसरे लक्ष्य पर पहुंच गया।

डिवाइस पर सॉफ्टवेयर का प्रबंधन

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

तो मैंने अपने आप से कहा कि इस बार सब कुछ अलग होगा!



और वह इस तथ्य की ओर मुड़ गया कि मैं पर्याप्त रूप से कुबेरनेट्स को जानता हूं।

यद्यपि K8s मेरे मुख्य काम पर विभिन्न उपकरणों (मेरे अपने, कोप्स, इत्यादि) का उपयोग करके लगभग तीन वर्षों के प्रबंधन के बाद एक बहुत ही सरल समस्या का हल है, लेकिन मैं इस प्रणाली से बहुत परिचित हूं। इसके अलावा, बादल वातावरण के बाहर K8s को तैनात करना, और यहां तक ​​कि एआरएम उपकरणों पर भी - यह सब एक दिलचस्प काम लग रहा था।

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

एआरएम पर कुबेरनेट्स

काम पर, मेरे पास गुच्छों को तैनात करने के लिए kubeadm उपयोगिता का उपयोग करने का अवसर नहीं था, इसलिए मैंने फैसला किया कि अब कार्रवाई में कोशिश करने का समय था।

रास्पियन को ऑपरेटिंग सिस्टम के रूप में चुना गया था, क्योंकि यह मेरे बोर्डों के लिए सर्वश्रेष्ठ समर्थन के लिए प्रसिद्ध है।

मुझे हाइपेरियोस का उपयोग करके एक रास्पबेरी पाई पर कुबेरनेट्स स्थापित करने पर एक अच्छा लेख मिला। चूंकि मुझे अपने सभी बोर्डों के लिए हाइपेरियोस की उपलब्धता के बारे में निश्चित नहीं था, इसलिए मैंने डेबियन / रास्पियन के इन निर्देशों को अनुकूलित किया।

आवश्यक घटक

सबसे पहले, निम्नलिखित टूल की स्थापना आवश्यक थी:

• डोकर,
• kubelet,
• kubeadm,
• kubectl।

डॉकर को एक विशेष स्क्रिप्ट - सुविधा स्क्रिप्ट का उपयोग करके स्थापित किया जाना चाहिए (जैसा कि रास्पियन का उपयोग करने के मामले के लिए संकेत दिया गया है)।

 curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh 

उसके बाद, मैंने ह्यप्रीत ब्लॉग के निर्देशों के अनुसार कुबेरनेट्स घटक स्थापित किए, उन्हें एडाप्ट किया ताकि सभी निर्भरता के लिए विशिष्ट संस्करणों का उपयोग किया जाए:

 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list apt-get update apt-get install -y kubelet=1.13.1-00 kubectl=1.13.1-00 kubeadm=1.13.1-00 

रास्पबेरी पाई बी

रास्पबेरी पाई बी पर एक क्लस्टर बूटस्ट्रैप करने की कोशिश करते समय पहली कठिनाई उत्पन्न हुई:

 $ kubeadm init Illegal instruction 

यह पता चला कि कुबेरनेट्स ने ARMv6 के लिए समर्थन हटा दिया । खैर, मेरे पास भी क्यूबाई बोर्ड और केले पाई है।

केले की पी

प्रारंभ में, केले पाई के लिए कार्रवाई का एक ही अनुक्रम अधिक सफल प्रतीत होता था, हालांकि, नियंत्रण विमान को काम करने के लिए इंतजार करने की कोशिश kubeadm init हुए kubeadm init कमांड kubeadm init :

 error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster 

कंटेनर के साथ क्या हो रहा था, इसके बारे में पता करते हुए, मैंने देखा कि kube-controller-manager और kube-scheduler दोनों कम से कम 4-5 मिनट से काम कर रहे थे, लेकिन kube-api-server केवल 1-2 मिनट पहले उठ गया:

 $ docker ps CONTAINER ID COMMAND CREATED STATUS de22427ad594 "kube-apiserver --au…" About a minute ago Up About a minute dc2b70dd803e "kube-scheduler --ad…" 5 minutes ago Up 5 minutes 60b6cc418a66 "kube-controller-man…" 5 minutes ago Up 5 minutes 1e1362a9787c "etcd --advertise-cl…" 5 minutes ago Up 5 minutes 

जाहिर है, api-server मर रहा था या स्ट्रोंटियम प्रक्रिया इसे मार रही थी और इसे फिर से शुरू कर रही थी।

लॉग की जांच करते हुए, मैंने बहुत मानक स्टार्ट-अप प्रक्रियाएं देखीं - टीएलएस हैंडशेक में कई त्रुटियों की उपस्थिति से पहले सुरक्षित पोर्ट और एक लंबे ठहराव को सुनने की शुरुआत का रिकॉर्ड था:

 20:06:48.604881 naming_controller.go:284] Starting NamingConditionController 20:06:48.605031 establishing_controller.go:73] Starting EstablishingController 20:06:50.791098 log.go:172] http: TLS handshake error from 192.168.1.155:50280: EOF 20:06:51.797710 log.go:172] http: TLS handshake error from 192.168.1.155:50286: EOF 20:06:51.971690 log.go:172] http: TLS handshake error from 192.168.1.155:50288: EOF 20:06:51.990556 log.go:172] http: TLS handshake error from 192.168.1.155:50284: EOF 20:06:52.374947 log.go:172] http: TLS handshake error from 192.168.1.155:50486: EOF 20:06:52.612617 log.go:172] http: TLS handshake error from 192.168.1.155:50298: EOF 20:06:52.748668 log.go:172] http: TLS handshake error from 192.168.1.155:50290: EOF 

और इसके तुरंत बाद, सर्वर अपना काम समाप्त कर देता है। Googling ने ऐसी समस्या को जन्म दिया, जो कुछ एआरएम उपकरणों पर क्रिप्टोग्राफिक एल्गोरिदम के धीमे संचालन के संभावित कारण का संकेत देता है।

मैंने और सोचा और सोचा कि शायद api-server scheduler और controller-manager से बहुत बार-बार अनुरोध मिल रहा है।

इन फाइलों को मैनिफ़ेस्ट डायरेक्टरी से हटाकर क्यूबलेट को संबंधित पॉड्स के निष्पादन को रोकने के लिए कहा जाएगा:

 mkdir /etc/kubernetes/manifests.bak mv /etc/kubernetes/manifests/kube-scheduler.yaml /etc/kubernetes/manifests.bak/ mv /etc/kubernetes/manifests/kube-controller-mananger.yaml /etc/kubernetes/manifests.bak/ 

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

इसलिए, मैंने /etc/kubernetes/manifests/kube-api-server.yaml - और इसमें, निश्चित रूप से जाँच की ...

 livenessProbe: failureThreshold: 8 httpGet: host: 192.168.1.155 path: /healthz port: 6443 scheme: HTTPS initialDelaySeconds: 15 timeoutSeconds: 15 

135 सेकंड के बाद पॉड की मौत हो गई ( initialDelaySeconds + timeoutSeconds * failureThreshold )। initialDelaySeconds वृद्धि को बढ़ाएं 120 ...

सफलता! खैर, हैंडशेक त्रुटियां अभी भी होती हैं (संभवतः क्यूबलेट से), हालांकि लॉन्च अभी भी हुआ है:

 20:06:54.957236 log.go:172] http: TLS handshake error from 192.168.1.155:50538: EOF 20:06:55.004865 log.go:172] http: TLS handshake error from 192.168.1.155:50384: EOF 20:06:55.118343 log.go:172] http: TLS handshake error from 192.168.1.155:50292: EOF 20:06:55.252586 cache.go:39] Caches are synced for autoregister controller 20:06:55.253907 cache.go:39] Caches are synced for APIServiceRegistrationController controller 20:06:55.545881 controller_utils.go:1034] Caches are synced for crd-autoregister controller ... 20:06:58.921689 storage_rbac.go:187] created clusterrole.rbac.authorization.k8s.io/cluster-admin 20:06:59.049373 storage_rbac.go:187] created clusterrole.rbac.authorization.k8s.io/system:discovery 20:06:59.214321 storage_rbac.go:187] created clusterrole.rbac.authorization.k8s.io/system:basic-user 

जब api-server उठ गया, तो मैंने कंट्रोलर और शेड्यूलर के लिए YAML फ़ाइलों को प्रकट निर्देशिका में स्थानांतरित कर दिया, जिसके बाद वे सामान्य रूप से भी शुरू हो गए।

अब यह सुनिश्चित करने का समय आ गया है कि यदि आप स्रोत निर्देशिका में सभी फ़ाइलों को छोड़ देते हैं तो डाउनलोड सफल होगा: क्या यह livenessProbe के आरंभ में स्वीकार्य देरी को बदलने के लिए पर्याप्त है?

 20:29:33.306983 reflector.go:134] k8s.io/client-go/informers/factory.go:132: Failed to list *v1.Service: Get https://192.168.1.155:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.1.155:6443: i/o timeout 20:29:33.434541 reflector.go:134] k8s.io/client-go/informers/factory.go:132: Failed to list *v1.ReplicationController: Get https://192.168.1.155:6443/api/v1/replicationcontrollers?limit=500&resourceVersion=0: dial tcp 192.168.1.155:6443: i/o timeout 20:29:33.435799 reflector.go:134] k8s.io/client-go/informers/factory.go:132: Failed to list *v1.PersistentVolume: Get https://192.168.1.155:6443/api/v1/persistentvolumes?limit=500&resourceVersion=0: dial tcp 192.168.1.155:6443: i/o timeout 20:29:33.477405 reflector.go:134] k8s.io/client-go/informers/factory.go:132: Failed to list *v1beta1.PodDisruptionBudget: Get https://192.168.1.155:6443/apis/policy/v1beta1/poddisruptionbudgets?limit=500&resourceVersion=0: dial tcp 192.168.1.155:6443: i/o timeout 20:29:33.493660 reflector.go:134] k8s.io/client-go/informers/factory.go:132: Failed to list *v1.PersistentVolumeClaim: Get https://192.168.1.155:6443/api/v1/persistentvolumeclaims?limit=500&resourceVersion=0: dial tcp 192.168.1.155:6443: i/o timeout 20:29:37.974938 controller_utils.go:1027] Waiting for caches to sync for scheduler controller 20:29:38.078558 controller_utils.go:1034] Caches are synced for scheduler controller 20:29:38.078867 leaderelection.go:205] attempting to acquire leader lease kube-system/kube-scheduler 20:29:38.291875 leaderelection.go:214] successfully acquired lease kube-system/kube-scheduler 

हां, सब कुछ काम करता है, हालांकि इस तरह के पुराने डिवाइस, जाहिरा तौर पर, नियंत्रण विमान को लॉन्च करने का इरादा नहीं था, क्योंकि दोहराया टीएलएस कनेक्शन महत्वपूर्ण ब्रेक का कारण बनते हैं। एक तरह से या किसी अन्य - एआरएम पर K8s की एक कामकाजी स्थापना प्राप्त होती है! चलिए आगे ...

RAID बढ़ते

चूंकि एसडी कार्ड लंबे समय तक रिकॉर्डिंग के लिए उपयुक्त नहीं हैं, इसलिए मैंने फ़ाइल सिस्टम के सबसे अस्थिर भागों के लिए अधिक विश्वसनीय भंडारण का उपयोग करने का फैसला किया - इस मामले में, RAID। इस पर 4 खंडों पर प्रकाश डाला गया:

• 50 जीबी;
• 2 × 20 जीबी;
• ३.९ टी.बी.

मैं अभी तक 20-गीगाबाइट विभाजन के लिए एक विशिष्ट उद्देश्य के साथ नहीं आया हूं, लेकिन मैं भविष्य के लिए अतिरिक्त अवसर छोड़ना चाहता था।

/etc/fstab 50 GB विभाजन के लिए, माउंट बिंदु को /mnt/root में और 3.9 TB के लिए निर्दिष्ट किया गया था - /mnt/raid । उसके बाद, मैंने etcd और docker के साथ निर्देशिकाओं को 50 GB विभाजन पर आरोहित किया:

 UUID=655a39e8-9a5d-45f3-ae14-73b4c5ed50c3 /mnt/root ext4 defaults,rw,user,auto,exec 0 0 UUID=0633df91-017c-4b98-9b2e-4a0d27989a5c /mnt/raid ext4 defaults,rw,user,auto 0 0 /mnt/root/var/lib/etcd /var/lib/etcd none defaults,bind 0 0 /mnt/root/var/lib/docker /var/lib/docker none defaults,bind 0 0 

आगमन ROC-RK3328-CC

जब नया बोर्ड दिया गया था, मैंने उस पर K8 के लिए आवश्यक घटक स्थापित किए (लेख की शुरुआत देखें) और kubeadm init लॉन्च किया। प्रतीक्षा के कुछ मिनट अन्य नोड्स पर चलने के लिए join कमांड की सफलता और आउटपुट है।

बहुत बढ़िया! टाइमआउट के साथ कोई उपद्रव नहीं।

और चूंकि RAID का उपयोग इस बोर्ड पर भी किया जाएगा, mounts को फिर से कॉन्फ़िगर करने की आवश्यकता होगी। सभी चरणों को संक्षेप में प्रस्तुत करने के लिए:

1. माउंट डिस्क में / etc / fstab है

 UUID=655a39e8-9a5d-45f3-ae14-73b4c5ed50c3 /mnt/root ext4 defaults,rw,user,auto,exec 0 0 UUID=0633df91-017c-4b98-9b2e-4a0d27989a5c /mnt/raid ext4 defaults,rw,user,auto 0 0 /mnt/root/var/lib/etcd /var/lib/etcd none defaults,bind 0 0 /mnt/root/var/lib/docker /var/lib/docker none defaults,bind 0 0 

2. डॉकर और K8s बायनेरिज़ को स्थापित करना

 curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh 

 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list apt-get update apt-get install -y kubelet=1.13.1-00 kubectl=1.13.1-00 kubeadm=1.13.1-00 

3. एक अद्वितीय होस्ट नाम कॉन्फ़िगर करना (जो कि कई नोड जोड़े गए हैं)

 hostnamectl set-hostname k8s-master-1 

4. कुबेरनेट्स इनिशियलाइज़ेशन

मैं नियंत्रण विमान के साथ चरण को छोड़ देता हूं, क्योंकि मैं इस नोड पर सामान्य पॉड्स की योजना बनाने में सक्षम होना चाहता हूं:

 kubeadm init --skip-phases mark-control-plane 

5. नेटवर्क प्लगइन स्थापित करना

हाइप्रीट लेख में इस पर जानकारी थोड़ी दिनांकित थी क्योंकि बुन नेटवर्क प्लगइन अब एआरएम पर भी समर्थित है :

 export KUBECONFIG=/etc/kubernetes/admin.conf kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" 

6. होस्ट लेबल जोड़ना

इस नोड पर, मैं NAS सर्वर शुरू करने जा रहा हूं, इसलिए मैं इसे अनुसूचक में संभावित भविष्य के उपयोग के लिए लेबल के साथ चिह्नित करूंगा:

 kubectl label nodes k8s-master-1 marshallbrekka.raid=true kubectl label nodes k8s-master-1 marshallbrekka.network=gigabit 

अन्य नोड्स को क्लस्टर से कनेक्ट करना

अन्य उपकरणों (बनाना पी, क्यूबाईबोर्ड) को स्थापित करना उतना ही आसान था। उनके लिए, आपको पहले 3 चरणों (बढ़ते डिस्क / फ्लैश मीडिया के लिए सेटिंग्स को बदलना, उनकी उपलब्धता के आधार पर) को kubeadm join होगा और kubeadm init बजाय kubeadm join कमांड को kubeadm init ।

एआरएम के लिए डॉकटर कंटेनर ढूँढना

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

अगले चरण

अभी भी इस तरह के स्वचालित / स्क्रिप्टेड रूप में उपकरणों का प्रारंभिक विन्यास नहीं मिल रहा है, जैसा कि मैं चाहूंगा, मैंने कम से कम बुनियादी आदेशों (mounts, kubeadm और kubeadm ) का एक सेट तैयार किया और उन्हें Git रिपॉजिटरी में प्रलेखित किया। उपयोग किए गए बाकी अनुप्रयोगों को भी उसी रिपॉजिटरी में संग्रहीत K8 के लिए YAML कॉन्फ़िगरेशन प्राप्त हुआ, इसलिए अब खरोंच से आवश्यक कॉन्फ़िगरेशन प्राप्त करना बहुत सरल है।

भविष्य में, मैं निम्नलिखित प्राप्त करना चाहूंगा:

1. मास्टर साइटों को अत्यधिक उपलब्ध करें
2. किसी भी घटक में विफलताओं के बारे में जानने के लिए निगरानी / सूचनाएं जोड़ें;
3. अनुप्रयोगों की खोज (जो आंतरिक आईपी पते को याद रखना चाहते हैं?) को सरल बनाने के लिए क्लस्टर से एक DNS सर्वर का उपयोग करने के लिए राउटर की DCHP सेटिंग्स बदलें;
4. एक निजी नेटवर्क (DNS, आदि) के लिए क्लस्टर सेवाओं को अग्रेषित करने के लिए MetalLB चलाएं।

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

• " कुबेरनेट्स टिप्स एंड ट्रिक्स: नोड्स के आवंटन और वेब एप्लिकेशन पर लोड ";
• " कुबेरनेट्स टिप्स एंड ट्रिक्स: देव साइटों तक पहुंच ";
• " कुबेरनेट्स टिप्स एंड ट्रिक्स: बड़े डेटाबेस के बूटस्ट्रैप को तेज करना ";
• " 11 तरीके (नॉट) कुबेरनेट्स हैकिंग का शिकार बनें ";
• " कुबेरनेट्स के साथ खेलें अभ्यास में K8 को जानने के लिए एक सेवा है ।"