Kubernetes #1 मा क्यानरी तैनाती: Gitlab CI

Kubernetes मा क्यानरी डिप्लोइमेन्ट लागू गर्न र प्रयोग गर्न हामी Gitlab CI र म्यानुअल GitOps प्रयोग गर्नेछौं।

यस श्रृंखलाबाट लेखहरू:

(यो लेख)
ArgoCI प्रयोग गरेर क्यानरी तैनाती
Istio प्रयोग गरेर क्यानरी तैनाती
Jenkins-X Istio Flagger प्रयोग गरेर क्यानरी डिप्लोइमेन्ट

हामी GitOps मार्फत क्यानरी डिप्लोइमेन्ट म्यानुअल रूपमा गर्नेछौं र मुख्य Kubernetes स्रोतहरू सिर्जना/परिमार्जन गर्नेछौं। यो लेख मुख्य रूपमा परिचयको लागि हो Kubernetes Canary मा डिप्लोइमेन्ट कसरी काम गर्दछ, किनकि त्यहाँ स्वचालनका थप प्रभावकारी विधिहरू छन्, जसलाई हामी निम्न लेखहरूमा विचार गर्नेछौं।

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

क्यानरी तैनाती

क्यानरी रणनीतिको साथ, अपडेटहरू पहिले प्रयोगकर्ताहरूको एक उपसमूहमा लागू हुन्छन्। निगरानी, लग डेटा, म्यानुअल परीक्षण, वा अन्य प्रतिक्रिया च्यानलहरू मार्फत, रिलीज सबै प्रयोगकर्ताहरूलाई जारी गर्नु अघि परीक्षण गरिन्छ।

Kubernetes तैनाती (रोलिङ अपडेट)

Kubernetes डिप्लोइमेन्टको लागि पूर्वनिर्धारित रणनीति रोलिङ-अपडेट हो, जहाँ छविहरूको नयाँ संस्करणहरूसँग निश्चित संख्यामा पोडहरू सुरू गरिन्छ। यदि तिनीहरू समस्या बिना सिर्जना गरिएको थियो भने, छविहरूको पुरानो संस्करणहरूसँग पोडहरू समाप्त हुन्छन्, र नयाँ पोडहरू समानान्तर रूपमा सिर्जना हुन्छन्।

GitOps

हामी यस उदाहरणमा GitOps प्रयोग गर्दछौं किनभने हामी:

सत्यको एकल स्रोतको रूपमा Git प्रयोग गर्दै
हामी निर्माण र तैनातीका लागि Git अपरेशनहरू प्रयोग गर्छौं (गिट ट्याग/मर्ज बाहेक अरू कुनै आदेशहरू आवश्यक पर्दैन)

उदाहरण:

एउटा राम्रो अभ्यास गरौं - एप्लिकेसन कोडको लागि एउटा भण्डार र एक पूर्वाधारको लागि।

आवेदन भण्डार

यो एक धेरै सरल पाइथन + फ्लास्क 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 आफ्नो क्लस्टरमा।

तपाईं क्लस्टर (Gcloud) को लागि प्रमाणहरू कसरी प्राप्त गर्ने बारे पढ्न सक्नुहुन्छ। ठीक छ.

पूर्वाधार यामल

पूर्वाधार भण्डारमा हामीसँग सेवा छ:

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 निम्न आउटपुट गर्नुपर्छ:

हामी देख्छौं app 10 प्रतिकृतिहरू र 0 सँग एप-क्यानरीको साथ तैनाती। त्यहाँ एक लोड ब्यालेन्सर पनि छ जसबाट हामी पहुँच गर्न सक्छौं। curl बाह्य आईपी मार्फत:

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

हामी देख्छौं कि हाम्रो परीक्षण अनुप्रयोगले मात्र "v1" फर्काउँछ।

क्यानरी तैनाती कार्यान्वयन गर्दै

चरण 1: केहि प्रयोगकर्ताहरूको लागि नयाँ संस्करण जारी गर्नुहोस्

हामीले deploy-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 मार्फत) र परिणामको रूपमा हेर्नुहोस्:

हाम्रो सेवाले दुबै डिप्लोइमेन्टलाई औंल्याउछ, किनकि दुबैमा एप चयनकर्ता छ। Kubernetes को पूर्वनिर्धारित अनियमितताको कारणले, हामीले अनुरोधहरूको ~ 10% को लागि फरक प्रतिक्रियाहरू हेर्नुपर्दछ:

हाम्रो एप्लिकेसनको हालको अवस्था (GitOps, सत्यको एकल स्रोतको रूपमा Git बाट लिइएको) प्रत्येक संस्करणको लागि सक्रिय प्रतिकृतिहरू सहित दुई डिप्लोइमेन्टहरूको उपस्थिति हो।

~ 10% प्रयोगकर्ताहरू नयाँ संस्करणसँग परिचित हुन्छन् र अनजानमा यसलाई परीक्षण गर्छन्। अब समस्याहरू फेला पार्न लगहरू र निगरानी डेटामा त्रुटिहरूको लागि जाँच गर्ने समय हो।

चरण 2: सबै प्रयोगकर्ताहरूलाई नयाँ संस्करण जारी गर्नुहोस्

हामीले निर्णय गर्यौं कि सबै कुरा राम्ररी गयो र अब हामीले सबै प्रयोगकर्ताहरूलाई नयाँ संस्करण रोल आउट गर्न आवश्यक छ। यो गर्नको लागि हामी केवल अपडेट गर्छौं deploy.yaml छविको नयाँ संस्करण स्थापना गर्दै र 10 बराबर प्रतिकृतिहरूको संख्या deploy-canary.yaml हामीले प्रतिकृतिहरूको संख्यालाई ० मा सेट गर्छौं। डिप्लोइमेन्ट पछि, नतिजा निम्नानुसार हुनेछ:

संक्षेप गर्न

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

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

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

हाम्रो ब्लगमा अन्य लेखहरू पनि पढ्नुहोस्:

स्रोत: www.habr.com