विभिन्न डाटा केन्द्रहरूमा Kubernetes क्लस्टरहरू कसरी जडान गर्ने

हाम्रो Kubernetes Quick Start श्रृंखलामा स्वागत छ। यो हामीले अनलाइन र हाम्रा प्रशिक्षणहरूमा प्राप्त गर्ने सबैभन्दा रोचक प्रश्नहरू भएको नियमित स्तम्भ हो। Kubernetes विशेषज्ञ जवाफ।

आजका विज्ञ हुन् डेनियल पोलेन्चिक (डेनियल पोलेन्सिक)। डेनियल एक प्रशिक्षक र सफ्टवेयर विकासकर्ताको रूपमा काम गर्दछ सिक्नुहोस्8s.

यदि तपाइँ तपाइँको प्रश्न को अर्को पोस्ट मा जवाफ चाहनुहुन्छ भने, हामीलाई ईमेल द्वारा सम्पर्क गर्नुहोस् वा ट्विटर: @learnk8s.

अघिल्लो पोस्टहरू छुटेको छ? तिनीहरूलाई यहाँ फेला पार्नुहोस्.

विभिन्न डाटा केन्द्रहरूमा Kubernetes क्लस्टरहरू कसरी जडान गर्ने?

संक्षिप्त: Kubefed v2 चाँडै आउँदैछ, र म पनि पढ्न सिफारिस गर्छु शिपर и बहु-क्लस्टर-शेड्युलर परियोजना.

प्रायः, पूर्वाधारहरू विभिन्न क्षेत्रहरूमा विशेष गरी नियन्त्रित वातावरणहरूमा प्रतिकृति र वितरण गरिन्छ।

यदि एक क्षेत्र अनुपलब्ध छ भने, ट्राफिक अवरोधहरूबाट बच्नको लागि अर्कोमा पुन: निर्देशित गरिन्छ।

Kubernetes को साथ, तपाईं समान रणनीति प्रयोग गर्न सक्नुहुन्छ र विभिन्न क्षेत्रहरूमा कार्यभार वितरण गर्न सक्नुहुन्छ।

तपाईंसँग प्रति टोली, क्षेत्र, वातावरण वा यी तत्वहरूको संयोजनमा एक वा बढी क्लस्टरहरू हुन सक्छन्।

तपाईंको क्लस्टरहरू विभिन्न क्लाउडहरू र अन-प्रिमाइसेसमा होस्ट गर्न सकिन्छ।

तर यस्तो भौगोलिक विस्तारको लागि पूर्वाधारको योजना कसरी बनाउनुहुन्छ?
के तपाइँ एकल नेटवर्कमा धेरै क्लाउड वातावरणहरूको लागि एउटा ठूलो क्लस्टर सिर्जना गर्न आवश्यक छ?
वा धेरै साना क्लस्टरहरू छन् र तिनीहरूलाई नियन्त्रण र सिङ्क्रोनाइज गर्ने तरिका पत्ता लगाउनुहोस्?

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

एउटै नेटवर्कमा एउटा क्लस्टर बनाउन त्यति सजिलो छैन।

कल्पना गर्नुहोस् कि तपाईसँग दुर्घटना भएको छ, क्लस्टर खण्डहरू बीचको जडान हराएको छ।

यदि तपाईंसँग एउटा मास्टर सर्भर छ भने, स्रोतहरूको आधाले नयाँ आदेशहरू प्राप्त गर्न सक्षम हुनेछैन किनभने तिनीहरू मास्टरलाई सम्पर्क गर्न सक्षम हुनेछैनन्।

र एकै समयमा तपाईंसँग पुरानो रूटिङ तालिकाहरू छन् (kube-proxy नयाँ डाउनलोड गर्न सक्दैन) र कुनै अतिरिक्त पोडहरू (कुबेलेटले अद्यावधिकहरू अनुरोध गर्न सक्दैन)।

