🤸🏽 👴🏼 🐁 VPC सेवा में Kubernetes क्लस्टर 🍫 🚒 🏠

हमने शुरुआती बीटा टेस्टिंग मोड में वर्चुअल प्राइवेट क्लाउड सर्विस में कुबेरनेट्स को आसानी से लॉन्च करने की क्षमता जोड़ी है।

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

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

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

इस लेख में, हम कुबेरनेट्स क्लस्टर की मुख्य वस्तुओं के बारे में बात करेंगे और ओपनस्टैक मैग्नम का उपयोग करके क्लस्टर बनाने की प्रक्रिया को देखने के लिए उदाहरणों का उपयोग करेंगे।

कुबेरनेट क्लस्टर बनाएं और प्रबंधित करें

वर्तमान में, कुबेरनेट्स क्लस्टर का निर्माण कंसोल यूटिलिटीज या ओपनस्टैक एपीआई इन उपलब्धता जोन आर -1 ए और आरयू -1 बी (सेंट पीटर्सबर्ग) के माध्यम से ही संभव है।

आरंभ करने के लिए, आपको आवश्यकता होगी:

एक नया बनाएँ या किसी मौजूदा VPC प्रोजेक्ट का उपयोग करें;
एक SSH कुंजी के साथ एक उपयोगकर्ता बनाएं;
परियोजना प्रबंधन पृष्ठ पर बनाई गई परियोजना के लिए एक उपयोगकर्ता जोड़ें;
प्रोजेक्ट पर जाएं और एक्सेस टैब पर एक्सेस फ़ाइल प्राप्त करें;
अजगर-मैग्नीक्लिअन लाइब्रेरी के साथ ओपनस्टैक कंसोल क्लाइंट स्थापित करें;
Kubectl कंसोल क्लाइंट स्थापित करें।

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

उबंटू / डेबियन परिवार के ऑपरेटिंग सिस्टम के लिए आवश्यक प्लग-इन के साथ एक ओपनस्टैक क्लाइंट स्थापित करने के लिए कमांड का पूरा सेट:

$ sudo apt update $ sudo apt -y install curl python-pip python-dev python3-dev git libxml2-dev libxslt1-dev python-openssl python3-openssl python-pyasn1 libffi-dev libssl-dev build-essential $ sudo pip install -UI pbr setuptools pytz $ sudo pip install -UI git+https://github.com/openstack/python-openstackclient $ sudo pip install -UI git+https://github.com/openstack/python-magnumclient

फेडोरा / सेंटोस परिवार के ऑपरेटिंग सिस्टम के लिए आवश्यक प्लग-इन के साथ एक ओपनस्टैक क्लाइंट स्थापित करने के लिए कमांड का पूरा सेट:

 $ sudo yum -y install python-pip gcc libffi-devel python-devel libxslt-devel openssl-devel git libffi-devel $ sudo pip install -UI pbr setuptools pytz $ sudo pip install -UI git+https://github.com/openstack/python-openstackclient $ sudo pip install -UI git+https://github.com/openstack/python-magnumclient

कुबेरनेट वस्तुओं का प्रबंधन करने के लिए, आपको कुबेटेल कंसोल क्लाइंट की आवश्यकता होती है। विभिन्न ऑपरेटिंग सिस्टम के लिए इंस्टॉलेशन के तरीके आधिकारिक दस्तावेज में वर्णित हैं।

एक क्लस्टर बनाने के लिए, आपको मौजूदा वाले बनाने या उपयोग करने की आवश्यकता होगी:

क्लस्टर टेम्पलेट ;
सीपीयू और आभासी मशीनों (स्वाद) की रैम के लिए मानकों सेट करें।

आप क्लस्टर टेम्प्लेट बना सकते हैं और स्वयं स्वाद ले सकते हैं, या सार्वजनिक पूर्व-निर्मित टेम्प्लेट का उपयोग कर सकते हैं।

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

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

