कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

कुबेरनेट्स में कैनरी परिनियोजन को लागू करने और उपयोग करने के लिए हम Gitlab CI और मैन्युअल GitOps का उपयोग करेंगे

कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

इस श्रृंखला के लेख:

हम GitOps के माध्यम से मैन्युअल रूप से कैनरी परिनियोजन करेंगे और मुख्य Kubernetes संसाधनों को बनाएंगे/संशोधित करेंगे। यह आलेख मुख्य रूप से परिचय के लिए है कुबेरनेट्स कैनरी में तैनाती कैसे काम करती है, क्योंकि स्वचालन के अधिक प्रभावी तरीके हैं, जिन पर हम निम्नलिखित लेखों में विचार करेंगे।


कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

https://www.norberteder.com/canary-deployment/

कैनरी परिनियोजन

कैनरी रणनीति के साथ, अपडेट पहले केवल उपयोगकर्ताओं के एक सबसेट पर लागू होते हैं। निगरानी, ​​लॉग डेटा, मैन्युअल परीक्षण या अन्य फीडबैक चैनलों के माध्यम से, सभी उपयोगकर्ताओं के लिए रिलीज़ होने से पहले रिलीज़ का परीक्षण किया जाता है।

कुबेरनेट्स परिनियोजन (रोलिंग अद्यतन)

कुबेरनेट्स परिनियोजन के लिए डिफ़ॉल्ट रणनीति रोलिंग-अपडेट है, जहां छवियों के नए संस्करणों के साथ एक निश्चित संख्या में पॉड्स लॉन्च किए जाते हैं। यदि वे बिना किसी समस्या के बनाए गए थे, तो छवियों के पुराने संस्करणों वाले पॉड समाप्त हो जाते हैं, और समानांतर में नए पॉड बनाए जाते हैं।

GitOps

हम इस उदाहरण में GitOps का उपयोग करते हैं क्योंकि हम:

  • सत्य के एकल स्रोत के रूप में Git का उपयोग करना
  • हम निर्माण और परिनियोजन के लिए Git ऑपरेशंस का उपयोग करते हैं (git टैग/मर्ज के अलावा किसी अन्य कमांड की आवश्यकता नहीं है)

उदाहरण

आइए एक अच्छा अभ्यास करें - एप्लिकेशन कोड के लिए एक रिपॉजिटरी और बुनियादी ढांचे के लिए एक रिपॉजिटरी रखें।

अनुप्रयोग भंडार

यह एक बहुत ही सरल Python+Flask API है जो JSON के रूप में प्रतिक्रिया देता है। हम GitlabCI के माध्यम से पैकेज बनाएंगे और परिणाम को Gitlab रजिस्ट्री पर भेजेंगे। रजिस्ट्री में हमारे पास दो अलग-अलग रिलीज़ संस्करण हैं:

  • wuestkamp/k8s-deployment-example-app:v1
  • wuestkamp/k8s-deployment-example-app:v2

उनके बीच एकमात्र अंतर लौटाई गई JSON फ़ाइल में परिवर्तन है। हम इस एप्लिकेशन का उपयोग यथासंभव आसानी से कल्पना करने के लिए करते हैं कि हम किस संस्करण के साथ संचार कर रहे हैं।

अवसंरचना भंडार

इस शलजम में हम GitlabCI के माध्यम से Kubernetes पर तैनात करेंगे, .gitlab-ci.yml निम्नानुसार है:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

इसे स्वयं चलाने के लिए आपको एक क्लस्टर की आवश्यकता होगी, आप Gcloud का उपयोग कर सकते हैं:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

आपको कांटा लगाने की जरूरत है https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure और एक वेरिएबल बनाएं KUBECONFIG GitlabCI में, जिसमें एक्सेस के लिए कॉन्फ़िगरेशन शामिल होगा kubectl आपके क्लस्टर के लिए.

आप क्लस्टर के लिए क्रेडेंशियल कैसे प्राप्त करें (जीक्लाउड) के बारे में पढ़ सकते हैं यहां.

इन्फ्रास्ट्रक्चर यमल

बुनियादी ढांचे के भंडार में हमारे पास सेवा है:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

और में तैनाती deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

