विभिन्न डेटा केंद्रों में कुबेरनेट क्लस्टर्स को कैसे कनेक्ट करें

हमारी कुबेरनेट्स क्विक स्टार्ट श्रृंखला में आपका स्वागत है। यह एक नियमित कॉलम है जिसमें सबसे दिलचस्प प्रश्न हमें ऑनलाइन और हमारे प्रशिक्षणों में प्राप्त होते हैं। कुबेरनेट्स विशेषज्ञ उत्तर।

आज के विशेषज्ञ डेनियल पोलेन्चिक हैं (डेनिएल पोलेंसिक). डैनियल एक प्रशिक्षक और सॉफ्टवेयर डेवलपर के रूप में काम करता है जानेंk8s.

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

पिछली पोस्टें छूट गईं? उन्हें यहां खोजें.

विभिन्न डेटा केंद्रों में कुबेरनेट क्लस्टर्स को कैसे कनेक्ट करें?

संक्षिप्त: क्यूबफेड v2 जल्द ही आ रहा है, और मैं इसके बारे में पढ़ने की भी सलाह देता हूं shipper и मल्टी-क्लस्टर-अनुसूचक परियोजना.

अक्सर, बुनियादी ढांचे को विभिन्न क्षेत्रों में दोहराया और वितरित किया जाता है, खासकर नियंत्रित वातावरण में।

यदि एक क्षेत्र अनुपलब्ध है, तो रुकावटों से बचने के लिए ट्रैफ़िक को दूसरे क्षेत्र में पुनर्निर्देशित किया जाता है।

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

आपके पास प्रति टीम, क्षेत्र, परिवेश या इन तत्वों के संयोजन में एक या अधिक क्लस्टर हो सकते हैं।

आपके क्लस्टर को विभिन्न क्लाउड और ऑन-प्रिमाइसेस में होस्ट किया जा सकता है।

लेकिन आप ऐसे भौगोलिक प्रसार के लिए बुनियादी ढांचे की योजना कैसे बनाते हैं?
क्या आपको एक ही नेटवर्क पर कई क्लाउड परिवेशों के लिए एक बड़ा क्लस्टर बनाने की आवश्यकता है?
या क्या आपके पास कई छोटे क्लस्टर हैं और उन्हें नियंत्रित और सिंक्रनाइज़ करने का कोई तरीका ढूंढते हैं?

एक नेतृत्व समूह

एक ही नेटवर्क पर एक क्लस्टर बनाना इतना आसान नहीं है।

कल्पना कीजिए कि आपके साथ कोई दुर्घटना हुई है, क्लस्टर खंडों के बीच कनेक्टिविटी खो गई है।

यदि आपके पास एक मास्टर सर्वर है, तो आधे संसाधन नए कमांड प्राप्त नहीं कर पाएंगे क्योंकि वे मास्टर से संपर्क नहीं कर पाएंगे।

और साथ ही आपके पास पुरानी राउटिंग टेबल हैं (kube-proxy नए डाउनलोड नहीं कर सकते) और कोई अतिरिक्त पॉड नहीं (क्यूबलेट अपडेट का अनुरोध नहीं कर सकता)।

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

परिणामस्वरूप, आपके पास दोगुनी संख्या में पॉड्स हैं।

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

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

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

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

और चूंकि नियंत्रक एक नहीं, बल्कि अनेक हैं, एक श्रृंखला प्रतिक्रिया का परिणाम होता है और पूरा क्लस्टर बहुत धीमी गति से काम करना शुरू कर देता है.

आदि इतना विलंबता संवेदनशील है कि आधिकारिक दस्तावेज़ीकरण नियमित हार्ड ड्राइव के बजाय SSDs का उपयोग करने की अनुशंसा करता है.

वर्तमान में एकल क्लस्टर के लिए बड़े नेटवर्क का कोई अच्छा उदाहरण नहीं है।

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

विकल्प 1: क्यूबफेड के साथ क्लस्टर फेडरेशन

एसआईजी-क्लस्टर से आधिकारिक प्रतिक्रिया - kubefed2, मूल kube फ़ेडरेशन क्लाइंट और ऑपरेटर का एक नया संस्करण.

पहली बार, हमने क्यूब फ़ेडरेशन टूल का उपयोग करके क्लस्टर के संग्रह को एक ऑब्जेक्ट के रूप में प्रबंधित करने का प्रयास किया।

शुरुआत अच्छी थी, लेकिन अंत में क्यूब फेडरेशन कभी लोकप्रिय नहीं हो सका क्योंकि यह सभी संसाधनों का समर्थन नहीं करता था।

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

कल्पना करें कि आप केवल एनोटेशन का उपयोग करके फेडरेशन में प्रत्येक क्लस्टर के लिए प्रतिकृति विभाजन का वर्णन कैसे कर सकते हैं।

यह पूरी तरह गड़बड़ था.