SSH के माध्यम से नोड्स तक पहुंचने के लिए, आपको पहले बनाई गई SSH कुंजी का उपयोग करना होगा। नमूना आदेश ssh- परीक्षण नामक एक कुंजी का उपयोग करेगा।

हम सार्वजनिक क्लस्टर टेम्प्लेट और फ्लेवर, फास्ट डिस्क प्रकार और आरयू -1 बी उपलब्धता क्षेत्र का उपयोग करेंगे।
हमारे क्लस्टर में, शुरू में 2 मास्टर नोड और 3 मिनियन नोड शुरू किए जाएंगे।

इन मापदंडों को सत्यापित करने के लिए, हम ओपनस्टैकक्लाइंट कमांड और डाउनलोड की गई एक्सेस फ़ाइल ( rsh ) का उपयोग करते हैं:

 #          . $ source rc.sh #  ,         $ openstack flavor show BL1.2-4096 -c ram -c vcpus +-------+-------+ | Field | Value | +-------+-------+ | ram | 4096 | | vcpus | 2 | +-------+-------+ #       ru-1b $ openstack volume type show fast.ru-1b -c name +-------+------------+ | Field | Value | +-------+------------+ | name | fast.ru-1b | +-------+------------+ #    Kubernetes $ openstack coe cluster template list -c name +---------------------------------------+ | name | +---------------------------------------+ | kubernetes-nofloatingips-ru-1b-v1.9.3 | | kubernetes-nofloatingips-ru-1b-v1.9.6 | | kubernetes-nofloatingips-ru-1b-v1.9.9 | | kubernetes-floatingips-ru-1b-v1.9.3 | | kubernetes-floatingips-ru-1b-v1.9.6 | | kubernetes-floatingips-ru-1b-v1.9.9 | | kubernetes-nofloatingips-ru-1a-v1.9.3 | | kubernetes-nofloatingips-ru-1a-v1.9.6 | | kubernetes-nofloatingips-ru-1a-v1.9.9 | | kubernetes-floatingips-ru-1a-v1.9.3 | | kubernetes-floatingips-ru-1a-v1.9.6 | | kubernetes-floatingips-ru-1a-v1.9.9 | +---------------------------------------+

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

 #   Kubernetes   test-cluster #   keypair   ,   $ openstack coe cluster create \ --cluster-template kubernetes-nofloatingips-ru-1b-v1.9.9 \ --master-count 2 \ --node-count 3 \ --keypair ssh-test \ --master-flavor BL1.2-4096 \ --flavor BL1.2-4096 \ test-cluster

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

यह भी विचार करने योग्य है कि कई मास्टर नोड्स के साथ एक क्लस्टर बनाते समय, कुबेरनेसेस एपीआई तक पहुंचने के लिए एक लोड बैलेंसर स्वचालित रूप से बनाया जाएगा।

कुछ मिनटों के बाद, आपकी परियोजना में एक कुबेरनेट समूह दिखाई देगा। प्रोजेक्ट कंट्रोल पैनल में, आपको नई वर्चुअल मशीनें, डिस्क और नेटवर्क ऑब्जेक्ट दिखाई देंगे।

आप अपने क्लस्टर की स्थिति ओपनस्टैककिएंट के माध्यम से देख सकते हैं:

 openstack coe cluster list -c name -c status +--------------+--------------------+ | name | status | +--------------+--------------------+ | test-cluster | CREATE_IN_PROGRESS | +--------------+--------------------+

क्लस्टर CREATE_COMPLETE स्थिति में प्रवेश करने के बाद, आप निम्न आदेशों का उपयोग करके कॉन्फ़िगरेशन फ़ाइल डाउनलोड करके kubectl उपयोगिता के माध्यम से इसकी वस्तुओं का प्रबंधन कर सकते हैं:

 $ mkdir -p ~/test-cluster $ openstack coe cluster config test-cluster --dir ~/test-cluster

