🥇Ανάπτυξη Canary στο Kubernetes #2: Argo Rollouts

Θα χρησιμοποιήσουμε τον ελεγκτή ανάπτυξης Argo Rollouts του k8s και το GitlabCI για να εκτελέσουμε αναπτύξεις Canary στο Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Άρθρα αυτής της σειράς

Ανάπτυξη Canary στο Kubernetes #1: Gitlab CI
(Αυτό το άρθρο)
Ανάπτυξη Canary με χρήση Istio
Ανάπτυξη Canary με χρήση Jenkins-X Istio Flagger

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

Ελπίζουμε να διαβάσετε πρώτο μέρος, όπου εξηγήσαμε εν συντομία τι είναι τα Canary Deployments. Δείξαμε επίσης πώς να το εφαρμόσουμε χρησιμοποιώντας τυπικούς πόρους Kubernetes.

Argo Rollouts

Το Argo Rollouts είναι ένας εγγενής ελεγκτής ανάπτυξης της Kubernetes. Παρέχει ένα CRD (Custom Resource Definition) για το Kubernetes. Χάρη σε αυτό, μπορούμε να χρησιμοποιήσουμε μια νέα οντότητα: Rollout, το οποίο διαχειρίζεται γαλαζοπράσινες και καναρινιές αναπτύξεις με διάφορες επιλογές διαμόρφωσης.

Ο ελεγκτής Argo Rollouts χρησιμοποιείται από έναν προσαρμοσμένο πόρο Rollout, Επιτρέπει πρόσθετες στρατηγικές ανάπτυξης, όπως μπλε-πράσινο και καναρίνι για Kubernetes. Πόρος Rollout παρέχει ισοδύναμη λειτουργικότητα Deployment, μόνο με πρόσθετες στρατηγικές ανάπτυξης.
πόρος Deployments έχει δύο στρατηγικές για την ανάπτυξη: RollingUpdate и Recreate. Αν και αυτές οι στρατηγικές είναι κατάλληλες για τις περισσότερες περιπτώσεις, για ανάπτυξη σε διακομιστές σε πολύ μεγάλη κλίμακα, χρησιμοποιούνται πρόσθετες στρατηγικές, όπως μπλε-πράσινο ή καναρίνι, οι οποίες δεν είναι διαθέσιμες στον ελεγκτή ανάπτυξης. Για να χρησιμοποιήσουν αυτές τις στρατηγικές στο Kubernetes, οι χρήστες έπρεπε να γράψουν σενάρια πάνω από τις αναπτύξεις τους. Ο ελεγκτής Argo Rollouts εκθέτει αυτές τις στρατηγικές ως απλές, δηλωτικές και διαμορφώσιμες παραμέτρους.
https://argoproj.github.io/argo-rollouts

Υπάρχει επίσης το Argo CI, το οποίο παρέχει μια βολική διεπαφή ιστού για χρήση με το Rollouts, θα ρίξουμε μια ματιά σε αυτό στο επόμενο άρθρο.

Εγκατάσταση του Argo Rollouts

Πλευρά του διακομιστή

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Στο turnip της υποδομής μας (δείτε παρακάτω) έχουμε ήδη προσθέσει το install.yaml ως i/k8s/argo-rollouts/install.yaml. Με αυτόν τον τρόπο το GitlabCI θα το εγκαταστήσει στο σύμπλεγμα.

