കുബർനെറ്റസിലെ കാനറി വിന്യാസം #1: Gitlab CI

Kubernetes-ൽ കാനറി വിന്യാസം നടപ്പിലാക്കുന്നതിനും ഉപയോഗിക്കുന്നതിനും ഞങ്ങൾ Gitlab CI, മാനുവൽ GitOps എന്നിവ ഉപയോഗിക്കും.

ഈ പരമ്പരയിലെ ലേഖനങ്ങൾ:

• (ഈ ലേഖനം)
• ArgoCI ഉപയോഗിച്ച് കാനറി വിന്യാസം
• ഇസ്തിയോ ഉപയോഗിച്ച് കാനറി വിന്യാസം
• Jenkins-X Istio Flagger ഉപയോഗിച്ചുള്ള കാനറി വിന്യാസം

GitOps വഴി ഞങ്ങൾ കാനറി വിന്യാസം സ്വമേധയാ നിർവഹിക്കുകയും പ്രധാന കുബർനെറ്റസ് ഉറവിടങ്ങൾ സൃഷ്ടിക്കുകയും/പരിഷ്‌ക്കരിക്കുകയും ചെയ്യും. ഈ ലേഖനം പ്രാഥമികമായി ആമുഖത്തിന് വേണ്ടിയുള്ളതാണ് കുബർനെറ്റസ് കാനറിയിൽ വിന്യാസം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനൊപ്പം, കൂടുതൽ ഫലപ്രദമായ ഓട്ടോമേഷൻ രീതികൾ ഉള്ളതിനാൽ, അത് ഞങ്ങൾ ഇനിപ്പറയുന്ന ലേഖനങ്ങളിൽ പരിഗണിക്കും.

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

കാനറി വിന്യാസം

കാനറി സ്ട്രാറ്റജി ഉപയോഗിച്ച്, അപ്ഡേറ്റുകൾ ആദ്യം പ്രയോഗിക്കുന്നത് ഉപയോക്താക്കളുടെ ഒരു ഉപവിഭാഗത്തിന് മാത്രമാണ്. നിരീക്ഷണം, ലോഗ് ഡാറ്റ, മാനുവൽ ടെസ്റ്റിംഗ് അല്ലെങ്കിൽ മറ്റ് ഫീഡ്‌ബാക്ക് ചാനലുകൾ എന്നിവയിലൂടെ, എല്ലാ ഉപയോക്താക്കൾക്കും റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് റിലീസ് പരീക്ഷിക്കുന്നു.

കുബർനെറ്റസ് വിന്യാസം (റോളിംഗ് അപ്‌ഡേറ്റ്)

Kubernetes വിന്യാസത്തിനുള്ള ഡിഫോൾട്ട് തന്ത്രം റോളിംഗ്-അപ്‌ഡേറ്റാണ്, അവിടെ ചിത്രങ്ങളുടെ പുതിയ പതിപ്പുകൾക്കൊപ്പം ഒരു നിശ്ചിത എണ്ണം പോഡുകൾ സമാരംഭിക്കുന്നു. അവ പ്രശ്‌നങ്ങളില്ലാതെ സൃഷ്‌ടിച്ചതാണെങ്കിൽ, ചിത്രങ്ങളുടെ പഴയ പതിപ്പുകളുള്ള പോഡുകൾ അവസാനിപ്പിക്കുകയും പുതിയ പോഡുകൾ സമാന്തരമായി സൃഷ്‌ടിക്കുകയും ചെയ്യും.

GitOps

ഈ ഉദാഹരണത്തിൽ ഞങ്ങൾ GitOps ഉപയോഗിക്കുന്നു കാരണം ഞങ്ങൾ:

• സത്യത്തിന്റെ ഒരൊറ്റ ഉറവിടമായി Git ഉപയോഗിക്കുന്നു
• നിർമ്മാണത്തിനും വിന്യാസത്തിനുമായി ഞങ്ങൾ Git ഓപ്പറേഷനുകൾ ഉപയോഗിക്കുന്നു (ജിറ്റ് ടാഗ്/ലയനം ഒഴികെയുള്ള കമാൻഡുകൾ ആവശ്യമില്ല)

