Ανάπτυξη καναρινιών στο Kubernetes #3: Istio

Χρησιμοποιώντας το Istio+Kiali για την εκκίνηση και την απεικόνιση μιας ανάπτυξης Canary

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

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

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

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

Ίστιο

Και υποθέτουμε ότι διαβάζοντας αυτό το άρθρο γνωρίζετε ήδη τι είναι το Istio. Αν όχι, τότε μπορείτε να διαβάσετε σχετικά εδώ.

Αίτηση για εξετάσεις

Κάθε pod περιέχει δύο δοχεία: την εφαρμογή μας και το istio-proxy.

Θα χρησιμοποιήσουμε μια απλή δοκιμαστική εφαρμογή με frontend-nginx και backend python pods. Το nginx pod απλώς θα ανακατευθύνει κάθε αίτημα στο backend pod και θα λειτουργεί ως διακομιστής μεσολάβησης. Λεπτομέρειες μπορείτε να βρείτε στα παρακάτω yaml:

• frontend.yaml
• backend.yaml
• ιστιο.yaml

Εκτελώντας μόνοι σας την εφαρμογή δοκιμής

Εάν θέλετε να ακολουθήσετε το παράδειγμά μου και να χρησιμοποιήσετε αυτήν την εφαρμογή δοκιμής μόνοι σας, δείτε project readme.

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

Όταν ξεκινάμε το πρώτο Deployment, βλέπουμε ότι τα pods της εφαρμογής μας έχουν μόνο 2 κοντέινερ, δηλαδή το Istio sidecar μόλις υλοποιείται:

Και βλέπουμε επίσης το Istio Gateway Loadbalancer στον χώρο ονομάτων istio-system:

Παραγωγή κυκλοφορίας

Θα χρησιμοποιήσουμε την ακόλουθη IP για να δημιουργήσουμε επισκεψιμότητα που θα λαμβάνεται από τις ομάδες του frontend και θα προωθούνται στις ομάδες υποστήριξης:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Θα προσθέσουμε επίσης frontend.istio-test στο αρχείο hosts μας.

Προβολή Mesh μέσω Kiali

Εγκαταστήσαμε τη δοκιμαστική εφαρμογή και το Istio μαζί με τα Tracing, Grafana, Prometheus και Kiali (δείτε παρακάτω για λεπτομέρειες). project readme). Επομένως, μπορούμε να χρησιμοποιήσουμε το Kiali μέσω:

istioctl dashboard kiali # admin:admin

Το Kiali οπτικοποιεί την τρέχουσα κυκλοφορία μέσω του Mesh

Όπως μπορούμε να δούμε, το 100% της επισκεψιμότητας πηγαίνει στην υπηρεσία frontend και, στη συνέχεια, στα frontend pods με ετικέτα v1, αφού χρησιμοποιούμε έναν απλό διακομιστή μεσολάβησης nginx που ανακατευθύνει αιτήματα στην υπηρεσία backend, η οποία με τη σειρά του τα ανακατευθύνει στα pods υποστήριξης με ετικέτα v1.

Το Kiali λειτουργεί εξαιρετικά με το Istio και παρέχει μια ολοκληρωμένη λύση για την απόδοση Mesh. Τέλεια.

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

Το backend μας έχει ήδη δύο αναπτύξεις k8s, μία για v1 και μία για v2. Τώρα πρέπει απλώς να πούμε στον Istio να προωθήσει ένα ορισμένο ποσοστό αιτημάτων στο v2.

Βήμα 1: 10%

Και το μόνο που χρειάζεται να κάνουμε είναι να προσαρμόσουμε το βάρος της VirtualService ιστιο.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Βλέπουμε ότι το 10% των αιτημάτων ανακατευθύνεται στο v2.

Βήμα 2: 50%

Και τώρα αρκεί απλώς να το αυξήσετε στο 50%:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Βήμα 3: 100%

Τώρα η ανάπτυξη Canary μπορεί να θεωρηθεί ολοκληρωμένη και όλη η κίνηση ανακατευθύνεται στο v2:

Δοκιμή Canary χειροκίνητα

Ας υποθέσουμε ότι τώρα στέλνουμε το 2% όλων των αιτημάτων στο backend του v10. Τι γίνεται αν θέλουμε να δοκιμάσουμε χειροκίνητα το v2 για να βεβαιωθούμε ότι όλα λειτουργούν όπως περιμένουμε;

Μπορούμε να προσθέσουμε έναν ειδικό κανόνα αντιστοίχισης με βάση τις κεφαλίδες HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Τώρα χρησιμοποιώντας το curl μπορούμε να επιβάλουμε ένα αίτημα v2 στέλνοντας την κεφαλίδα:

Τα αιτήματα χωρίς κεφαλίδα θα εξακολουθούν να καθορίζονται από την αναλογία 1/10:

Canary για δύο εξαρτημένες εκδόσεις

Τώρα θα εξετάσουμε την επιλογή όπου έχουμε την έκδοση v2 τόσο για το frontend όσο και για το backend. Και για τα δύο, καθορίσαμε ότι το 10% της επισκεψιμότητας πρέπει να πηγαίνει στο v2:

Βλέπουμε ότι το frontend v1 και v2 και τα δύο προς τα εμπρός κίνηση σε αναλογία 1/10 προς το backend v1 και v2.

Τι θα γινόταν αν χρειαζόταν να προωθήσουμε την κυκλοφορία από το frontend-v2 μόνο στο backend-v2 επειδή δεν είναι συμβατό με το v1; Για να γίνει αυτό, θα ορίσουμε μια αναλογία 1/10 για το frontend, το οποίο ελέγχει την κυκλοφορία που φτάνει στο backend-v2 χρησιμοποιώντας τη διαπραγμάτευση sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Ως αποτέλεσμα, παίρνουμε αυτό που χρειαζόμαστε:

Διαφορές από τη χειροκίνητη προσέγγιση των Καναρίων

В το πρώτο μέρος Πραγματοποιήσαμε την ανάπτυξη Canary χειροκίνητα, χρησιμοποιώντας επίσης δύο αναπτύξεις k8. Εκεί ελέγξαμε την αναλογία των αιτημάτων αλλάζοντας τον αριθμό των αντιγράφων. Αυτή η προσέγγιση λειτουργεί, αλλά έχει σοβαρά μειονεκτήματα.

Το Istio καθιστά δυνατό τον προσδιορισμό της αναλογίας των αιτημάτων ανεξάρτητα από τον αριθμό των αντιγράφων. Αυτό σημαίνει, για παράδειγμα, ότι μπορούμε να χρησιμοποιήσουμε HPA (Horizontal Pod Autoscalers) και δεν χρειάζεται να ρυθμιστούν σύμφωνα με την τρέχουσα κατάσταση της ανάπτυξης των Καναρίων.

Σύνολο

Το Istio λειτουργεί υπέροχα και η χρήση του μαζί με το Kiali κάνει έναν πολύ δυνατό συνδυασμό. Επόμενο στη λίστα με τα ενδιαφέροντά μου είναι ο συνδυασμός του Spinnaker με το Istio για αυτοματισμούς και Canary analytics.

Πηγή: www.habr.com