🥇 Kubernetes मा तैनाती रणनीतिहरू: रोलिङ, पुन: सिर्जना, नीलो/हरियो, क्यानरी, गाढा (A/B परीक्षण)

नोट अनुवाद: Weaveworks को यो सिंहावलोकनले सबैभन्दा लोकप्रिय एप्लिकेसन रोलआउट रणनीतिहरू प्रस्तुत गर्दछ र Kubernetes Flagger अपरेटर प्रयोग गरेर कसरी सबैभन्दा उन्नतहरू लागू गर्न सकिन्छ भनेर देखाउँछ। यो सरल भाषामा लेखिएको छ र भिजुअल रेखाचित्रहरू समावेश गर्दछ जसले नयाँ इन्जिनियरहरूलाई पनि मुद्दा बुझ्न अनुमति दिन्छ।

रेखाचित्र बाट लिइएको हो अर्को समीक्षा कन्टेनर समाधानमा बनाइएको रोलआउट रणनीतिहरू

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

छोटो र अधिक बारम्बार तैनातीका निम्न फाइदाहरू छन्:

बजार जाने समय घटेको छ ।
नयाँ सुविधाहरू प्रयोगकर्ताहरू छिटो पुग्छन्।
प्रयोगकर्ता प्रतिक्रिया छिटो विकास टोली पुग्छ। यसको मतलब टोलीले सुविधाहरू थप्न र समस्याहरू छिटो समाधान गर्न सक्छ।
विकासकर्ता मनोबल बढ्छ: विकासमा थप सुविधाहरू काम गर्न थप रमाइलो छ।

तर रिलिजको फ्रिक्वेन्सी बढ्दै जाँदा, अनुप्रयोगको विश्वसनीयता वा प्रयोगकर्ता अनुभवमा नकारात्मक प्रभाव पार्ने सम्भावना पनि बढ्छ। यसैले अपरेशनहरू र DevOps टोलीहरूका लागि प्रक्रियाहरू निर्माण गर्न र उत्पादन र प्रयोगकर्ताहरूलाई जोखिम कम गर्ने तरिकामा डिप्लोइमेन्ट रणनीतिहरू प्रबन्ध गर्न महत्त्वपूर्ण छ। (तपाईं CI/CD पाइपलाइन स्वचालन बारे थप जान्न सक्नुहुन्छ यहाँ.)

यस पोष्टमा, हामी कुबर्नेट्समा विभिन्न परिनियोजन रणनीतिहरू, रोलिङ डिप्लोयमेन्टहरू र थप उन्नत विधिहरू जस्तै क्यानरी रोलआउटहरू र तिनीहरूको भिन्नताहरू सहित छलफल गर्नेछौं।

परिनियोजन रणनीतिहरू

त्यहाँ विभिन्न प्रकारका परिनियोजन रणनीतिहरू छन् जुन तपाईंले आफ्नो लक्ष्यको आधारमा प्रयोग गर्न सक्नुहुन्छ। उदाहरणका लागि, तपाईंले थप परीक्षणको लागि निश्चित वातावरणमा परिवर्तनहरू गर्न वा प्रयोगकर्ता/ग्राहकहरूको उपसमूहमा परिवर्तन गर्न आवश्यक हुन सक्छ, वा तपाईंले सुविधा बनाउनु अघि सीमित प्रयोगकर्ता परीक्षण गर्न आवश्यक हुन सक्छ। सार्वजनिक.

रोलिङ (क्रमिक, "रोलिङ" तैनाती)

यो Kubernetes मा मानक तैनाती रणनीति हो। यसले बिस्तारै, एक-एक गरेर, एप्लिकेसनको पुरानो संस्करणसँग पोडहरूलाई नयाँ संस्करणको साथ पोडहरू प्रतिस्थापन गर्दछ - क्लस्टर डाउनटाइम बिना।

Kubernetes नयाँ पोडहरू काम गर्न तयार नभएसम्म पर्खन्छ (तिनीहरूलाई प्रयोग गरेर जाँच गर्दै तयारी परीक्षण), तपाईंले पुरानाहरू रोल गर्न सुरु गर्नु अघि। यदि कुनै समस्या भयो भने, यो रोलिङ अद्यावधिक सम्पूर्ण क्लस्टरलाई रोक्न बिना रद्द गर्न सकिन्छ। 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

रोलओभर अपडेट प्यारामिटरहरू manifest फाइलमा निर्दिष्ट गर्न सकिन्छ:

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

पुन: सिर्जना गर्नुहोस्

यस सरल प्रकारको परिनियोजनमा, पुरानो पोडहरू एकैचोटि मारिन्छन् र नयाँहरूद्वारा प्रतिस्थापित हुन्छन्:

सम्बन्धित manifest केहि यस्तो देखिन्छ:

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 परीक्षण सहित धेरै फरक रणनीतिहरू समावेश गर्दछ।

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

यद्यपि यो रणनीति विशेष रूपमा Kubernetes प्रयोग गरेर लागू गर्न सकिन्छ, पुरानो पोडहरू नयाँहरूसँग बदलेर, यो Istio जस्तै सेवा जाल प्रयोग गर्न धेरै सुविधाजनक र सरल छ।

उदाहरणका लागि, तपाईंसँग Git मा दुई फरक manifests हुन सक्छ: ट्याग 0.1.0 संग एक नियमित manifest र ट्याग 0.2.0 संग एक क्यानरी प्रकट। Istio भर्चुअल गेटवे मेनिफेस्टमा वजनहरू परिवर्तन गरेर, तपाइँ यी दुई डिप्लोइमेन्टहरू बीचको ट्राफिकको वितरणलाई नियन्त्रण गर्न सक्नुहुन्छ:

