वेगवेगळ्या डेटा सेंटर्समध्ये कुबर्नेट्स क्लस्टर्स कसे जोडायचे

आमच्या Kubernetes Quick Start या मालिकेत आपले स्वागत आहे. हा एक नियमित स्तंभ आहे ज्यामध्ये आम्हाला ऑनलाइन आणि आमच्या प्रशिक्षणांमध्ये सर्वात मनोरंजक प्रश्न प्राप्त होतात. Kubernetes तज्ञ उत्तरे.

आजचे तज्ञ डॅनियल पोलेन्चिक (डॅनियल पोलेन्सिक). डॅनियल येथे इन्स्ट्रक्टर आणि सॉफ्टवेअर डेव्हलपर म्हणून काम करतो Learn8s.

तुम्हाला तुमच्या प्रश्नाचे उत्तर पुढील पोस्टमध्ये हवे असल्यास, ईमेलद्वारे आमच्याशी संपर्क साधा किंवा Twitter: @learnk8s.

मागील पोस्ट्स चुकल्या? त्यांना येथे शोधा.

वेगवेगळ्या डेटा सेंटरमध्ये कुबर्नेट्स क्लस्टर्स कसे जोडायचे?

थोडक्यात: Kubefed v2 लवकरच येत आहे, आणि मी याबद्दल वाचण्याची देखील शिफारस करतो शिपाई и मल्टी-क्लस्टर-शेड्युलर प्रकल्प.

बर्‍याचदा, पायाभूत सुविधांची प्रतिकृती बनविली जाते आणि वेगवेगळ्या प्रदेशांमध्ये, विशेषतः नियंत्रित वातावरणात वितरित केली जाते.

एक क्षेत्र अनुपलब्ध असल्यास, व्यत्यय टाळण्यासाठी रहदारी दुसर्‍याकडे पुनर्निर्देशित केली जाते.

Kubernetes सह, तुम्ही एक समान रणनीती वापरू शकता आणि विविध क्षेत्रांमध्ये वर्कलोड वितरित करू शकता.

तुमच्याकडे प्रति संघ, प्रदेश, पर्यावरण किंवा या घटकांचे संयोजन एक किंवा अधिक क्लस्टर असू शकतात.

तुमचे क्लस्टर वेगवेगळ्या ढगांमध्ये आणि ऑन-प्रिमाइसेसमध्ये होस्ट केले जाऊ शकतात.

पण अशा भौगोलिक प्रसारासाठी तुम्ही पायाभूत सुविधांचे नियोजन कसे कराल?
तुम्हाला एकाच नेटवर्कवर अनेक क्लाउड वातावरणासाठी एक मोठा क्लस्टर तयार करण्याची आवश्यकता आहे का?
किंवा अनेक लहान क्लस्टर आहेत आणि त्यांना नियंत्रित आणि समक्रमित करण्याचा मार्ग शोधा?

एक नेतृत्व क्लस्टर

एका नेटवर्कवर एक क्लस्टर तयार करणे इतके सोपे नाही.

कल्पना करा की तुमचा अपघात झाला आहे, क्लस्टर विभागांमधील संपर्क तुटला आहे.

तुमच्याकडे एक मास्टर सर्व्हर असल्यास, अर्ध्या संसाधनांना नवीन कमांड प्राप्त करता येणार नाहीत कारण ते मास्टरशी संपर्क साधू शकणार नाहीत.

आणि त्याच वेळी आपल्याकडे जुने रूटिंग टेबल्स आहेत (kube-proxy नवीन डाउनलोड करू शकत नाही) आणि कोणतेही अतिरिक्त पॉड नाहीत (कुबेलेट अद्यतनांची विनंती करू शकत नाही).

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

परिणामी, आपल्याकडे दुप्पट शेंगा आहेत.

तुम्ही प्रत्येक प्रदेशासाठी एक मास्टर सर्व्हर बनवल्यास, etcd डेटाबेसमधील एकमत अल्गोरिदममध्ये समस्या असतील. (अंदाजे एड — खरं तर, etcd डेटाबेस मास्टर सर्व्हरवर स्थित असणे आवश्यक नाही. हे त्याच प्रदेशातील सर्व्हरच्या वेगळ्या गटावर चालवले जाऊ शकते. खरे आहे, त्याच वेळी क्लस्टरच्या अपयशाचा एक बिंदू मिळत आहे. पण पटकन.)

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