ഉദാഹരണം:

നമുക്ക് ഒരു നല്ല ശീലം എടുക്കാം - ആപ്ലിക്കേഷൻ കോഡിനായി ഒരു ശേഖരവും ഇൻഫ്രാസ്ട്രക്ചറിനായി ഒന്ന്.

ആപ്ലിക്കേഷൻ ശേഖരം

ഇത് JSON ആയി ഒരു പ്രതികരണം നൽകുന്ന വളരെ ലളിതമായ ഒരു Python+Flask API ആണ്. ഞങ്ങൾ GitlabCI വഴി പാക്കേജ് നിർമ്മിക്കുകയും ഫലം Gitlab രജിസ്ട്രിയിലേക്ക് തള്ളുകയും ചെയ്യും. രജിസ്ട്രിയിൽ ഞങ്ങൾക്ക് രണ്ട് വ്യത്യസ്ത പതിപ്പുകൾ ഉണ്ട്:

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

തിരികെ നൽകിയ JSON ഫയലിലെ മാറ്റം മാത്രമാണ് അവ തമ്മിലുള്ള വ്യത്യാസം. ഏത് പതിപ്പുമായാണ് ഞങ്ങൾ ആശയവിനിമയം നടത്തുന്നതെന്ന് കഴിയുന്നത്ര എളുപ്പത്തിൽ ദൃശ്യവൽക്കരിക്കാൻ ഞങ്ങൾ ഈ ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്നു.

ഇൻഫ്രാസ്ട്രക്ചർ റിപ്പോസിറ്ററി

ഈ ടേണിപ്പിൽ ഞങ്ങൾ GitlabCI വഴി കുബർനെറ്റസിലേക്ക് വിന്യസിക്കും, .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) ക്രെഡൻഷ്യലുകൾ എങ്ങനെ നേടാം എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് വായിക്കാം. ഇവിടെ ഇതാ.

ഇൻഫ്രാസ്ട്രക്ചർ Yaml

ഇൻഫ്രാസ്ട്രക്ചർ റിപ്പോസിറ്ററിയിൽ ഞങ്ങൾക്ക് സേവനമുണ്ട്:

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 ബാഹ്യ IP വഴി:

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 വഴി) റിപ്പോസിറ്ററിയിലേക്ക് ഞങ്ങൾ ഈ മാറ്റങ്ങൾ വരുത്തുകയും അതിന്റെ ഫലമായി കാണുക:

രണ്ടിനും ആപ്പ് സെലക്ടർ ഉള്ളതിനാൽ ഞങ്ങളുടെ സേവനം രണ്ട് വിന്യാസങ്ങളിലേക്കും വിരൽ ചൂണ്ടും. കുബെർനെറ്റസിന്റെ ഡിഫോൾട്ട് റാൻഡമൈസേഷൻ കാരണം, ~10% അഭ്യർത്ഥനകൾക്ക് ഞങ്ങൾ വ്യത്യസ്ത പ്രതികരണങ്ങൾ കാണും:

ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ നിലവിലെ അവസ്ഥ (GitOps, Git-ൽ നിന്ന് സത്യത്തിന്റെ ഏക ഉറവിടമായി എടുത്തത്) സജീവമായ പകർപ്പുകളുള്ള രണ്ട് വിന്യാസങ്ങളുടെ സാന്നിധ്യമാണ്, ഓരോ പതിപ്പിനും ഒന്ന്.

~10% ഉപയോക്താക്കൾക്ക് ഒരു പുതിയ പതിപ്പ് പരിചിതമായിത്തീരുകയും അവിചാരിതമായി അത് പരീക്ഷിക്കുകയും ചെയ്യുന്നു. ലോഗുകളിലെ പിശകുകൾ പരിശോധിക്കാനും പ്രശ്നങ്ങൾ കണ്ടെത്തുന്നതിന് ഡാറ്റ നിരീക്ഷിക്കാനുമുള്ള സമയമാണിത്.

ഘട്ടം 2: എല്ലാ ഉപയോക്താക്കൾക്കും പുതിയ പതിപ്പ് റിലീസ് ചെയ്യുക

