🥇ಕುಬರ್ನೆಟ್ಸ್ #1 ರಲ್ಲಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆ: ಗಿಟ್ಲಾಬ್ CI

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಬಳಸಲು ನಾವು Gitlab CI ಮತ್ತು ಹಸ್ತಚಾಲಿತ GitOps ಅನ್ನು ಬಳಸುತ್ತೇವೆ

ಈ ಸರಣಿಯ ಲೇಖನಗಳು:

(ಈ ಲೇಖನ)
ArgoCI ಬಳಸಿಕೊಂಡು ಕ್ಯಾನರಿ ನಿಯೋಜನೆ
ಇಸ್ಟಿಯೊ ಬಳಸಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆ
ಜೆಂಕಿನ್ಸ್-ಎಕ್ಸ್ ಇಸ್ಟಿಯೊ ಫ್ಲ್ಯಾಗರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಯಾನರಿ ನಿಯೋಜನೆ

ನಾವು ಕ್ಯಾನರಿ ನಿಯೋಜನೆಯನ್ನು GitOps ಮೂಲಕ ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತೇವೆ ಮತ್ತು ಮುಖ್ಯ ಕುಬರ್ನೆಟ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ/ಮಾರ್ಪಡಿಸುತ್ತೇವೆ. ಈ ಲೇಖನವು ಪ್ರಾಥಮಿಕವಾಗಿ ಪರಿಚಯಕ್ಕಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಯಾನರಿಯಲ್ಲಿ ನಿಯೋಜನೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ವಿಧಾನಗಳಿವೆ, ಅದನ್ನು ನಾವು ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ಪರಿಗಣಿಸುತ್ತೇವೆ.

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

ಕ್ಯಾನರಿ ನಿಯೋಜನೆ

ಕ್ಯಾನರಿ ತಂತ್ರದೊಂದಿಗೆ, ನವೀಕರಣಗಳನ್ನು ಮೊದಲು ಬಳಕೆದಾರರ ಉಪವಿಭಾಗಕ್ಕೆ ಮಾತ್ರ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಮೇಲ್ವಿಚಾರಣೆ, ಲಾಗ್ ಡೇಟಾ, ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆ ಅಥವಾ ಇತರ ಪ್ರತಿಕ್ರಿಯೆ ಚಾನಲ್‌ಗಳ ಮೂಲಕ, ಬಿಡುಗಡೆಯನ್ನು ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆ (ರೋಲಿಂಗ್ ಅಪ್‌ಡೇಟ್)

ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆಗಾಗಿ ಡೀಫಾಲ್ಟ್ ತಂತ್ರವು ರೋಲಿಂಗ್-ಅಪ್‌ಡೇಟ್ ಆಗಿದೆ, ಅಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಪಾಡ್‌ಗಳನ್ನು ಚಿತ್ರಗಳ ಹೊಸ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಅವುಗಳನ್ನು ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ರಚಿಸಿದರೆ, ಚಿತ್ರಗಳ ಹಳೆಯ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಪಾಡ್‌ಗಳನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಪಾಡ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ.

GitOps

ನಾವು ಈ ಉದಾಹರಣೆಯಲ್ಲಿ GitOps ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಏಕೆಂದರೆ ನಾವು:

Git ಅನ್ನು ಸತ್ಯದ ಏಕೈಕ ಮೂಲವಾಗಿ ಬಳಸುವುದು
ನಾವು ನಿರ್ಮಿಸಲು ಮತ್ತು ನಿಯೋಜನೆಗಾಗಿ Git ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ (ಜಿಟ್ ಟ್ಯಾಗ್ / ವಿಲೀನವನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಆಜ್ಞೆಗಳ ಅಗತ್ಯವಿಲ್ಲ)

ಉದಾಹರಣೆಗೆ

ನಾವು ಉತ್ತಮ ಅಭ್ಯಾಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ - ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ಗಾಗಿ ಒಂದು ರೆಪೊಸಿಟರಿ ಮತ್ತು ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ ಒಂದನ್ನು ಹೊಂದಲು.

ಅಪ್ಲಿಕೇಶನ್ ರೆಪೊಸಿಟರಿ

ಇದು ತುಂಬಾ ಸರಳವಾದ ಪೈಥಾನ್+ಫ್ಲಾಸ್ಕ್ API ಆಗಿದ್ದು ಅದು JSON ನಂತೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ. ನಾವು GitlabCI ಮೂಲಕ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು Gitlab ರಿಜಿಸ್ಟ್ರಿಗೆ ತಳ್ಳುತ್ತೇವೆ. ನೋಂದಾವಣೆಯಲ್ಲಿ ನಾವು ಎರಡು ವಿಭಿನ್ನ ಬಿಡುಗಡೆ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ:

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

ಹಿಂದಿರುಗಿದ JSON ಫೈಲ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆ ಮಾತ್ರ ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವಾಗಿದೆ. ನಾವು ಯಾವ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸುಲಭವಾಗಿ ದೃಶ್ಯೀಕರಿಸಲು ನಾವು ಈ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಮೂಲಸೌಕರ್ಯ ಭಂಡಾರ

ಈ ಟರ್ನಿಪ್‌ನಲ್ಲಿ ನಾವು ಗಿಟ್ಲಾಬ್‌ಸಿಐ ಮೂಲಕ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ, .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 ಮೂಲಕ ಎಲ್ಲವನ್ನೂ ನವೀಕರಿಸಲು ಅನುಮತಿಸುವುದರಿಂದ, ಈ ಹಂತಗಳನ್ನು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಮೂಲಕ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು.

ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ ಪರೀಕ್ಷಕ ಪ್ರವೇಶ ಬಿಂದು (ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ಪ್ರವೇಶದ ಮೂಲಕ) ಅದರ ಮೂಲಕ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರ ಪ್ರವೇಶಿಸಬಹುದು. ಇದನ್ನು ಹಸ್ತಚಾಲಿತ ಬ್ರೌಸಿಂಗ್‌ಗೆ ಬಳಸಬಹುದು.

ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ, ನಾವು ಮಾಡಿರುವುದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಇತರ ಸ್ವಯಂಚಾಲಿತ ಪರಿಹಾರಗಳನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇತರ ಲೇಖನಗಳನ್ನು ಸಹ ಓದಿ:

ಮೂಲ: www.habr.com

ಕುಬರ್ನೆಟ್ಸ್ #1 ರಲ್ಲಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆ: ಗಿಟ್ಲಾಬ್ CI