जर etcd घटनांमधील लेटन्सी नाटकीयरीत्या वाढली, जसे की वेगवेगळ्या प्रदेशातील तीन etcd घटनांप्रमाणेच, मूल्य निगोशिएट करण्यासाठी आणि डिस्कवर लिहिण्यासाठी बराच वेळ लागतो.
हे Kubernetes नियंत्रकांमध्ये प्रतिबिंबित होते.

नियंत्रक व्यवस्थापकाला बदल जाणून घेण्यासाठी आणि डेटाबेसला प्रतिसाद लिहिण्यासाठी अधिक वेळ द्यावा लागेल.

आणि एक नियंत्रक नसून अनेक असल्याने, चेन रिअॅक्शन परिणाम होतो आणि संपूर्ण क्लस्टर खूप हळू काम करू लागतो.

etcd इतके विलंब संवेदनशील आहे की अधिकृत दस्तऐवजीकरण नियमित हार्ड ड्राइव्हऐवजी SSDs वापरण्याची शिफारस करते.

एका क्लस्टरसाठी मोठ्या नेटवर्कची सध्या चांगली उदाहरणे नाहीत.

मुळात, डेव्हलपर समुदाय आणि SIG-क्लस्टर गट कुबेरनेट्स कंटेनर्सचे ऑर्केस्ट्रेट कसे करतात त्याच प्रकारे क्लस्टर्सचे ऑर्केस्ट्रेट कसे करायचे हे शोधण्याचा प्रयत्न करत आहेत.

पर्याय १: कुबेफेडसह क्लस्टर फेडरेशन

SIG-क्लस्टरकडून अधिकृत प्रतिसाद - kubefed2, मूळ kube फेडरेशन क्लायंट आणि ऑपरेटरची नवीन आवृत्ती.

प्रथमच, आम्ही कुबे फेडरेशन टूल वापरून क्लस्टर्सचा संग्रह एकल ऑब्जेक्ट म्हणून व्यवस्थापित करण्याचा प्रयत्न केला.

सुरुवात चांगली झाली, पण शेवटी कुबे फेडरेशन कधीही लोकप्रिय होऊ शकले नाही कारण त्याला सर्व संसाधनांचा आधार नव्हता.

हे फेडरेशन डिलिव्हरी आणि सेवांना समर्थन देते, परंतु स्टेटफुलसेट नाही, उदाहरणार्थ.
तसेच, फेडरेशन कॉन्फिगरेशन भाष्यांच्या स्वरूपात प्रसारित केले गेले आणि ते लवचिक नव्हते.

कल्पना करा की तुम्ही फक्त भाष्ये वापरून फेडरेशनमधील प्रत्येक क्लस्टरसाठी प्रतिकृती विभाजनाचे वर्णन कसे करू शकता.

तो एक संपूर्ण गोंधळ होता.

SIG-क्लस्टरने kubefed v1 नंतर बरेच काम केले आणि वेगळ्या कोनातून समस्येकडे जाण्याचा निर्णय घेतला.

भाष्यांऐवजी, त्यांनी क्लस्टरवर स्थापित केलेला नियंत्रक सोडण्याचा निर्णय घेतला. हे कस्टम रिसोर्स डेफिनिशन (CRDs) वापरून सानुकूलित केले जाऊ शकते.

फेडरेशनचा भाग असलेल्या प्रत्येक संसाधनासाठी, तुमच्याकडे तीन विभागांसह सानुकूल CRD व्याख्या आहे:

• संसाधनाची मानक व्याख्या, उदाहरणार्थ उपयोजन;
• धडा placement, जेथे आपण फेडरेशनमध्ये संसाधन कसे वितरित केले जाईल ते परिभाषित करता;
• धडा override, जेथे विशिष्ट संसाधनासाठी तुम्ही प्लेसमेंटमधून वजन आणि पॅरामीटर्स ओव्हरराइड करू शकता.

येथे प्लेसमेंट आणि ओव्हरराइड विभागांसह एकत्रित वितरणाचे उदाहरण आहे.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

जसे आपण पाहू शकता, पुरवठा दोन क्लस्टरमध्ये वितरीत केला जातो: cluster1 и cluster2.

