Usambazaji wa Canary katika Kubernetes #1: Gitlab CI

Tutatumia Gitlab CI na GitOps ya mwongozo kutekeleza na kutumia uwekaji wa Canary huko Kubernetes.

Makala kutoka mfululizo huu:

• (Makala hii)
• Usambazaji wa Canary kwa kutumia ArgoCI
• Usambazaji wa Canary kwa kutumia Istio
• Usambazaji wa Canary kwa kutumia Bendera ya Jenkins-X Istio

Tutafanya uwekaji wa Canary sisi wenyewe kupitia GitOps na kuunda/kurekebisha rasilimali kuu za Kubernetes. Nakala hii imekusudiwa kimsingi kwa utangulizi na jinsi upelekaji unavyofanya kazi katika Kubernetes Canary, kwa kuwa kuna njia bora zaidi za automatisering, ambazo tutazingatia katika makala zifuatazo.

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

Usambazaji wa Canary

Kwa mkakati wa Canary, masasisho yanatumiwa kwanza kwa kikundi kidogo cha watumiaji. Kupitia ufuatiliaji, data ya kumbukumbu, majaribio ya mikono, au njia zingine za maoni, toleo hujaribiwa kabla ya kutolewa kwa watumiaji wote.

Usambazaji wa Kubernetes (sasisho linaloendelea)

Mkakati chaguo-msingi wa Kubernetes Deployment ni usasishaji unaoendelea, ambapo idadi fulani ya maganda huzinduliwa kwa matoleo mapya ya picha. Ikiwa ziliundwa bila matatizo, maganda yenye matoleo ya zamani ya picha yanasitishwa, na maganda mapya yanaundwa kwa sambamba.

GitOps

Tunatumia GitOps katika mfano huu kwa sababu sisi:

• kutumia Git kama chanzo kimoja cha ukweli
• tunatumia Uendeshaji wa Git kwa ajili ya kujenga na kupeleka (hakuna amri nyingine isipokuwa git tag/merge zinahitajika)

Mfano

Wacha tufanye mazoezi mazuri - kuwa na hazina moja ya nambari ya maombi na moja ya miundombinu.

Hifadhi ya maombi

Hii ni API rahisi sana ya Python+Flask ambayo inarudisha jibu kama JSON. Tutaunda kifurushi kupitia GitlabCI na kusukuma matokeo kwenye Usajili wa Gitlab. Katika Usajili tuna matoleo mawili tofauti ya kutolewa:

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

Tofauti pekee kati yao ni mabadiliko katika faili iliyorejeshwa ya JSON. Tunatumia programu hii kuibua kwa urahisi iwezekanavyo ni toleo gani tunawasiliana nalo.

Hifadhi ya miundombinu

Katika turnip hii tutapeleka kupitia GitlabCI hadi Kubernetes, .gitlab-ci.yml inaonekana kama hii:

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

Ili kuiendesha mwenyewe utahitaji nguzo, unaweza kutumia Gcloud:

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

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

Unahitaji uma https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure na unda kigezo KUBECONFIG katika GitlabCI, ambayo itakuwa na usanidi wa ufikiaji kubectl kwa nguzo yako.

Unaweza kusoma kuhusu jinsi ya kupata vitambulisho kwa nguzo (Gcloud) hapa.

Miundombinu Yaml

Katika hazina ya miundombinu tunayo huduma:

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

Na kupelekwa ndani 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

Na kupelekwa kwingine ndani 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

Kumbuka kuwa programu-tumizi haina nakala zozote zilizofafanuliwa.

Kufanya uwekaji wa awali

Ili kuanza upelekaji wa awali, unaweza kuanza bomba la GitlabCI kwa mikono kwenye tawi kuu. Baada ya hapo kubectl inapaswa kutoa zifuatazo:

Tunaona app kupelekwa kwa nakala 10 na canary ya programu na 0. Pia kuna LoadBalancer ambayo tunaweza kufikia kupitia curl kupitia IP ya Nje:

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

Tunaona kwamba maombi yetu ya jaribio yanarudisha "v1" pekee.

Inatekeleza uwekaji wa Canary

Hatua ya 1: toa toleo jipya kwa baadhi ya watumiaji

Tunaweka idadi ya nakala kuwa 1 katika faili ya deploy-canary.yaml na picha ya toleo jipya:

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

Katika faili deploy.yaml tulibadilisha idadi ya nakala hadi 9:

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

Tunasukuma mabadiliko haya kwenye hazina ambayo uwekaji utaanza (kupitia GitlabCI) na kuona kama matokeo:

Huduma yetu itaelekeza kwenye matumizi yote mawili, kwa kuwa zote zina kiteuzi cha programu. Kwa sababu ya kubahatisha chaguo-msingi ya Kubernetes, tunapaswa kuona majibu tofauti kwa ~10% ya maombi:

Hali ya sasa ya programu yetu (GitOps, iliyochukuliwa kutoka Git kama Chanzo Kimoja cha Ukweli) ni uwepo wa uwekaji wa nakala mbili zenye nakala amilifu, moja kwa kila toleo.

~10% ya watumiaji hufahamu toleo jipya na kulijaribu bila kukusudia. Sasa ni wakati wa kuangalia makosa katika kumbukumbu na data ya ufuatiliaji ili kupata matatizo.

Hatua ya 2: Toa toleo jipya kwa watumiaji wote

Tuliamua kuwa kila kitu kilikwenda vizuri na sasa tunahitaji kusambaza toleo jipya kwa watumiaji wote. Ili kufanya hivyo, tunasasisha tu deploy.yaml kusakinisha toleo jipya la picha na idadi ya nakala sawa na 10. In deploy-canary.yaml tunaweka idadi ya nakala nyuma hadi 0. Baada ya kupelekwa, matokeo yatakuwa kama ifuatavyo:

Akihitimisha

Kwangu, kuendesha upelekaji kwa mikono kwa njia hii husaidia kuelewa jinsi inavyoweza kusanidiwa kwa urahisi kwa kutumia k8s. Kwa kuwa Kubernetes hukuruhusu kusasisha kila kitu kupitia API, hatua hizi zinaweza kuendeshwa kiotomatiki kupitia hati.

Jambo lingine linalohitaji kutekelezwa ni sehemu ya kuingilia ya kijaribu (LoadBalancer au kupitia Ingress) ambayo ni toleo jipya pekee linaweza kufikiwa. Inaweza kutumika kwa kuvinjari kwa mikono.

Katika makala zijazo, tutaangalia masuluhisho mengine ya kiotomatiki ambayo yanatekeleza mengi ambayo tumefanya.

Pia soma nakala zingine kwenye blogi yetu:

• Je, uhamiaji kutoka kwa ClickHouse bila idhini kwenda kwa ClickHouse kwa idhini ulisababisha nini?
• Kuunda moduli zinazobadilika za Nginx
• Sasisha nxs-build-tools - msaidizi katika ujenzi wa madeni na vifurushi vya rpm
• Utangulizi wa Uidhinishaji wa Kubernetes wa Balozi wa Hashicorp
• Kile tulilazimika kukabili wakati wa kutumia matumizi ya Csync2
• Telegraph bot kwa Redmine. Jinsi ya kurahisisha maisha kwako na kwa wengine

Chanzo: mapenzi.com