क्यूबफेड v1 के बाद एसआईजी-क्लस्टर ने बहुत काम किया और समस्या को एक अलग कोण से देखने का फैसला किया।

एनोटेशन के बजाय, उन्होंने एक नियंत्रक जारी करने का निर्णय लिया जो क्लस्टर पर स्थापित है। इसे कस्टम रिसोर्स डेफिनिशन (सीआरडी) का उपयोग करके अनुकूलित किया जा सकता है।

प्रत्येक संसाधन के लिए जो फेडरेशन का हिस्सा होगा, आपके पास तीन खंडों के साथ एक कस्टम सीआरडी परिभाषा है:

• किसी संसाधन की मानक परिभाषा, उदाहरण के लिए परिनियोजन;
• अनुभाग 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 एक नया ReplicationSchedulingPreference ऑब्जेक्ट प्रदान करता है जहां प्रतिकृतियों को भारित किया जा सकता है:

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

सीआरडी संरचना और एपीआई अभी तक पूरी तरह से तैयार नहीं हैं, और आधिकारिक परियोजना भंडार में सक्रिय कार्य चल रहा है।

Kubefed2 पर नज़र रखें, लेकिन याद रखें कि यह अभी उत्पादन के लिए उपयुक्त नहीं है।

Kubefed2 के बारे में और जानें Kubefed2 के बारे में आधिकारिक लेख कुबेरनेट्स और इन के बारे में ब्लॉग में क्यूबफेड परियोजना का आधिकारिक भंडार.

विकल्प 2: बुकिंग.कॉम शैली में क्लस्टरों का संयोजन

बुकिंग.कॉम के डेवलपर्स ने क्यूबफेड वी2 पर काम नहीं किया, लेकिन वे शिपर के साथ आए - जो कई समूहों, कई क्षेत्रों और कई बादलों में डिलीवरी के लिए एक ऑपरेटर है।

shipper कुछ हद तक 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

शिपर कई समूहों के प्रबंधन के लिए एक अच्छा विकल्प है, लेकिन हेल्म के साथ इसका करीबी रिश्ता ही आड़े आता है।

क्या होगा अगर हम सभी हेल्म से स्विच करें अनुकूलित करें या kapitan?

शिपर और उसके दर्शन के बारे में और अधिक जानकारी प्राप्त करें यह आधिकारिक प्रेस विज्ञप्ति.

यदि आप कोड को गहराई से जानना चाहते हैं, आधिकारिक परियोजना भंडार पर जाएँ.

विकल्प 3: "जादुई" क्लस्टर विलय

क्यूबफेड v2 और शिपर क्लस्टर फेडरेशन के साथ काम करते हैं, कस्टम संसाधन परिभाषा के माध्यम से क्लस्टर को नए संसाधन प्रदान करते हैं।

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

YAML को बदले बिना किसी मौजूदा क्लस्टर को फ़ेडरेशन में कैसे शामिल करें?

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

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

प्रत्येक निर्मित पॉड को तुरंत एक डमी से बदल दिया जाता है।

मल्टी-क्लस्टर-शेड्यूलर का उपयोग एक्सेस संशोधन के लिए वेबहुककॉल को इंटरसेप्ट करने और एक निष्क्रिय डमी पॉड बनाने के लिए।

मूल पॉड एक अन्य नियोजन चक्र से गुजरता है, जहां पूरे महासंघ के मतदान के बाद, प्लेसमेंट का निर्णय लिया जाता है।

अंत में, पॉड को लक्ष्य क्लस्टर तक पहुंचा दिया जाता है।

परिणामस्वरूप, आपके पास एक अतिरिक्त पॉड है जो कुछ नहीं करता, बस जगह घेरता है।

लाभ यह है कि आपको आपूर्ति को संयोजित करने के लिए नए संसाधन लिखने की ज़रूरत नहीं है।

पॉड बनाने वाला प्रत्येक संसाधन स्वचालित रूप से विलय के लिए तैयार है।

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

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

इसमें उन्नत क्रमिक वितरण तंत्र नहीं है।

मल्टी-क्लस्टर-शेड्यूलर के बारे में अधिक जानकारी यहां पाई जा सकती है आधिकारिक भंडार पृष्ठ.

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

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

एकाधिक समूहों को जोड़ना और प्रबंधित करना एक जटिल कार्य है, और इसका कोई सार्वभौमिक समाधान नहीं है।

यदि आप इस विषय पर और अधिक विस्तार से जानना चाहते हैं, तो यहां कुछ संसाधन दिए गए हैं:

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

यह सभी आज के लिए है

अंत तक पढ़ने के लिए धन्यवाद!

यदि आप जानते हैं कि एकाधिक समूहों को अधिक कुशलता से कैसे जोड़ा जाए, हमें बताओ.

हम आपकी विधि को लिंक में जोड़ देंगे।

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

स्रोत: www.habr.com