पहिला क्लस्टर तीन प्रतिकृती पुरवतो आणि दुसरा 5 वर सेट केला आहे.

तुम्हाला प्रतिकृतींच्या संख्येवर अधिक नियंत्रण हवे असल्यास, kubefed2 नवीन ReplicaSchedulingPreference ऑब्जेक्ट प्रदान करते जेथे प्रतिकृतींचे वजन केले जाऊ शकते:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

CRD संरचना आणि API अद्याप तयार नाहीत आणि अधिकृत प्रकल्प भांडारात सक्रिय काम चालू आहे.

kubefed2 वर लक्ष ठेवा, परंतु लक्षात ठेवा की ते अद्याप उत्पादनासाठी योग्य नाही.

कडून kubefed2 बद्दल अधिक जाणून घ्या kubefed2 बद्दल अधिकृत लेख Kubernetes बद्दल ब्लॉग मध्ये आणि मध्ये कुबेफेड प्रकल्पाचे अधिकृत भांडार.

पर्याय २: Booking.com शैलीमध्ये क्लस्टर एकत्र करणे

Booking.com च्या डेव्हलपर्सनी kubefed v2 वर काम केले नाही, परंतु ते Shipper सोबत आले - अनेक क्लस्टर्सवर, अनेक क्षेत्रांमध्ये आणि अनेक क्लाउडमध्ये डिलिव्हरीसाठी ऑपरेटर.

शिपाई काहीसे kubefed2 सारखे.

दोन्ही टूल्स तुम्हाला तुमची मल्टी-क्लस्टर डिप्लॉयमेंट स्ट्रॅटेजी सानुकूलित करण्याची परवानगी देतात (कोणते क्लस्टर वापरले जातात आणि त्यांच्या किती प्रतिकृती आहेत).

पण डिलिव्हरी दरम्यान त्रुटींचा धोका कमी करणे हे शिपरचे ध्येय आहे.

Shipper मध्ये, तुम्ही पायऱ्यांची मालिका परिभाषित करू शकता जी मागील आणि वर्तमान तैनाती आणि येणार्‍या रहदारीच्या व्हॉल्यूममधील प्रतिकृतींचे विभाजन वर्णन करतात.

जेव्हा तुम्ही क्लस्टरमध्ये संसाधन पुश करता, तेव्हा शिपर कंट्रोलर सर्व जोडलेल्या क्लस्टरमध्ये ते बदल वाढवत आणतो.

तसेच, शिपर खूप मर्यादित आहे.

उदाहरणार्थ, हे हेल्म चार्ट इनपुट म्हणून स्वीकारते आणि व्हॅनिला संसाधनांना समर्थन देत नाही.
सामान्य शब्दात, शिपर असे कार्य करते.

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

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

एकाधिक क्लस्टर्स व्यवस्थापित करण्यासाठी शिपर हा एक चांगला पर्याय आहे, परंतु हेल्मशी त्याचा जवळचा संबंध केवळ मार्गात येतो.

जर आपण सर्वांनी हेल्म वरून स्विच केले तर काय होईल सानुकूलित करा किंवा कर्णधार?

शिपर आणि त्याच्या तत्त्वज्ञानाबद्दल येथे अधिक शोधा हे अधिकृत प्रेस प्रकाशन.

जर तुम्हाला कोड खोदायचा असेल तर, अधिकृत प्रकल्प भांडाराकडे जा.

पर्याय 3: "जादू" क्लस्टर विलीनीकरण

Kubefed v2 आणि Shipper क्लस्टर फेडरेशनसह कार्य करतात, सानुकूल संसाधन परिभाषाद्वारे क्लस्टर्सना नवीन संसाधने प्रदान करतात.

पण तुम्हाला सर्व डिलिव्हरी, स्टेटफुलसेट्स, डेमनसेट्स इ. विलीन करण्यासाठी पुन्हा लिहायचे नसल्यास काय?

YAML न बदलता फेडरेशनमध्ये विद्यमान क्लस्टर कसे समाविष्ट करावे?

मल्टी-क्लस्टर-शेड्युलर हा अॅडमिरॅलिटी प्रकल्प आहे, जे क्लस्टर्सवर शेड्यूलिंग वर्कलोडशी संबंधित आहे.