कुरालाई नराम्रो बनाउनको लागि, यदि Kubernetes ले नोड देख्दैन भने, यसले यसलाई अनाथको रूपमा चिन्ह लगाउँछ र हराइरहेको पोडहरूलाई अवस्थित नोडहरूमा वितरण गर्दछ।

नतिजाको रूपमा, तपाईंसँग दुई गुणा धेरै पोडहरू छन्।

यदि तपाईंले प्रत्येक क्षेत्रको लागि एउटा मास्टर सर्भर बनाउनुभयो भने, etcd डाटाबेसमा सहमति एल्गोरिथ्ममा समस्याहरू हुनेछन्। (लगभग। एड। - वास्तवमा, etcd डाटाबेस मास्टर सर्भरहरूमा अवस्थित हुन आवश्यक छैन। यो एउटै क्षेत्र मा सर्भर को एक अलग समूह मा चलाउन सकिन्छ। साँचो, एकै समयमा क्लस्टर को विफलता को एक बिन्दु प्राप्त। तर छिटो।)

etcd प्रयोग गर्दछ राफ्ट एल्गोरिथ्मडिस्कमा लेख्नु अघि मूल्य वार्ता गर्न।
अर्थात्, राज्यलाई etcd मा लेख्न सक्नु अघि अधिकांश उदाहरणहरू सहमतिमा पुग्नै पर्छ।

यदि etcd उदाहरणहरू बीचको विलम्बता नाटकीय रूपमा बढ्छ, जस्तै विभिन्न क्षेत्रहरूमा तीन etcd उदाहरणहरूको मामलामा, यसले मूल्य वार्ता गर्न र डिस्कमा लेख्न लामो समय लिन्छ।
यो Kubernetes नियन्त्रकहरूमा प्रतिबिम्बित हुन्छ।

कन्ट्रोलर प्रबन्धकलाई परिवर्तनको बारेमा जान्न र डाटाबेसमा प्रतिक्रिया लेख्न थप समय चाहिन्छ।

र त्यहाँ एक नियन्त्रक छैन, तर धेरै, एक चेन प्रतिक्रिया परिणाम र सम्पूर्ण क्लस्टर धेरै बिस्तारै काम गर्न थाल्छ.

etcd यति विलम्बता संवेदनशील छ कि आधिकारिक कागजातले नियमित हार्ड ड्राइभको सट्टा SSDs प्रयोग गर्न सिफारिस गर्दछ.

एकल क्लस्टरको लागि ठूलो नेटवर्कको हाल कुनै राम्रो उदाहरणहरू छैनन्।

सामान्यतया, विकासकर्ता समुदाय र SIG-क्लस्टर समूहले Kubernetes अर्केस्ट्रेट कन्टेनरहरू जस्तै क्लस्टरहरू कसरी अर्केस्ट्रेट गर्ने भनेर पत्ता लगाउन प्रयास गरिरहेका छन्।

विकल्प 1: kubefed संग क्लस्टर संघ

SIG-क्लस्टरबाट आधिकारिक प्रतिक्रिया - kubefed2, मूल kube संघ ग्राहक र अपरेटर को एक नयाँ संस्करण.

पहिलो पटक, हामीले कुबे फेडरेशन उपकरण प्रयोग गरेर एकल वस्तुको रूपमा क्लस्टरहरूको सङ्कलन व्यवस्थापन गर्ने प्रयास गर्यौं।

शुरुवात राम्रो भयो तर अन्त्यमा सबै स्रोतसाधन जुटाउन नसक्दा कुबे महासंघ कहिल्यै लोकप्रिय हुन सकेन ।

यसले संघीय डेलिभरी र सेवाहरूलाई समर्थन गर्यो, तर स्टेटफुलसेटहरू होइन, उदाहरणका लागि।
साथै, संघ कन्फिगरेसन एनोटेसनको रूपमा प्रसारित गरिएको थियो र लचिलो थिएन।

केवल एनोटेसनहरू प्रयोग गरेर फेडरेशनमा प्रत्येक क्लस्टरको लागि प्रतिकृति विभाजन कसरी वर्णन गर्न सक्नुहुन्छ कल्पना गर्नुहोस्।

यो एक पूर्ण गडबड थियो।

SIG-क्लस्टरले kubefed v1 पछि धेरै काम गर्यो र फरक कोणबाट समस्यामा पुग्ने निर्णय गर्यो।

एनोटेसनहरूको सट्टा, तिनीहरूले क्लस्टरहरूमा स्थापना भएको नियन्त्रक जारी गर्ने निर्णय गरे। यसलाई Custom Resource Definitions (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 को बारे मा ब्लग मा र मा kubefed परियोजना को आधिकारिक भण्डार.

विकल्प २: Booking.com शैलीमा क्लस्टरहरू संयोजन गर्दै

Booking.com का विकासकर्ताहरूले kubefed v2 मा काम गरेनन्, तर तिनीहरू शिपरसँग आए - धेरै क्लस्टरहरूमा, धेरै क्षेत्रहरूमा र धेरै क्लाउडहरूमा डेलिभरीको लागि एक अपरेटर।

शिपर केहि हद सम्म kubefed2 को समान।

दुबै उपकरणहरूले तपाइँलाई तपाइँको बहु-क्लस्टर डिप्लोइमेन्ट रणनीति (कुन क्लस्टरहरू प्रयोग गरिन्छ र तिनीहरूसँग कति प्रतिकृतिहरू छन्) अनुकूलन गर्न अनुमति दिन्छ।

तर सिपरको लक्ष्य डेलिभरीको समयमा त्रुटिहरूको जोखिम कम गर्नु हो।

शिपरमा, तपाईंले अघिल्लो र हालको डिप्लोइमेन्ट र आगमन ट्राफिकको भोल्युम बीचको प्रतिकृतिहरूको विभाजनलाई वर्णन गर्ने चरणहरूको श्रृंखला परिभाषित गर्न सक्नुहुन्छ।

जब तपाइँ क्लस्टरमा स्रोत पुश गर्नुहुन्छ, शिपर नियन्त्रकले सबै जोडिएका क्लस्टरहरूमा परिवर्तनलाई बढाउँदै रोल आउट गर्दछ।

साथै, सिपर धेरै सीमित छ।

उदाहरणका लागि, यसले हेल्म चार्टलाई इनपुटको रूपमा स्वीकार गर्दछ र वेनिला स्रोतहरूलाई समर्थन गर्दैन।
सामान्य सर्तहरूमा, शिपरले यस्तो काम गर्दछ।

मानक डेलिभरीको सट्टा, तपाईंले हेल्म चार्ट समावेश गर्ने एप्लिकेसन स्रोत सिर्जना गर्न आवश्यक छ:

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 परिवर्तन नगरी महासंघमा अवस्थित क्लस्टर कसरी समावेश गर्ने?

बहु-क्लस्टर-शेड्युलर एक एडमिरेलिटी परियोजना हो, जसले क्लस्टरहरूमा कार्यभारको समयतालिकासँग सम्बन्धित छ।

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

प्रत्येक सिर्जना गरिएको पोड तुरुन्तै डमीको साथ प्रतिस्थापन गरिन्छ।

बहु-क्लस्टर-शेड्युलर प्रयोग गर्दछ पहुँच परिमार्जनका लागि वेबहुकहरूकल अवरोध गर्न र निष्क्रिय डमी पोड सिर्जना गर्न।

मूल पोड अर्को योजना चक्र मार्फत जान्छ जहाँ, सम्पूर्ण संघको मतदान पछि, नियुक्ति निर्णय गरिन्छ।

अन्तमा, पोड लक्षित क्लस्टरमा डेलिभर गरिन्छ।

नतिजाको रूपमा, तपाइँसँग एक अतिरिक्त पोड छ जसले केहि गर्दैन, केवल ठाउँ लिन्छ।

फाइदा यो हो कि तपाईंले आपूर्तिहरू संयोजन गर्न नयाँ स्रोतहरू लेख्नुपर्दैन।

पोड सिर्जना गर्ने प्रत्येक स्रोत स्वचालित रूपमा मर्ज हुन तयार छ।

यो चाखलाग्दो छ, किनकि अचानक तपाईंले धेरै क्षेत्रहरूमा आपूर्तिहरू वितरण गर्नुभयो, र तपाईंले ध्यान दिनुभएन। यद्यपि, यो एकदम जोखिमपूर्ण छ, किनकि यहाँ सबै कुरा जादूमा आधारित छ।

तर जब शिपरले धेरैजसो डेलिभरीको प्रभावलाई कम गर्न कोशिस गरिरहेको छ, बहु-क्लस्टर-शेड्यूलरले अधिक सामान्य कार्यहरू ह्यान्डल गर्दछ र सम्भवतः ब्याच कार्यहरूको लागि उपयुक्त छ।

यसमा उन्नत क्रमिक वितरण संयन्त्र छैन।

बहु-क्लस्टर-शेड्युलरको बारेमा थप मा फेला पार्न सकिन्छ आधिकारिक भण्डार पृष्ठ.

यदि तपाईं कार्यमा बहु-क्लस्टर-शेड्यूलरको बारेमा पढ्न चाहनुहुन्छ भने, एडमिरल्टी छ Argo संग रोचक प्रयोग मामला — कार्यप्रवाह, घटनाहरू, CI र CD Kubernetes।

अन्य उपकरण र समाधान

धेरै क्लस्टरहरू जडान र व्यवस्थापन एक जटिल कार्य हो, र त्यहाँ कुनै विश्वव्यापी समाधान छैन।

यदि तपाईं यस विषयलाई थप अन्वेषण गर्न चाहनुहुन्छ भने, यहाँ केही स्रोतहरू छन्:

• Rancher द्वारा पनडुब्बी विभिन्न Kubernetes क्लस्टरहरूको ओभरले नेटवर्कहरू जडान गर्ने उपकरण हो।
• रिटेल चेन लक्ष्य प्रयोग गर्दछ Unimatrix Spinnaker सँग धेरै क्लस्टरहरूमा डिप्लोइमेन्ट अर्केस्ट्रेट गर्न.
• IPV6 प्रयोग गरी हेर्नुहोस् धेरै क्षेत्रहरूमा एकल नेटवर्क.
• उदाहरणका लागि, तपाईं सेवा जाल प्रयोग गर्न सक्नुहुन्छ धेरै क्लस्टरहरू जडान गर्नको लागि Istio.
• Cilium, एक कन्टेनर नेटवर्क इन्टरफेस प्लगइन, प्रस्ताव गर्दछ क्लस्टर जाल प्रकार्य, जसले तपाईंलाई धेरै क्लस्टरहरू संयोजन गर्न अनुमति दिन्छ

आजको लागि यति हो

अन्त सम्म पढ्न को लागी धन्यवाद!

यदि तपाईलाई धेरै क्लस्टरहरू थप कुशलतापूर्वक जडान गर्ने तरिका थाहा छ भने, हामीलाई भन्नुहोस्.

हामी तपाइँको विधि लिङ्कहरूमा थप्नेछौं।

क्रिस नेस्बिट-स्मिथलाई विशेष धन्यवाद (क्रिस नेस्बिट-स्मिथ) र भिन्सेन्ट डे स्मे (भिन्सेन्ट डे स्मेट) (विश्वसनीयता इन्जिनियर मा swatmobile.ioलेख पढ्न र महासंघले कसरी काम गर्छ भन्ने बारे उपयोगी जानकारी साझा गर्नको लागि।

स्रोत: www.habr.com