उसके बाद, आप kubectl उपयोगिता का उपयोग करके क्लस्टर के साथ काम कर सकते हैं:

 $ export KUBECONFIG=~/test-cluster/config $ kubectl get pods --all-namespaces -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase NAME STATUS coredns-785dcf9c58-6gnfp Running heapster-6846cdc674-rm4k6 Running kube-dns-autoscaler-6b94f7bbf8-x5clt Running kubernetes-dashboard-747575c864-wlg6p Running monitoring-grafana-84b4596dd7-zf5rx Running monitoring-influxdb-c8486fc95-bqqb6 Running node-exporter-test-cluster-robvp4cvwpt7-minion-0 Running

यदि आवश्यक हो, तो आप नए node_count मान को पास करके ओपनस्टैकक्लिएंट के माध्यम से क्लस्टर में मिनियन नोड्स की संख्या बढ़ा या घटा सकते हैं:

 $ openstack coe cluster update test-cluster replace node_count=4

कुंजी Kubernetes क्लस्टर ऑब्जेक्ट्स

फली

हालांकि कुबेरनेट्स कंटेनरों के एक समूह का प्रबंधन करता है, लेकिन कुबेरनेट्स की अंतर्निहित इकाई कंटेनर नहीं है, लेकिन एक फली है ।

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

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

उदाहरण के लिए, आइए यमल प्रारूप में वर्णन का उपयोग करते हुए Nginx के साथ सबसे सरल पॉड बनाएं:

 # nginx-basic.yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80

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

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-basic.yaml

निर्माण के बाद, हम kubectl डिस्क्रिप्शन कमांड का उपयोग करते हुए फली की स्थिति के बारे में पूरी जानकारी का अनुरोध कर सकते हैं:

 $ kubectl describe pod nginx Name: nginx Namespace: default Node: test-cluster-nd5c5y6lsfxb-minion-0/10.0.0.5 Start Time: Sun, 17 Jun 2018 12:29:03 +0000 Labels: <none> Annotations: <none> Status: Running IP: 10.100.88.9 Containers: nginx: Container ID: docker://6ca6383b66686c05c61c1f690737110e0f8994eda393f44a7ebfbbf2b2026267 Image: library/nginx:1.14-alpine Image ID: docker-pullable://docker.io/nginx@sha256:944b79ca7dbe456ce72e73e70816c1990e39967c8f010349a388c00b77ec519c Port: 80/TCP Host Port: 0/TCP State: Running Started: Sun, 17 Jun 2018 12:29:16 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-rp5ls (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-rp5ls: Type: Secret (a volume populated by a Secret) SecretName: default-token-rp5ls Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 52s default-scheduler Successfully assigned nginx to test-cluster-nd5c5y6lsfxb-minion-0 Normal SuccessfulMountVolume 51s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 MountVolume.SetUp succeeded for volume "default-token-rp5ls" Normal Pulling 50s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 pulling image "library/nginx:1.14-alpine" Normal Pulled 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Successfully pulled image "library/nginx:1.14-alpine" Normal Created 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Created container Normal Started 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Started container

जैसा कि आप देख सकते हैं, पॉड ने टेस्ट-क्लस्टर- nd5c5y6lsfxb-minion-0 नाम के नोड पर शुरू किया और 10.100.88.9 का आंतरिक आईपी पता प्राप्त किया।

ईवेंट अनुभाग से आप मुख्य लॉन्च ईवेंट देख सकते हैं - छवि को लॉन्च और डाउनलोड करने के लिए एक नोड का चयन करना।

हम पॉड में जा सकते हैं और कंटेनर के अंदर प्रक्रियाओं की स्थिति की जांच कर सकते हैं:

 $ kubectl exec -it nginx sh ps aux PID USER TIME COMMAND 1 root 0:00 nginx: master process nginx -g daemon off; 7 nginx 0:00 nginx: worker process 20 root 0:00 sh 24 root 0:00 ps aux exit

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

 $ ping -c 1 10.100.88.9 PING 10.100.88.9 (10.100.88.9): 56 data bytes --- 10.100.88.9 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss $ kubectl exec nginx -- ping -c1 10.100.88.9 PING 10.100.88.9 (10.100.88.9): 56 data bytes 64 bytes from 10.100.88.9: seq=0 ttl=64 time=0.075 ms --- 10.100.88.9 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.075/0.075/0.075 ms