परंतु क्लस्टरशी संवाद साधण्याचा नवीन मार्ग आणण्याऐवजी आणि सानुकूल परिभाषांमध्ये संसाधने गुंडाळण्याऐवजी, मल्टी-क्लस्टर-शेड्यूलर हे मानक कुबर्नेट्स लाइफसायकलमध्ये एम्बेड केलेले आहे आणि पॉड्स तयार करणारे सर्व कॉल इंटरसेप्ट करते.

प्रत्येक तयार केलेला पॉड ताबडतोब डमीने बदलला जातो.

मल्टी-क्लस्टर-शेड्युलर वापरते प्रवेश सुधारणेसाठी वेबहुककॉल इंटरसेप्ट करण्यासाठी आणि निष्क्रिय डमी पॉड तयार करण्यासाठी.

मूळ पॉड दुसर्‍या नियोजन चक्रातून जातो जेथे, संपूर्ण फेडरेशनचे मतदान केल्यानंतर, नियुक्तीचा निर्णय घेतला जातो.

शेवटी, पॉड लक्ष्य क्लस्टरला वितरित केले जाते.

परिणामी, तुमच्याकडे अतिरिक्त पॉड आहे जे काहीही करत नाही, फक्त जागा घेते.

फायदा असा आहे की पुरवठा एकत्र करण्यासाठी तुम्हाला नवीन संसाधने लिहिण्याची गरज नाही.

पॉड तयार करणारे प्रत्येक संसाधन आपोआप विलीन होण्यासाठी तयार आहे.

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

परंतु शिपर बहुतेक वितरणाचा प्रभाव कमी करण्याचा प्रयत्न करत असताना, मल्टी-क्लस्टर-शेड्युलर अधिक सामान्य कार्ये हाताळतो आणि कदाचित बॅच जॉबसाठी अधिक अनुकूल आहे.

त्यात प्रगत क्रमिक वितरण यंत्रणा नाही.

मल्टी-क्लस्टर-शेड्युलरबद्दल अधिक येथे आढळू शकते अधिकृत भांडार पृष्ठ.

जर तुम्हाला मल्टी-क्लस्टर-शेड्युलर कृतीमध्ये वाचायचे असेल, तर Admiralty आहे Argo सह मनोरंजक वापर केस — वर्कफ्लो, इव्हेंट्स, सीआय आणि सीडी कुबर्नेट्स.

इतर साधने आणि उपाय

एकाधिक क्लस्टर्स कनेक्ट करणे आणि व्यवस्थापित करणे हे एक जटिल कार्य आहे आणि कोणतेही सार्वत्रिक उपाय नाही.

तुम्हाला हा विषय आणखी एक्सप्लोर करायचा असल्यास, येथे काही संसाधने आहेत:

• Rancher द्वारे पाणबुडी हे एक साधन आहे जे विविध Kubernetes क्लस्टर्सच्या आच्छादन नेटवर्कला जोडते.
• किरकोळ साखळी लक्ष्य वापर युनिमॅट्रिक्स स्पिननेकरसह एकत्रितपणे अनेक क्लस्टर्समध्ये तैनाती ऑर्केस्ट्रेट करण्यासाठी.
• IPV6 आणि वापरून पहा अनेक क्षेत्रांमध्ये एकल नेटवर्क.
• आपण सेवा जाळी वापरू शकता, उदाहरणार्थ एकाधिक क्लस्टर कनेक्ट करण्यासाठी Istio.
• Cilium, एक कंटेनर नेटवर्क इंटरफेस प्लगइन, ऑफर करते क्लस्टर मेष फंक्शन, जे तुम्हाला अनेक क्लस्टर्स एकत्र करण्यास अनुमती देते

आजसाठी एवढेच

शेवटपर्यंत वाचल्याबद्दल धन्यवाद!

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

आम्ही तुमची पद्धत लिंक्सवर जोडू.

ख्रिस नेस्बिट-स्मिथचे विशेष आभार (ख्रिस नेस्बिट-स्मिथ) आणि व्हिन्सेंट डी स्मे (व्हिन्सेंट डी स्मेट) (विश्वसनीयता अभियंता मध्ये swatmobile.io) लेख वाचण्यासाठी आणि फेडरेशन कसे कार्य करते याबद्दल उपयुक्त माहिती सामायिक करण्यासाठी.

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