Istio प्रयोग गरेर क्यानरी डिप्लोइमेन्टहरू लागू गर्न चरण-दर-चरण गाइडको लागि, हेर्नुहोस् Istio संग GitOps कार्यप्रवाह. (नोट। अनुवाद।: हामीले क्यानरी रोलआउटहरू बारे सामग्रीलाई Istio मा अनुवाद गर्यौं यहाँ.)

Weaveworks फ्ल्यागर संग क्यानरी तैनाती

Weaveworks फ्ल्यागर तपाईंलाई सजिलै र प्रभावकारी रूपमा क्यानरी रोलआउटहरू व्यवस्थापन गर्न अनुमति दिन्छ।

फ्ल्यागर स्वचालित तिनीहरूसँग काम गर्दछ। यसले Istio वा AWS एप मेसलाई ट्राफिक र स्विच गर्न र परिणामहरू विश्लेषण गर्न प्रोमेथियस मेट्रिक्स प्रयोग गर्दछ। थप रूपमा, क्यानरी डिप्लोइमेन्टहरूको विश्लेषणलाई स्वीकृति परीक्षणहरू, लोड परीक्षणहरू, र अन्य कुनै पनि प्रकारका जाँचहरू सञ्चालन गर्न वेबहुकहरूसँग पूरक गर्न सकिन्छ।

Kubernetes डिप्लोइमेन्टको आधारमा र, यदि आवश्यक भएमा, पोडको तेर्सो मापन (HPA), Flagger ले क्यानरी डिप्लोइमेन्टहरू विश्लेषण र कार्यान्वयन गर्न वस्तुहरूको सेटहरू (Kubernetes deployments, ClusterIP सेवाहरू र Istio वा App Mesh भर्चुअल सेवाहरू) सिर्जना गर्दछ:

नियन्त्रण लूप लागू गर्दै (नियन्त्रण लूप),फ्लेगरले बिस्तारै क्यानरी सर्भरमा ट्राफिक स्विच गर्छ, जबकि, सफल HTTP अनुरोधहरूको अनुपात, औसत अनुरोध अवधि, र पोडहरूको स्वास्थ्य जस्ता मुख्य कार्यसम्पादन सूचकहरू मापन गर्दै। KPI (कुञ्जी कार्यसम्पादन सूचक) विश्लेषणको आधारमा, क्यानरी कि त बढ्छ वा पतन हुन्छ र विश्लेषणको नतिजा Slack मा प्रकाशित गरिन्छ। यस प्रक्रियाको विवरण र प्रदर्शन सामग्रीमा फेला पार्न सकिन्छ एप मेषको लागि प्रगतिशील डेलिभरी.

गाढा (लुकेको) वा A/B परिनियोजनहरू

स्टेल्थ डिप्लोइमेन्ट क्यानरी रणनीतिको अर्को भिन्नता हो (जसलाई, फ्ल्यागरले पनि काम गर्न सक्छ)। स्टेल्थ र क्यानरी डिप्लोइमेन्टहरू बीचको भिन्नता यो हो कि स्टेल्थ डिप्लोयमेन्टहरूले क्यानरी डिप्लोइमेन्टहरू जस्तै ब्याकएन्ड भन्दा फ्रन्टएन्डसँग सम्झौता गर्दछ।

यी परिनियोजनहरूको अर्को नाम A/B परीक्षण हो। नयाँ सुविधा सबै प्रयोगकर्ताहरूलाई उपलब्ध गराउनुको सट्टा, यो तिनीहरूको सीमित भागलाई मात्र प्रस्ताव गरिएको छ। सामान्यतया, यी प्रयोगकर्ताहरूलाई थाहा छैन कि तिनीहरू अग्रगामी परीक्षक हुन् (यसैले "स्टेल्थ डिप्लोयमेन्ट" शब्द)।

कार्यक्षमता स्विचहरू प्रयोग गर्दै (सुविधा टगल) र अन्य उपकरणहरू, तपाइँ प्रयोगकर्ताहरूले नयाँ सुविधासँग कसरी अन्तर्क्रिया गर्छन् भनेर निगरानी गर्न सक्नुहुन्छ, उनीहरू यसमा संलग्न छन् कि छैनन्, वा उनीहरूले नयाँ प्रयोगकर्ता इन्टरफेस भ्रामक फेला पार्छन्, र अन्य प्रकारका मेट्रिकहरू।

फ्ल्यागर र A/B परिनियोजनहरू

वजन-आधारित राउटिङको अतिरिक्त, फ्ल्यागरले HTTP प्यारामिटरहरूमा आधारित क्यानरी सर्भरमा ट्राफिकलाई पनि रुट गर्न सक्छ। A/B परीक्षणमा, तपाइँ HTTP हेडर वा कुकीहरू प्रयोग गर्न सक्नुहुन्छ प्रयोगकर्ताहरूको विशिष्ट खण्डलाई लक्षित गर्न। यो विशेष गरी फ्रन्टएन्ड अनुप्रयोगहरूको मामलामा प्रभावकारी हुन्छ जसलाई सर्भरमा सत्र बाध्यकारी चाहिन्छ (सत्र आत्मीयता)। थप जानकारी फ्ल्यागर कागजातमा फेला पार्न सकिन्छ।

लेखक कृतज्ञता व्यक्त गर्दछ स्टेफन प्रोडान, Weaveworks इन्जिनियर (र Flagger को निर्माता), यी सबै अद्भुत तैनाती ढाँचाहरूको लागि।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

स्रोत: www.habr.com

Kubernetes मा तैनाती रणनीतिहरू: रोलिङ, पुन: सिर्जना, निलो/हरियो, क्यानरी, गाढा (A/B परीक्षण)