इस तथ्य के अलावा कि निर्दिष्ट आईपी पता केवल कंटेनर से सुलभ है, यह भी स्थायी नहीं है। इसका मतलब है कि यदि इस पॉड को फिर से बनाया गया है, तो यह एक अलग आईपी पता प्राप्त कर सकता है।

इन समस्याओं को हल करने के लिए, आप सेवा नामक एक वस्तु का उपयोग कर सकते हैं।

सेवाएं

सेवा आपको पॉड्स के लिए स्थायी आईपी पते प्रदान करने की अनुमति देती है, उन्हें बाहरी नेटवर्क से पहुंच प्रदान करती है और पॉड्स के बीच संतुलन का अनुरोध करती है।
आप आधिकारिक दस्तावेज में सेवा के बारे में अधिक जान सकते हैं।

उदाहरण के लिए, हमें चल रहे पॉड को हटाने की आवश्यकता है:

 $ kubectl delete pod nginx

पॉड एक लेबल (लेबल) के विवरण में जोड़ें, जो सेवा के लिए आवश्यक है:

 # nginx-labeled.yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: app: webservice spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80

हमें सेवा के विवरण की भी आवश्यकता होगी:

 # nginx-nodeport.yaml apiVersion: v1 kind: Service metadata: name: nginx-nodeport labels: app: webservice spec: type: NodePort ports: - port: 80 nodePort: 30001 protocol: TCP selector: app: webservice

फली और सेवा बनाएँ:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-labeled.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/services/nginx-nodeport.yaml

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

सेवा तक पहुँचने के लिए क्लस्टर नोड्स के बाहरी पतों का उपयोग नहीं करने के लिए, हम NbPort के बजाय LoadBalancer प्रकार का उपयोग कर सकते हैं।
हमें सेवा के नए विवरण की आवश्यकता होगी:

 # nginx-loadbalancer.yaml apiVersion: v1 kind: Service metadata: name: nginx-loadbalancer labels: app: webservice spec: type: LoadBalancer ports: - port: 80 protocol: TCP selector: app: webservice

वर्तमान सेवा हटाएं और नया विवरण लागू करें:

 $ kubectl delete service nginx-service $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/services/nginx-loadbalancer.yaml

सेवा शुरू करने के बाद, नगीनक्स बाहरी नेटवर्क से टीसीपी पोर्ट 80 पर उपलब्ध होगा, और क्लस्टर नोड्स के लिए बाहरी पते को असाइन करने और उपयोग करने की कोई आवश्यकता नहीं होगी। प्रकार की सेवा LoadBalancer स्वचालित रूप से आपके VPC प्रोजेक्ट के लिए एक नया बाहरी पता आवंटित करेगा और इसका उपयोग करना शुरू कर देगा।

आप kubectl का उपयोग करके हाइलाइट किए गए बाहरी पते के बारे में जानकारी प्राप्त कर सकते हैं:

 $ kubectl get service nginx-service -o=custom-columns=IP:status.loadBalancer.ingress[0].ip IP xxx.xxx.xxx.xxx

हमारे उदाहरणों में, केवल एक पॉड को नगनेक्स के साथ लॉन्च किया गया था। अधिक पॉड्स के लिए एप्लिकेशन को स्केल करने के लिए, हम परिनियोजन का उपयोग कर सकते हैं।

तैनाती

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

हमें फिर से पोड निकालने की आवश्यकता होगी (हमें सेवा को हटाने की आवश्यकता नहीं है):

 $ kubectl delete pod nginx

निम्नलिखित परिनियोजन विवरण जोड़ें:

 # nginx-1.14.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 10 selector: matchLabels: app: webservice minReadySeconds: 10 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: webservice spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80

निर्दिष्ट परिनियोजन बनाएँ:

 $ kubectl create -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.14.yaml

हमने प्रतिकृतियां पैरामीटर के लिए 10 को चुना है, इसलिए नगीनक्स एप्लिकेशन के साथ 10 पॉड्स हमारे क्लस्टर में बनाए जाएंगे:

 $ kubectl get pods --selector app=webservice NAME READY STATUS RESTARTS AGE nginx-deployment-54bfdc4489-42rrb 1/1 Running 0 4m nginx-deployment-54bfdc4489-5lvtc 1/1 Running 0 4m nginx-deployment-54bfdc4489-g7rk2 1/1 Running 0 4m nginx-deployment-54bfdc4489-h5rxp 1/1 Running 0 4m nginx-deployment-54bfdc4489-l9l2d 1/1 Running 0 4m nginx-deployment-54bfdc4489-pjpvg 1/1 Running 0 4m nginx-deployment-54bfdc4489-q8dnp 1/1 Running 0 4m nginx-deployment-54bfdc4489-s4wzf 1/1 Running 0 4m nginx-deployment-54bfdc4489-tfxf9 1/1 Running 0 4m nginx-deployment-54bfdc4489-xjzb5 1/1 Running 0 4m

आप पिछले अनुभाग में बनाई गई सेवा का उपयोग करके बाहरी नेटवर्क से चल रहे एप्लिकेशन तक पहुंच सकते हैं। 10 Nginx उदाहरणों के बीच सेवा स्वचालित रूप से बाहरी नेटवर्क से अनुरोधों को संतुलित करेगी।

यदि आवश्यक हो, तो हम Nginx के संस्करण को अपडेट कर सकते हैं। छवि के संस्करण को 1.14-अल्पाइन से 1.15-अल्पाइन में बदलकर परिनियोजन विवरण अपडेट करें:

 # nginx-1.15.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 10 selector: matchLabels: app: webservice minReadySeconds: 10 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: webservice spec: containers: - name: nginx image: library/nginx:1.15-alpine # <-- changed ports: - containerPort: 80

पॉड्स को अपडेट करने की प्रक्रिया शुरू करने के लिए, हम kubectl कमांड का उपयोग करते हैं। तर्क पर ध्यान दें - एकॉर्ड, यह हमारे लिए उपयोगी है Nginx संस्करण के बाद के सुविधाजनक रोलबैक के लिए:

 $ kubectl apply -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.15.yaml \ --record

आप निम्न कमांड का उपयोग करके अद्यतन की प्रगति की निगरानी कर सकते हैं:

 $ kubectl rollout status deployment nginx-deployment Waiting for rollout to finish: 4 out of 10 new replicas have been updated...

कुबेरनेट्स एक पॉड के सफल अद्यतन के बाद 10 सेकंड इंतजार करेंगे, क्योंकि हमने तैनाती विवरण में minReadySeconds पैरामीटर के लिए 10 का मान निर्दिष्ट किया था।

अद्यतन पूर्ण होने के बाद, सभी पॉड्स परिनियोजन सक्रिय स्थिति में जाएंगे:

 $ kubectl get deployment --selector app=webservice NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 10 10 10 10 23m

अगर कुछ गलत हुआ तो हम एप्लिकेशन के संस्करण को वापस ला सकते हैं। ऐसा करने के लिए, हमें वांछित परिनियोजन संशोधन का चयन करने की आवश्यकता है:

 $ kubectl rollout history deployment nginx-deployment deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 <none> 2 kubectl apply --filename=https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.15.yaml --record=true

कमांड के आउटपुट में 2 संशोधन हैं - पहला तैनाती का प्रारंभिक निर्माण है, दूसरा एक अपडेट है। चूंकि हमने अपडेट करते समय --record तर्क का उपयोग किया था, इसलिए हम उस आदेश को देखते हैं जिसने परिनियोजन का दूसरा संशोधन बनाया था।