എല്ലാം നന്നായി നടന്നുവെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു, ഇപ്പോൾ എല്ലാ ഉപയോക്താക്കൾക്കും പുതിയ പതിപ്പ് ലഭ്യമാക്കേണ്ടതുണ്ട്. ഇത് ചെയ്യുന്നതിന് ഞങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുക deploy.yaml ചിത്രത്തിന്റെ പുതിയ പതിപ്പും 10-ന് തുല്യമായ പകർപ്പുകളുടെ എണ്ണവും ഇൻസ്റ്റാൾ ചെയ്യുന്നു deploy-canary.yaml ഞങ്ങൾ പകർപ്പുകളുടെ എണ്ണം 0 ആയി സജ്ജീകരിച്ചു. വിന്യാസത്തിന് ശേഷം, ഫലം ഇനിപ്പറയുന്നതായിരിക്കും:

ചുരുക്കത്തിൽ

എന്നെ സംബന്ധിച്ചിടത്തോളം, ഈ രീതിയിൽ വിന്യാസം സ്വമേധയാ പ്രവർത്തിപ്പിക്കുന്നത് k8s ഉപയോഗിച്ച് എത്ര എളുപ്പത്തിൽ കോൺഫിഗർ ചെയ്യാമെന്ന് മനസിലാക്കാൻ സഹായിക്കുന്നു. ഒരു API വഴി എല്ലാം അപ്‌ഡേറ്റ് ചെയ്യാൻ Kubernetes നിങ്ങളെ അനുവദിക്കുന്നതിനാൽ, ഈ ഘട്ടങ്ങൾ സ്‌ക്രിപ്‌റ്റുകളിലൂടെ ഓട്ടോമേറ്റ് ചെയ്യാൻ കഴിയും.

നടപ്പിലാക്കേണ്ട മറ്റൊരു കാര്യം ഒരു ടെസ്റ്റർ എൻട്രി പോയിന്റാണ് (LoadBalancer അല്ലെങ്കിൽ Ingress വഴി) അതിലൂടെ പുതിയ പതിപ്പ് മാത്രമേ ആക്സസ് ചെയ്യാൻ കഴിയൂ. ഇത് മാനുവൽ ബ്രൗസിങ്ങിന് ഉപയോഗിക്കാം.

ഭാവിയിലെ ലേഖനങ്ങളിൽ, ഞങ്ങൾ ചെയ്ത മിക്ക കാര്യങ്ങളും നടപ്പിലാക്കുന്ന മറ്റ് ഓട്ടോമേറ്റഡ് സൊല്യൂഷനുകൾ ഞങ്ങൾ പരിശോധിക്കും.

ഞങ്ങളുടെ ബ്ലോഗിലെ മറ്റ് ലേഖനങ്ങളും വായിക്കുക:

• ClickHouse-ൽ നിന്ന് അനുമതിയില്ലാതെ ClickHouse-ലേക്ക് അനുമതിയോടെയുള്ള മൈഗ്രേഷൻ എന്തിലേക്ക് നയിച്ചു?
• Nginx-നായി ഡൈനാമിക് മൊഡ്യൂളുകൾ നിർമ്മിക്കുന്നു
• nxs-build-tools അപ്ഡേറ്റ് ചെയ്യുക - deb, rpm പാക്കേജുകൾ നിർമ്മിക്കുന്നതിനുള്ള ഒരു സഹായി
• ഹാഷികോർപ്പ് കോൺസലിന്റെ കുബർനെറ്റസ് ഓതറൈസേഷന്റെ ആമുഖം
• Csync2 യൂട്ടിലിറ്റി ഉപയോഗിക്കുമ്പോൾ നമ്മൾ അഭിമുഖീകരിക്കേണ്ടി വന്ന കാര്യങ്ങൾ
• Redmine-നുള്ള ടെലിഗ്രാം ബോട്ട്. നിങ്ങൾക്കും മറ്റുള്ളവർക്കുമായി ജീവിതം എങ്ങനെ ലളിതമാക്കാം

അവലംബം: www.habr.com