और में एक और तैनाती deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ध्यान दें कि ऐप-परिनियोजन में अभी तक कोई प्रतिकृति परिभाषित नहीं है।

प्रारंभिक परिनियोजन निष्पादित करना

प्रारंभिक तैनाती शुरू करने के लिए, आप मास्टर शाखा पर मैन्युअल रूप से GitlabCI पाइपलाइन शुरू कर सकते हैं। इसके बाद kubectl निम्नलिखित आउटपुट देना चाहिए:

कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

हम देखते हैं app 10 प्रतिकृतियों के साथ परिनियोजन और 0 के साथ ऐप-कैनरी। एक लोडबैलेंसर भी है जिससे हम पहुंच सकते हैं curl बाहरी आईपी के माध्यम से:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

हम देखते हैं कि हमारा परीक्षण एप्लिकेशन केवल "v1" लौटाता है।

कैनरी परिनियोजन निष्पादित करना

चरण 1: कुछ उपयोगकर्ताओं के लिए एक नया संस्करण जारी करें

हमने परिनियोजन-canary.yaml फ़ाइल और नई संस्करण छवि में प्रतिकृतियों की संख्या 1 निर्धारित की है:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

फाइल मैं deploy.yaml हमने प्रतिकृतियों की संख्या बदलकर 9 कर दी है:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

हम इन परिवर्तनों को रिपॉजिटरी में धकेलते हैं जहाँ से तैनाती शुरू होगी (GitlabCI के माध्यम से) और परिणाम के रूप में देखेंगे:

कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

हमारी सेवा दोनों परिनियोजन को इंगित करेगी, क्योंकि दोनों में ऐप चयनकर्ता है। कुबेरनेट्स के डिफ़ॉल्ट रैंडमाइजेशन के कारण, हमें ~10% अनुरोधों के लिए अलग-अलग प्रतिक्रियाएँ देखनी चाहिए:

कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

हमारे एप्लिकेशन की वर्तमान स्थिति (GitOps, Git से सत्य के एकल स्रोत के रूप में ली गई) सक्रिय प्रतिकृतियों के साथ दो तैनाती की उपस्थिति है, प्रत्येक संस्करण के लिए एक।

~10% उपयोगकर्ता नए संस्करण से परिचित हो जाते हैं और अनजाने में उसका परीक्षण करते हैं। अब लॉग में त्रुटियों की जांच करने और समस्याओं का पता लगाने के लिए डेटा की निगरानी करने का समय आ गया है।

चरण 2: सभी उपयोगकर्ताओं के लिए नया संस्करण जारी करें

हमने तय किया कि सब कुछ ठीक रहा और अब हमें सभी उपयोगकर्ताओं के लिए नया संस्करण पेश करना होगा। ऐसा करने के लिए हम बस अपडेट करते हैं deploy.yaml छवि का एक नया संस्करण स्थापित करना और प्रतिकृतियों की संख्या 10 के बराबर deploy-canary.yaml हमने प्रतिकृतियों की संख्या वापस 0 पर सेट की है। तैनाती के बाद, परिणाम इस प्रकार होगा:

कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई

उपसंहार

मेरे लिए, इस तरह से परिनियोजन को मैन्युअल रूप से चलाने से यह समझने में मदद मिलती है कि k8s का उपयोग करके इसे कितनी आसानी से कॉन्फ़िगर किया जा सकता है। चूंकि कुबेरनेट्स आपको एपीआई के माध्यम से सब कुछ अपडेट करने की अनुमति देता है, इसलिए इन चरणों को स्क्रिप्ट के माध्यम से स्वचालित किया जा सकता है।

एक और चीज जिसे लागू करने की आवश्यकता है वह एक परीक्षक प्रवेश बिंदु (लोडबैलेंसर या इनग्रेस के माध्यम से) है जिसके माध्यम से केवल नए संस्करण तक पहुंचा जा सकता है। इसका उपयोग मैन्युअल ब्राउजिंग के लिए किया जा सकता है।

भविष्य के लेखों में, हम अन्य स्वचालित समाधानों की जाँच करेंगे जो हमारे द्वारा किए गए अधिकांश कार्यों को लागू करते हैं।

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

स्रोत: www.habr.com

एक टिप्पणी जोड़ें