संस्करण को वापस लाने के लिए, निम्नलिखित कमांड का उपयोग करें:

 $ kubectl rollout undo deployment nginx-deployment --to-revision=1

इसी तरह, अपडेट के साथ, हम कमांड का उपयोग करके संस्करण के रोलबैक की निगरानी कर सकते हैं:

 $ kubectl rollout status deployment nginx-deployment Waiting for rollout to finish: 6 out of 10 new replicas have been updated…

हमारे सभी उदाहरणों में, हमने लगातार डेटा स्टोर के बिना कंटेनरों का उपयोग किया। अगले भाग में हम इसे ठीक करेंगे।

डेटा भंडारण

डिफ़ॉल्ट रूप से, पॉड्स के अंदर चलने वाले कंटेनरों का सारा डेटा अल्पकालिक होता है और पॉड्स के दुर्घटनाग्रस्त होने पर खो जाएगा।

पॉड्स को लगातार डेटा वेयरहाउस चलाने के लिए आप PersistentVolumeClaim ऑब्जेक्ट का उपयोग कर सकते हैं।

क्लस्टर में इस तरह की एक वस्तु बनाना बहुत सरल है - बस इसका विवरण जोड़ें, जिस तरह से हमने पिछले अनुभागों में पॉड, सेवा या तैनाती बनाई है।

अधिक जानकारी आधिकारिक दस्तावेज में पाई जा सकती है।

10V डिस्क बनाने के लिए PersistentVolumeClaim का उदाहरण विवरण:

 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pv-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi

हम इसे फली के डिस्क के रूप में जोड़ सकते हैं, इससे पहले बनाए गए नगीन के साथ पॉड के विवरण को अपडेट करके:

 # nginx-with-volume.yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80 volumeMounts: - mountPath: "/var/www/html" name: data volumes: - name: data persistentVolumeClaim: claimName: my-pv-claim

हालाँकि, डिस्क को बनाने के लिए, आपको StorageClass के रूप में बनाई गई डिस्क के गुणों को निर्दिष्ट करना होगा। "वर्चुअल प्राइवेट क्लाउड" सेवा में, आप कुबेरनेट पॉड डेटा के स्थायी भंडारण के रूप में तेज, सार्वभौमिक और बुनियादी प्रकार के नेटवर्क ड्राइव का उपयोग कर सकते हैं।

उदाहरण के लिए, StorageClass बनाने के लिए जो आपको रू -1 बी उपलब्धता क्षेत्र में तेजी से डिस्क का उपयोग करने की अनुमति देता है, आपको निम्नलिखित चीजें चाहिए:

 # fast.ru-1b.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: fast.ru-1b annotations: storageclass.beta.kubernetes.io/is-default-class: "true" provisioner: kubernetes.io/cinder parameters: type: fast.ru-1b availability: ru-1b

निर्दिष्ट ऑब्जेक्ट बनाने से पहले, पहले बनाए गए परिनियोजन को हटाएं:

 $ kubectl delete deployment nginx-deployment

सबसे पहले, एक StorageClass बनाते हैं, इसलिए यह डिफ़ॉल्ट वर्ग बन जाएगा, और PersistentVolumeClaim बाद में इसका उपयोग करेगा:

 $ kubectl create -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/storageclasses/fast.ru-1b.yaml

PersistentVolumeClaim और Pod बनाएँ:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/persistentvolumeclaims/my-pv-claim.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-with-volume.yaml

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

हम Nginx के साथ कंटेनर के अंदर डिस्क देख सकते हैं:

 $ kubectl exec -it nginx sh mount | grep "/var/www/html" /dev/sdc on /var/www/html type ext4 (rw,seclabel,relatime,data=ordered) exit

आप ड्राइव को परिनियोजन से कनेक्ट कर सकते हैं। आधिकारिक प्रलेखन में एक समान उदाहरण पाया जा सकता है।

कुबेरनेट्स कंट्रोल पैनल

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

पैनल की सभी विशेषताओं का उपयोग करने के लिए, आपको अपने क्लस्टर में व्यवस्थापक भूमिका के साथ एक खाता बनाना होगा।

