ProHoster > Automatiske canary-udrulninger med Flagger og Istio

Automatiske canary-udrulninger med Flagger og Istio

Automatiske canary-udrulninger med Flagger og Istio

CD er anerkendt som en praksis inden for virksomhedens software og er resultatet af en naturlig evolution af etablerede CI-principper. Dog er CD stadig en ret sjælden forekomst, muligvis på grund af kompleksiteten ved at administrere og frygten for mislykkede udrulninger, der påvirker systemets tilgængelighed.

Flagger er en open source Kubernetes-operatør, hvis mål er at fjerne forvirrende sammenhænge. Den automatiserer udrulningen af canary-udrulninger ved at bruge Istios trafikfordeling og Prometheus-metrikker til at analysere applikationens opførsel under en kontrolleret udrulning.

Nedenfor er en trin-for-trin vejledning til opsætning og brug af Flagger i Google Kubernetes Engine (GKE).

Opsætning af Kubernetes-kluster

Du starter med at oprette et GKE-kluster med Istio-tilføjelsen (hvis du ikke har en GCP-konto, kan du tilmelde dig her for at få gratis kreditter).

Log ind på Google Cloud, opret et projekt og aktiver fakturering for det. Installer kommandolinje-værktøjet gcloud og konfigurer dit projekt med gcloud init.

Indstil standardprojektet, compute-region og -zone (erstat PROJECT_ID med dit projekt):

gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

Aktiver GKE-tjenesten og opret et kluster med HPA og Istio-tilføjelser:

gcloud services enable container.googleapis.com
K8S_VERSION=$(gcloud beta container get-server-config --format=json | jq -r '.validMasterVersions[0]')
gcloud beta container clusters create istio 
--cluster-version=${K8S_VERSION} 
--zone=us-central1-a 
--num-nodes=2 
--machine-type=n1-standard-2 
--disk-size=30 
--enable-autorepair 
--no-enable-cloud-logging 
--no-enable-cloud-monitoring 
--addons=HorizontalPodAutoscaling,Istio 
--istio-config=auth=MTLS_PERMISSIVE

Den ovenstående kommando vil skabe en standard nodpulje, der inkluderer to VM'er n1-standard-2 (vCPU: 2, RAM 7,5 GB, disk: 30 GB). Ideelt set bør Istio-komponenterne isoleres fra deres arbejdsbelastninger, men der findes ikke en enkel måde at køre Istio-pods på i en dedikeret nodpulje. Istios manifester anses for at være kun læselige, og GKE vil annullere eventuelle ændringer, såsom bindning til en node eller afkobling fra en pod.

Konfigurer legitimationsoplysninger for kubectl:

gcloud container clusters get-credentials istio

Opret en cluster-administrator rollebindning:

kubectl create clusterrolebinding "cluster-admin-$(whoami)" 
--clusterrole=cluster-admin 
--user="$(gcloud config get-value core/account)"

Installer kommandolinjeværktøjet Helm:

brew install kubernetes-helm

Homebrew 2.0 er nu også tilgængeligt for Linux.

Opret en tjenestekonto og bind en clusterrolle til Tiller:

kubectl -n kube-system create sa tiller && 
kubectl create clusterrolebinding tiller-cluster-rule 
--clusterrole=cluster-admin 
--serviceaccount=kube-system:tiller

Udrul Tiller i navnerummet kube-system:

helm init --service-account tiller

Du bør overveje at bruge SSL mellem Helm og Tiller. For mere information om at sikre Helm-installationen, se docs.helm.sh

Bekræft indstillingerne:

kubectl -n istio-system get svc

Efter et par sekunder skal GCP tildele en offentlig IP-adresse til tjenesten istio-ingressgateway.

Konfigurer Istio indgangsgateway

Opret en statisk IP-adresse med navnet istio-gateway, ved hjælp af IP-adressen for Istio-gateway:

export GATEWAY_IP=$(kubectl -n istio-system get svc/istio-ingressgateway -ojson | jq -r .status.loadBalancer.ingress[0].ip)
gcloud compute addresses create istio-gateway --addresses ${GATEWAY_IP} --region us-central1

Nu har du brug for et internetdomæne og adgang til din DNS-registrator. Tilføj to A-poster (erstat example.com med dit domæne):

istio.example.com   A ${GATEWAY_IP}
*.istio.example.com A ${GATEWAY_IP}

Sørg for, at wildcard DNS fungerer:

watch host test.istio.example.com

Opret en offentlig Istio-gateway til at levere tjenester uden for service mesh via HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"

Gem ovenstående ressource som public-gateway.yaml og anvend den derefter:

kubectl apply -f ./public-gateway.yaml

Ingen produktionssystemer bør levere tjenester på internettet uden SSL. For at sikre Istio indgangsgatewayen med cert-manager, CloudDNS og Let’s Encrypt, se venligst dokumentationen Flagger GKE.

Installation af Flagger