Πλευρά πελάτη (πρόσθετο kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Παράδειγμα Εφαρμογής

Είναι καλή πρακτική να υπάρχουν ξεχωριστά αποθετήρια για τον κώδικα εφαρμογής και την υποδομή.

Αποθετήριο για την εφαρμογή

Kim Wuestkamp/k8s-deployment-example-app

Αυτό είναι ένα πολύ απλό 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-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

και rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout λειτουργεί το ίδιο με το Deployment. Εάν δεν ορίσουμε μια στρατηγική ενημέρωσης (όπως το καναρίνι εδώ) θα συμπεριφέρεται όπως η προεπιλεγμένη ανάπτυξη κυλιόμενης ενημέρωσης.

Ορίζουμε δύο βήματα στο yaml για την ανάπτυξη καναρινιών:

10% της κίνησης στο καναρίνι (περιμένετε για μη αυτόματο ΟΚ)
50% κίνηση στο καναρίνι (περιμένετε 2 λεπτά και μετά συνεχίστε στο 100%)

Εκτέλεση αρχικής ανάπτυξης

Μετά την αρχική ανάπτυξη, οι πόροι μας θα μοιάζουν με αυτό:

Και λαμβάνουμε απάντηση μόνο από την πρώτη έκδοση της εφαρμογής:

Εκτέλεση ανάπτυξης καναρινιών

Βήμα 1: 10% επισκεψιμότητα

Για να ξεκινήσουμε μια ανάπτυξη καναρίνι, πρέπει απλώς να αλλάξουμε την έκδοση εικόνας όπως κάνουμε συνήθως με τις αναπτύξεις:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

Και προωθούμε τις αλλαγές, οπότε το Gitlab CI αναπτύσσεται και βλέπουμε τις αλλαγές:

Τώρα αν έχουμε πρόσβαση στην υπηρεσία:

Εξαιρετική! Βρισκόμαστε στη μέση της ανάπτυξης των καναρινιών μας. Μπορούμε να δούμε την πρόοδο τρέχοντας:

kubectl argo rollouts get rollout rollout-canary

Βήμα 2: 50% επισκεψιμότητα:

Τώρα ας προχωρήσουμε στο επόμενο βήμα: ανακατεύθυνση του 50% της επισκεψιμότητας. Διαμορφώσαμε αυτό το βήμα ώστε να εκτελείται μη αυτόματα:

kubectl argo rollouts promote rollout-canary # continue to step 2

Και η εφαρμογή μας επέστρεψε το 50% των απαντήσεων από νέες εκδόσεις:

Και κριτική διάθεσης:

Εκπληκτικός.

Βήμα 3: 100% επισκεψιμότητα:

Το ρυθμίσαμε έτσι ώστε μετά από 2 λεπτά να τελειώνει αυτόματα το βήμα 50% και να ξεκινά το βήμα 100%.

Και η έξοδος της εφαρμογής:

Και κριτική διάθεσης:

Η ανάπτυξη των καναρίνι ολοκληρώθηκε.

Περισσότερα παραδείγματα με το Argo Rollouts

Υπάρχουν περισσότερα παραδείγματα εδώ, όπως πώς να ρυθμίσετε τις προεπισκοπήσεις περιβάλλοντος και τις συγκρίσεις με βάση το καναρίνι:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Βίντεο σχετικά με τα Argo Rollouts και Argo CI

Συνιστώ πραγματικά αυτό το βίντεο, δείχνει πώς συνεργάζονται το Argo Rollouts και το Argo CI:

Σύνολο

Μου αρέσει πολύ η ιδέα της χρήσης CRD που διαχειρίζονται τη δημιουργία πρόσθετων τύπων αναπτύξεων ή συνόλων αντιγραφής, ανακατεύθυνσης κυκλοφορίας κ.λπ. Η εργασία μαζί τους πηγαίνει ομαλά. Στη συνέχεια θα ήθελα να δοκιμάσω την ενοποίηση με το Argo CI.

Ωστόσο, φαίνεται να υπάρχει μια μεγάλη συγχώνευση των Argo CI και Flux CI, οπότε ίσως να περιμένω μέχρι να κυκλοφορήσει η νέα έκδοση: Argo Flux.

Είχατε κάποια εμπειρία με το Argo Rollouts ή το Argo CI;

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

Πηγή: www.habr.com

Ανάπτυξη Canary στο Kubernetes #2: Argo Rollouts