कुबर्नेट्समध्ये तैनात करण्याच्या धोरणे: रोलिंग, रीक्रिएट, निळा/हिरवा, कॅनरी, गडद (A/B चाचणी)

नोंद भाषांतर: Weaveworks चे हे विहंगावलोकन सर्वात लोकप्रिय ॲप्लिकेशन रोलआउट स्ट्रॅटेजीज सादर करते आणि Kubernetes Flagger ऑपरेटर वापरून सर्वात प्रगत योजना कशा लागू केल्या जाऊ शकतात हे दाखवते. हे सोप्या भाषेत लिहिलेले आहे आणि त्यात व्हिज्युअल आकृत्या आहेत ज्यामुळे अगदी नवशिक्या अभियंत्यांना समस्या समजू शकतात.

रेखाचित्र वरून घेतले आहे आणखी एक पुनरावलोकन कंटेनर सोल्यूशन्समध्ये तयार केलेल्या रोलआउट धोरणे

आज क्लाउड नेटिव्ह ॲप्लिकेशन्स विकसित करण्यामधील सर्वात मोठे आव्हान म्हणजे तैनाती वाढवणे. मायक्रो सर्व्हिसेस पध्दतीमध्ये, डेव्हलपर आधीपासून पूर्णपणे मॉड्यूलर ॲप्लिकेशन्ससह काम करतात आणि डिझाइन करतात, ज्यामुळे वेगवेगळ्या टीम्सना एकाच वेळी कोड लिहिण्याची आणि ॲप्लिकेशनमध्ये बदल करण्याची परवानगी मिळते.

लहान आणि अधिक वारंवार उपयोजनांचे खालील फायदे आहेत:

• बाजारासाठी लागणारा वेळ कमी होतो.
• नवीन वैशिष्ट्ये वापरकर्त्यांपर्यंत जलद पोहोचतात.
• वापरकर्ता अभिप्राय विकास कार्यसंघापर्यंत जलद पोहोचतो. याचा अर्थ कार्यसंघ वैशिष्ट्ये जोडू शकतो आणि समस्या अधिक जलद निराकरण करू शकतो.
• डेव्हलपरचे मनोबल वाढते: डेव्हलपमेंटमधील अधिक वैशिष्ट्यांसह काम करणे अधिक मनोरंजक आहे.

परंतु रिलीझची वारंवारता जसजशी वाढते तसतसे अनुप्रयोगाच्या विश्वासार्हतेवर किंवा वापरकर्त्याच्या अनुभवावर नकारात्मक परिणाम होण्याची शक्यता देखील वाढते. म्हणूनच ऑपरेशन्स आणि DevOps संघांसाठी प्रक्रिया तयार करणे आणि उपयोजन धोरणे अशा प्रकारे व्यवस्थापित करणे महत्वाचे आहे की ज्यामुळे उत्पादन आणि वापरकर्त्यांना धोका कमी होईल. (तुम्ही CI/CD पाइपलाइन ऑटोमेशनबद्दल अधिक जाणून घेऊ शकता येथे.)

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

उपयोजन धोरणे

तुमच्या ध्येयानुसार तुम्ही वापरू शकता अशा अनेक प्रकारच्या उपयोजन धोरणे आहेत. उदाहरणार्थ, तुम्हाला पुढील चाचणीसाठी विशिष्ट वातावरणात किंवा वापरकर्त्यांच्या/क्लायंटच्या उपसंचात बदल करावे लागतील किंवा वैशिष्ट्य बनवण्यापूर्वी तुम्हाला मर्यादित वापरकर्ता चाचणी करण्याची आवश्यकता असू शकते. सार्वजनिक.

रोलिंग (हळूहळू, "रोलिंग" उपयोजन)

कुबर्नेट्स मधील ही मानक उपयोजन धोरण आहे. हे हळूहळू, एकामागून एक, क्लस्टर डाउनटाइमशिवाय - नवीन आवृत्तीसह पॉड्ससह ऍप्लिकेशनच्या जुन्या आवृत्तीसह पॉड्स पुनर्स्थित करते.

नवीन शेंगा काम करण्यासाठी तयार होईपर्यंत कुबर्नेट्स प्रतीक्षा करतात (त्यांना वापरून तपासत आहे तयारी चाचण्या), तुम्ही जुने गुंडाळणे सुरू करण्यापूर्वी. समस्या उद्भवल्यास, संपूर्ण क्लस्टर न थांबवता हे रोलिंग अपडेट रद्द केले जाऊ शकते. उपयोजन प्रकाराचे वर्णन करणाऱ्या YAML फाइलमध्ये, नवीन प्रतिमा जुन्या प्रतिमेची जागा घेते:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

रोलओव्हर अपडेट पॅरामीटर्स मॅनिफेस्ट फाइलमध्ये निर्दिष्ट केले जाऊ शकतात:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

पुन्हा तयार करा

या सोप्या प्रकारच्या उपयोजनामध्ये, जुन्या शेंगा एकाच वेळी मारल्या जातात आणि नवीन शेंगा बदलल्या जातात:

संबंधित मॅनिफेस्ट असे काहीतरी दिसते:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

निळा/हिरवा (निळा-हिरवा उपयोजन)

निळ्या-हिरव्या उपयोजन धोरणात (कधीकधी लाल/काळा देखील म्हणतात) अनुप्रयोगाच्या जुन्या (हिरव्या) आणि नवीन (निळ्या) आवृत्त्यांचा एकाचवेळी तैनाती समाविष्ट आहे. दोन्ही आवृत्त्या पोस्ट केल्यानंतर, नियमित वापरकर्त्यांना हिरव्या रंगात प्रवेश असतो, तर निळा एक स्वतंत्र सेवा किंवा थेट पोर्ट फॉरवर्डिंगद्वारे चाचणी स्वयंचलित करण्यासाठी QA टीमसाठी उपलब्ध असतो:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

निळ्या (नवीन) आवृत्तीची चाचणी झाल्यानंतर आणि तिचे प्रकाशन मंजूर झाल्यानंतर, सेवा त्यावर स्विच करते आणि हिरवी (जुनी) आवृत्ती दुमडली जाते:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

कॅनरी (कॅनरी उपयोजन)

कॅनरी रोलआउट्स निळ्या-हिरव्या रोलआउट्ससारखेच असतात, परंतु त्यांचे नियंत्रण आणि वापर अधिक चांगले असते पुरोगामी चरण-दर-चरण दृष्टीकोन. या प्रकारात "स्टिल्थ" लाँच आणि A/B चाचणीसह अनेक भिन्न धोरणे समाविष्ट आहेत.

जेव्हा काही नवीन कार्यक्षमता वापरून पाहण्याची आवश्यकता असते तेव्हा ही रणनीती वापरली जाते, सहसा अनुप्रयोगाच्या बॅकएंडमध्ये. दृष्टिकोनाचे सार दोन जवळजवळ एकसारखे सर्व्हर तयार करणे आहे: एक जवळजवळ सर्व वापरकर्त्यांना सेवा देतो आणि दुसरा, नवीन फंक्शन्ससह, वापरकर्त्यांचा फक्त एक छोटा उपसमूह सर्व्ह करतो, ज्यानंतर त्यांच्या कार्याच्या परिणामांची तुलना केली जाते. सर्व काही त्रुटींशिवाय होत असल्यास, नवीन आवृत्ती हळूहळू संपूर्ण पायाभूत सुविधांमध्ये आणली जाईल.

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

उदाहरणार्थ, तुमच्याकडे Git मध्ये दोन भिन्न मॅनिफेस्ट असू शकतात: टॅग 0.1.0 सह नियमित मॅनिफेस्ट आणि 0.2.0 टॅगसह कॅनरी मॅनिफेस्ट. Istio आभासी गेटवे मॅनिफेस्टमधील वजन बदलून, तुम्ही या दोन उपयोजनांमधील रहदारीचे वितरण नियंत्रित करू शकता:

Istio वापरून कॅनरी उपयोजनांची अंमलबजावणी करण्यासाठी चरण-दर-चरण मार्गदर्शकासाठी, पहा Istio सह GitOps वर्कफ्लो. (नोंद. अनुवाद: आम्ही कॅनरी रोलआउट्स बद्दलची सामग्री देखील Istio मध्ये भाषांतरित केली येथे.)

Weaveworks फ्लॅगरसह कॅनरी तैनाती

Weaveworks ध्वजांकित तुम्हाला कॅनरी रोलआउट्स सहज आणि प्रभावीपणे व्यवस्थापित करण्यास अनुमती देते.

फ्लॅगर ऑटोमेट त्यांच्यासोबत काम करतात. हे ट्रॅफिक मार्ग आणि स्विच करण्यासाठी Istio किंवा AWS ॲप मेश आणि परिणामांचे विश्लेषण करण्यासाठी Prometheus मेट्रिक्स वापरते. याव्यतिरिक्त, कॅनरी उपयोजनांचे विश्लेषण स्वीकृती चाचण्या, लोड चाचण्या आणि इतर कोणत्याही प्रकारच्या तपासण्या करण्यासाठी वेबहुकसह पूरक केले जाऊ शकते.

Kubernetes तैनातीवर आधारित आणि, आवश्यक असल्यास, पॉड्सचे क्षैतिज स्केलिंग (HPA), फ्लॅगर कॅनरी उपयोजनांचे विश्लेषण आणि अंमलबजावणी करण्यासाठी ऑब्जेक्ट्सचे संच (कुबरनेट डिप्लॉयमेंट्स, क्लस्टरआयपी सेवा आणि Istio किंवा ॲप मेश व्हर्च्युअल सेवा) तयार करतो:

नियंत्रण लूप लागू करणे (नियंत्रण लूप),फ्लेगर हळूहळू कॅनरी सर्व्हरवर रहदारी स्विच करते, त्याचवेळी यशस्वी HTTP विनंत्यांची टक्केवारी, सरासरी विनंती कालावधी आणि पॉड हेल्थ यासारख्या प्रमुख कार्यप्रदर्शन मेट्रिक्सचे मापन करते. KPI (की परफॉर्मन्स इंडिकेटर्स) विश्लेषणावर आधारित, कॅनरी एकतर वाढते किंवा कोसळते आणि विश्लेषणाचे परिणाम स्लॅकमध्ये प्रकाशित केले जातात. या प्रक्रियेचे वर्णन आणि प्रात्यक्षिक सामग्रीमध्ये आढळू शकते ॲप मेशसाठी प्रगतीशील वितरण.

गडद (लपलेले) किंवा A/B उपयोजन

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

या उपयोजनांचे दुसरे नाव A/B चाचणी आहे. नवीन वैशिष्ट्य सर्व वापरकर्त्यांसाठी उपलब्ध करून देण्याऐवजी, ते त्यांच्यापैकी केवळ मर्यादित भागांसाठी ऑफर केले जाते. सामान्यतः, या वापरकर्त्यांना हे माहित नसते की ते पायनियरिंग परीक्षक आहेत (म्हणून "स्टेल्थ डिप्लॉयमेंट" हा शब्द).

कार्यक्षमता स्विच वापरणे (वैशिष्ट्य टॉगल) आणि इतर साधने, वापरकर्ते नवीन वैशिष्ट्याशी कसे संवाद साधतात, ते त्यात गुंतलेले आहेत की नाही, किंवा त्यांना नवीन वापरकर्ता इंटरफेस गोंधळात टाकणारा आहे की नाही, आणि इतर प्रकारचे मेट्रिक्स हे तुम्ही निरीक्षण करू शकता.

फ्लॅगर आणि A/B उपयोजन

वजन-आधारित राउटिंग व्यतिरिक्त, फ्लॅगर HTTP पॅरामीटर्सवर आधारित कॅनरी सर्व्हरवर रहदारी देखील रूट करू शकतो. A/B चाचणीमध्ये, तुम्ही वापरकर्त्यांच्या विशिष्ट विभागाला लक्ष्य करण्यासाठी HTTP शीर्षलेख किंवा कुकीज वापरू शकता. हे विशेषतः फ्रंटएंड ऍप्लिकेशन्सच्या बाबतीत प्रभावी आहे ज्यांना सर्व्हरवर सत्र बंधनकारक असणे आवश्यक आहे (सत्र आत्मीयता). अधिक माहिती फ्लॅगर दस्तऐवजीकरणामध्ये आढळू शकते.

लेखक कृतज्ञता व्यक्त करतो स्टीफन प्रोडन, Weaveworks अभियंता (आणि Flagger चे निर्माता), या सर्व आश्चर्यकारक उपयोजन नमुन्यांसाठी.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्ससाठी इंग्रेस कंट्रोलर्सचे विहंगावलोकन आणि तुलना";
• «werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)";
• «werf आणि GitLab CI सह समान प्रकारच्या मायक्रोसर्व्हिसेस तयार करा आणि तैनात करा";
• «GitOps म्हणजे काय?».

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