ऐसा करने के लिए, हमें एक खाता विवरण चाहिए:

 # admin-user.yaml apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system

और भूमिका विवरण:

 # cluster-admin.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system

निर्दिष्ट ऑब्जेक्ट बनाएँ:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/accounts/admin-user.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/clusterrolebindings/cluster-admin.yaml

इसके बाद, आपको इस खाते के लिए जनरेट किए गए टोकन के मूल्य का पता लगाना होगा।
ऐसा करने के लिए, क्लस्टर में संबंधित सीक्रेट ऑब्जेक्ट खोजें:

 $ kubectl get secret --namespace=kube-system | grep "admin-user-token" admin-user-token-bkfhb kubernetes.io/service-account-token 3 22m

और व्यवस्थापक-उपयोगकर्ता-टोकन-bkfhb नाम के साथ गुप्त के टोकन मूल्य को देखें:

 $ kubectl describe secret admin-user-token-bkfhb --namespace=kube-system | grep "token:" token: XXXXXX...

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

इस स्थिति में कि आपने सार्वजनिक टेम्पलेट से एक क्लस्टर बनाया है, पैनल के संचालन को सुनिश्चित करने के लिए पोड और सर्विस इसमें पहले से मौजूद हैं:

 $ kubectl get svc kubernetes-dashboard --namespace=kube-system 206ms Tue Jun 19 14:35:19 2018 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes-dashboard ClusterIP 10.254.122.245 <none> 443/TCP 2d $ kubectl get pod --namespace=kube-system --selector k8s-app=kubernetes-dashboard 119ms Tue Jun 19 14:36:48 2018 NAME READY STATUS RESTARTS AGE kubernetes-dashboard-747575c864-jpxvt 1/1 Running 0 2d

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

 $ kubectl proxy Starting to serve on 127.0.0.1:8001

ब्राउज़र में निर्दिष्ट पता खोलकर प्रॉक्सी का परीक्षण करें:

यदि आपको स्क्रीनशॉट के समान उत्तर दिखाई देता है, तो आप निम्न पते का उपयोग करके कंट्रोल पैनल स्क्रीन पर जा सकते हैं:

 http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

इसके माध्यम से जाने पर, आपको पैनल में लॉगिन स्क्रीन देखनी चाहिए:

आपको पहले प्राप्त टोकन को निर्दिष्ट करने की आवश्यकता होगी। लॉग इन करने के बाद, आप कंट्रोल पैनल का उपयोग कर सकते हैं:

आप आधिकारिक दस्तावेज में नियंत्रण कक्ष की सभी विशेषताओं के बारे में पता कर सकते हैं।

Kubernetes ऑब्जेक्ट्स की निगरानी करना

यदि आप सार्वजनिक क्लस्टर टेम्पलेट का उपयोग करते हैं, तो आप स्वचालित रूप से मैट्रिक्स - प्रोमेथियस और ग्राफाना को इकट्ठा करने और प्रदर्शित करने के लिए घटकों को चलाएंगे।

कंट्रोल पैनल के समान, क्लस्टर प्रकार सेवा प्रकार के रूप में स्थापित किया गया है, इस तक पहुंच केवल क्लस्टर के भीतर से या कुबेटिक प्रॉक्सी के माध्यम से संभव है। आप निम्न पते पर अपने काम के कंप्यूटर से ग्रेफाना का उपयोग कर सकते हैं:

 http://127.0.0.1:8001/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana:80

निष्कर्ष

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

निकट भविष्य में, नवीनतम कुबेरनेट्स रिलीज का उपयोग करना संभव होगा, और क्लस्टर प्रबंधन नियंत्रण कक्ष के माध्यम से उपलब्ध होगा।

हमें खुशी होगी यदि आप परीक्षण मोड में हमारी सेवा का उपयोग करते हैं और प्रतिक्रिया प्रदान करते हैं।

VPC सेवा में Kubernetes क्लस्टर