🥇Ανάπτυξη Canary στο Kubernetes #1: Gitlab CI

Θα χρησιμοποιήσουμε το Gitlab CI και το μη αυτόματο GitOps για να εφαρμόσουμε και να χρησιμοποιήσουμε την ανάπτυξη Canary στο Kubernetes

Άρθρα από αυτή τη σειρά:

(Αυτό το άρθρο)
Ανάπτυξη Canary με χρήση ArgoCI
Ανάπτυξη Canary με χρήση Istio
Ανάπτυξη Canary με χρήση Jenkins-X Istio Flagger

Θα εκτελέσουμε την ανάπτυξη Canary με μη αυτόματο τρόπο μέσω του GitOps και δημιουργώντας/τροποποιώντας τους κύριους πόρους Kubernetes. Αυτό το άρθρο προορίζεται κυρίως για εισαγωγή με το πώς λειτουργεί η ανάπτυξη στο Kubernetes Canary, αφού υπάρχουν πιο αποτελεσματικές μέθοδοι αυτοματισμού, τις οποίες θα εξετάσουμε στα επόμενα άρθρα.

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

Ανάπτυξη καναρινιών

Με τη στρατηγική Canary, οι ενημερώσεις εφαρμόζονται πρώτα μόνο σε ένα υποσύνολο χρηστών. Μέσω παρακολούθησης, δεδομένων καταγραφής, μη αυτόματων δοκιμών ή άλλων καναλιών ανατροφοδότησης, η έκδοση ελέγχεται πριν κυκλοφορήσει σε όλους τους χρήστες.

Ανάπτυξη Kubernetes (κυλιόμενη ενημέρωση)

Η προεπιλεγμένη στρατηγική για το Kubernetes Deployment είναι η κυλιόμενη ενημέρωση, όπου ένας συγκεκριμένος αριθμός pod εκκινείται με νέες εκδόσεις των εικόνων. Εάν δημιουργήθηκαν χωρίς προβλήματα, οι ομάδες με παλιές εκδόσεις εικόνων τερματίζονται και δημιουργούνται νέες ομάδες παράλληλα.

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 στο σύμπλεγμα σας.

Μπορείτε να διαβάσετε σχετικά με τον τρόπο λήψης διαπιστευτηρίων για ένα σύμπλεγμα (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 αντίγραφα και app-canary με 0. Υπάρχει επίσης ένα LoadBalancer από το οποίο μπορούμε να έχουμε πρόσβαση μέσω curl μέσω εξωτερικής IP:

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

Βλέπουμε ότι η δοκιμαστική εφαρμογή μας επιστρέφει μόνο "v1".

Εκτέλεση ανάπτυξης Canary

Βήμα 1: κυκλοφορήστε μια νέα έκδοση για ορισμένους χρήστες

Ορίσαμε τον αριθμό των αντιγράφων σε 1 στο αρχείο deploy-canary.yaml και στην εικόνα της νέας έκδοσης:

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 as a Single Source Of Truth) είναι η παρουσία δύο αναπτύξεων με ενεργά αντίγραφα, ένα για κάθε έκδοση.

~10% των χρηστών εξοικειώνονται με μια νέα έκδοση και τη δοκιμάζουν ακούσια. Τώρα είναι η ώρα να ελέγξετε για σφάλματα στα αρχεία καταγραφής και στα δεδομένα παρακολούθησης για να βρείτε προβλήματα.

Βήμα 2: Κυκλοφορήστε τη νέα έκδοση σε όλους τους χρήστες

Αποφασίσαμε ότι όλα πήγαν καλά και τώρα πρέπει να διαθέσουμε τη νέα έκδοση σε όλους τους χρήστες. Για να γίνει αυτό, απλώς ενημερώνουμε deploy.yaml εγκατάσταση μιας νέας έκδοσης της εικόνας και ο αριθμός των αντιγράφων είναι ίσος με 10. Σε deploy-canary.yaml επαναφέρουμε τον αριθμό των αντιγράφων στο 0. Μετά την ανάπτυξη, το αποτέλεσμα θα είναι το εξής:

Ανακεφαλαίωση

Για μένα, η μη αυτόματη εκτέλεση της ανάπτυξης με αυτόν τον τρόπο βοηθά να κατανοήσω πόσο εύκολα μπορεί να ρυθμιστεί χρησιμοποιώντας το k8s. Δεδομένου ότι το Kubernetes σάς επιτρέπει να ενημερώνετε τα πάντα μέσω ενός API, αυτά τα βήματα μπορούν να αυτοματοποιηθούν μέσω σεναρίων.

Ένα άλλο πράγμα που πρέπει να εφαρμοστεί είναι ένα σημείο εισόδου δοκιμαστή (LoadBalancer ή μέσω Ingress) μέσω του οποίου είναι δυνατή η πρόσβαση μόνο στη νέα έκδοση. Μπορεί να χρησιμοποιηθεί για χειροκίνητη περιήγηση.

Σε μελλοντικά άρθρα, θα δούμε άλλες αυτοματοποιημένες λύσεις που υλοποιούν το μεγαλύτερο μέρος των όσων έχουμε κάνει.

Διαβάστε επίσης άλλα άρθρα στο ιστολόγιό μας:

Πηγή: www.habr.com

Ανάπτυξη Canary στο Kubernetes #1: Gitlab CI