GKE Istio opgradering inkluderer ikke en instance af Prometheus, som håndterer rensningen af Istio telemetritjenester. Da Flagger bruger Istio HTTP-metrikker til at udføre canary-analyse, skal du udrulle følgende Prometheus-konfiguration, som svarer til den, der følger med den officielle Istio Helm skema.

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/gke/istio-prometheus.yaml

Tilføj Flagger Helm-repositoriet:

helm repo add flagger [https://flagger.app](https://flagger.app/)

Udrul Flagger i navnerummet istio-system, med Slack-meddelelser:

helm upgrade -i flagger flagger/flagger 
--namespace=istio-system 
--set metricsServer=http://prometheus.istio-system:9090 
--set slack.url=https://hooks.slack.com/services/YOUR-WEBHOOK-ID 
--set slack.channel=general 
--set slack.user=flagger

Du kan installere Flagger i ethvert navnerum, hvis det kan interagere med Istio Prometheus-tjenesten via port 9090.

Flagger har et Grafana-dashboard til canary-analyse. Installer Grafana i navnerummet istio-system:

helm upgrade -i flagger-grafana flagger/grafana 
--namespace=istio-system 
--set url=http://prometheus.istio-system:9090 
--set user=admin 
--set password=change-me

Åbn Grafana gennem den åbne gateway ved at oprette en virtuel tjeneste (erstat example.com med dit domæne):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grafana
  namespace: istio-system
spec:
  hosts:
    - "grafana.istio.example.com"
  gateways:
    - public-gateway.istio-system.svc.cluster.local
  http:
    - route:
        - destination:
            host: flagger-grafana

Gem ovenstående ressource som grafana-virtual-service.yaml, og anvend den derefter:

kubectl apply -f ./grafana-virtual-service.yaml

Når du navigerer til http://grafana.istio.example.com bør du blive omdirigeret til login-siden for Grafana.

Udrulning af webapplikationer med Flagger

Flagger udruller Kubernetes og, om nødvendigt, horisontal automatisk skalering (HPA), og opretter derefter en sekvens af objekter (Kubernetes-deployments, ClusterIP-tjenester og Istio-virtuelle tjenester). Disse objekter gør applikationen synlig i servicenetværket og håndterer canary-analyse og fremdrift.

Automatiske canary-udrulninger med Flagger og Istio

Opret et testnavnerum med aktiveret Istio Sidecar-implementering:

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml

Opret en deployment og en automatisk horisontal skalering for pod:

kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml

Udrul en testbelastningstjeneste for at generere trafik under canary-analysen:

helm upgrade -i flagger-loadtester flagger/loadtester 
--namepace=test

Opret en brugerdefineret canary-ressource (erstat example.com med dit domæne):

apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
  canaryAnalysis:
    interval: 30s
    threshold: 10
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: istio_requests_total
      threshold: 99
      interval: 30s
    - name: istio_request_duration_seconds_bucket
      threshold: 500
      interval: 30s
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"

Gem ovenstående ressource som podinfo-canary.yaml, og anvend den derefter:

kubectl apply -f ./podinfo-canary.yaml

Den ovennævnte analyse, i tilfælde af succes, vil blive udført i fem minutter med kontrol af HTTP-metrikker hver halve minut. Du kan bestemme minimumstiden nødvendig for at validere og fremme canary-deployeringen med følgende formel: interval * (maxWeight / stepWeight). Felter Canary CRD dokumenteres her.

Om et par sekunder vil Flagger oprette canary-objekter:

# applied 
deployment.apps/podinfo
horizontalpodautoscaler.autoscaling/podinfo
canary.flagger.app/podinfo
# generated 
deployment.apps/podinfo-primary
horizontalpodautoscaler.autoscaling/podinfo-primary
service/podinfo
service/podinfo-canary
service/podinfo-primary
virtualservice.networking.istio.io/podinfo

Åbn browseren og gå til app.istio.example.com, du skal se versionsnummeret demonstrationsapplikationen.

Automatisk canary-analyse og fremme

Flagger implementerer en styringscyklus, der gradvist flytter trafikken til canary, samtidig med at den måler nøglepræstationsindikatorer, såsom succesrate for HTTP-anmodninger, gennemsnitlig svartid og pods tilgængelighed. Baseret på KPI-analysen fremmes eller afbrydes canary, og analyse resultaterne offentliggøres i Slack.

Automatiske canary-udrulninger med Flagger og Istio

Canary-udrulningen startes ved ændring af en af følgende objekter:

  • Deployment PodSpec (containerbillede, kommando, porte, miljø osv.)
  • ConfigMaps monteres som volumener eller transformeres til miljøvariabler
  • Secrets monteres som volumener eller transformeres til miljøvariabler

Start canary-udrulningen ved opdatering af containerbilledet:

kubectl -n test set image deployment/podinfo 
podinfod=quay.io/stefanprodan/podinfo:1.4.1

Flagger opdager, at versionen af deployment er ændret og begynder at analysere den:

kubectl -n test describe canary/podinfo

Begivenheder:

Ny revision opdaget podinfo.test
Opdaterer podinfo.test
Venter på at podinfo.test udrulningen skal afsluttes: 0 af 1 opdaterede replikaer er tilgængelige
Fremgang podinfo.test canary vægt 5
Fremgang podinfo.test canary vægt 10
Fremgang podinfo.test canary vægt 15
Fremgang podinfo.test canary vægt 20
Fremgang podinfo.test canary vægt 25
Fremgang podinfo.test canary vægt 30
Fremgang podinfo.test canary vægt 35
Fremgang podinfo.test canary vægt 40
Fremgang podinfo.test canary vægt 45
Fremgang podinfo.test canary vægt 50
Kopiere podinfo.test skabelonspecifikation til podinfo-primary.test
Venter på at podinfo-primary.test udrulningen skal afsluttes: 1 af 2 opdaterede replikaer er tilgængelige
Fremme fuldført! Nedskalering af podinfo.test

Under analysen kan resultaterne af canary overvåges ved hjælp af Grafana:

Automatiske canary-udrulninger med Flagger og Istio

Bemærk: Hvis nye ændringer anvendes til deployment under canary-analysen, vil Flagger genstarte analysefasen.

Lav en liste over alle "canaries" i din klynge:

watch kubectl get canaries --all-namespaces
NAMESPACE   NAVN      STATUS        VÆGT   SIDSTEOVERGANGSTID
test        podinfo   Fremskridter   15       2019-01-16T14:05:07Z
prod        frontend  Fuldført      0        2019-01-15T16:15:07Z
prod        backend   Fejlet       0        2019-01-14T17:05:07Z

Hvis du har aktiveret Slack-notifikationer, vil du modtage følgende beskeder:

Automatiske canary-udrulninger med Flagger og Istio

Automatisk tilbagetrækning

Under canary-analysen kan der genereres syntetiske HTTP 500-fejl og høj svartid for at tjekke, om Flagger stopper deployment.

Opret en testpod og udfør følgende handling:

kubectl -n test run tester 
--image=quay.io/stefanprodan/podinfo:1.2.1 
-- ./podinfo --port=9898
kubectl -n test exec -it tester-xx-xx sh

Generering af HTTP 500-fejl:

watch curl http://podinfo-canary:9898/status/500

Generering af forsinkelse:

watch curl http://podinfo-canary:9898/delay/1

Når antallet af mislykkede kontroller når tærskelværdien, dirigeres trafikken tilbage til den primære kanal, canary skaleres ned til nul, og deploymentet bliver markeret som mislykket.

Canary-fejl og forsinkelsespidser registreres som Kubernetes-begivenheder og gemmes af Flagger i JSON-format:

kubectl -n istio-system logs deployment/flagger -f | jq .msg

Starter canary-deployment for podinfo.test
Fremdrift af podinfo.test canary-vægt 5
Fremdrift af podinfo.test canary-vægt 10
Fremdrift af podinfo.test canary-vægt 15
Stop podinfo.test fremdrift succesrate 69.17% < 99%
Stop podinfo.test fremdrift succesrate 61.39% < 99%
Stop podinfo.test fremdrift succesrate 55.06% < 99%
Stop podinfo.test fremdrift succesrate 47.00% < 99%
Stop podinfo.test fremdrift succesrate 37.00%  500ms
Stop podinfo.test fremdrift anmodningsvarighed 1.600s > 500ms
Stop podinfo.test fremdrift anmodningsvarighed 1.915s > 500ms
Stop podinfo.test fremdrift anmodningsvarighed 2.050s > 500ms
Stop podinfo.test fremdrift anmodningsvarighed 2.515s > 500ms
Ruller tilbage podinfo.test mislykkede kontroller tærskel nået 10
Canary mislykkedes! Skalerer ned podinfo.test

Hvis du har aktiveret Slack-notifikationer, vil du modtage en besked, når tærsklen for udførelsestid eller det maksimale antal mislykkede kontroller under analysen er overskredet:

Automatiske canary-udrulninger med Flagger og Istio

Afslutningsvis

At køre en service mesh, som Istio, ud over Kubernetes, giver automatisk metrikker, logs og protokoller, men deployment af arbejdsbyrder afhænger stadig af eksterne værktøjer. Flagger stræber efter at ændre denne situation ved at tilføje Istio-kapaciteter progressiv levering.

Flagger er kompatibel med enhver CI/CD-løsning for Kubernetes, og canary-analysen kan nemt udvides med webhooks til at udføre systemintegration/acceptancetests, belastningstests eller enhver anden brugerdefineret kontrol. Da Flagger er deklarativ og reagerer på Kubernetes-begivenheder, kan den bruges i GitOps-pipelines sammen med Weave Flux eller JenkinsX. Hvis du bruger JenkinsX, kan du installere Flagger med jx-udvidelser.

Flagger understøttes af Weaveworks og muliggør canary-deployments i Weave Cloud. Projektet testes på GKE, EKS og 'bare metal' med kubeadm.

Hvis du har forslag til forbedringer af Flagger, bedes du sende et spørgsmål eller PR til GitHub på stefanprodan/flagger. Bidrag er mere end velkomne!

Tak Ræy Tsan.

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster