ProHoster > Automatiska canary-deployments med Flagger och Istio

Automatiska canary-deployments med Flagger och Istio

Automatiska canary-deployments med Flagger och Istio

CD erkänns som en praktik inom företagsprogramvara; det är resultatet av en naturlig evolution av etablerade CI-principer. Trots det är CD fortfarande en ganska sällsynt förekomst, kanske på grund av svårigheten att hantera det och rädslan för misslyckade deploys som påverkar systemets tillgänglighet.

Flagger är en Kubernetes-operator med öppen källkod, vars mål är att undvika komplicerade beroenden. Den automatiserar främjandet av canary-deploys med användning av trafikskifte i Istio och Prometheus-metriker för att analysera applikationens beteende under en kontrollerad utrullning.

Nedan följer en steg-för-steg-guide för att konfigurera och använda Flagger i Google Kubernetes Engine (GKE).

Konfigurera Kubernetes-klustret

Du börjar med att skapa ett GKE-kluster med Istio-tillägg (om du inte har ett GCP-konto kan du registrera dig här för att få gratis krediter).

Logga in på Google Cloud, skapa ett projekt och aktivera fakturering för det. Installera kommandoradsverktyget gcloud och ställ in ditt projekt med gcloud init.

Ställ in standardprojektet, beräkningsregionen och zonen (ersätt PROJECT_ID med ditt projekt):

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

Aktivera GKE-tjänsten och skapa ett kluster med HPA och Istio-tillägg:

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

Ovanstående kommando kommer att skapa en standard nodpool med två VM:ar n1-standard-2 (vCPU: 2, RAM 7,5 GB, disk: 30 GB). Idealiskt bör komponenterna i Istio isoleras från sina arbetsbelastningar, men det finns inget enkelt sätt att köra Istio-pods i en dedikerad nodpool. Istios manifest anses vara skrivskyddade, och GKE kommer att avbryta eventuella ändringar, såsom nodbindning eller bortkoppling från en pod.

Konfigurera autentiseringsuppgifter för kubectl:

gcloud container clusters get-credentials istio

Skapa en rollbindning för klusteradministratör:

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

Installera kommandoradsverktyget Helm:

brew install kubernetes-helm

Homebrew 2.0 är nu också tillgängligt för Linux.

Skapa ett tjänstekonto och en klusterrollbindning för Tiller:

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

Distribuera Tiller i namespace kube-system:

helm init --service-account tiller

Du bör överväga att använda SSL mellan Helm och Tiller. För mer information om att skydda Helm-installationen, se docs.helm.sh

Bekräfta inställningarna:

kubectl -n istio-system get svc

Inom några sekunder bör GCP tilldela en extern IP-adress till tjänsten istio-ingressgateway.

Konfigurera Istios ingångsgateway

Skapa en statisk IP-adress med namnet istio-gateway, med hjälp av Istio-gatewayens IP-adress:

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 behöver du en internetdomän och tillgång till din DNS-registrator. Lägg till två A-poster (ersätt example.com med din domän):

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

Säkerställ att wildcard-DNS fungerar:

watch host test.istio.example.com

Skapa en offentlig Istio-gateway för att tillhandahålla tjänster utanför 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:
        - "*"

Spara den ovanstående resursen som public-gateway.yaml och applicera den sedan:

kubectl apply -f ./public-gateway.yaml

Ingen produktionssystem bör tillhandahålla tjänster på Internet utan SSL. För att skydda Istios ingångsgateway med cert-manager, CloudDNS och Let’s Encrypt, läs vänligen dokumentationen Flagger GKE.

Installera Flagger

GKE Istio-upgrade inkluderar inte en Prometheus-instans som hanterar städningen av Istios telemetritjänster. Eftersom Flagger använder Istio HTTP-metrik för att utföra canary-analyser, behöver du distribuera följande Prometheus-konfiguration, liknande den som följer med den officiella Istio Helm-mallen.

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

Lägg till Flagger Helm-repo:

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

Distribuera Flagger i namespace istio-system, aktivera Slack-notifikationer:

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 installera Flagger i valfritt namespace, så länge det kan interagera med Istio Prometheus-tjänsten via port 9090.

Flagger har en Grafana-övervakningspanel för canary-analys. Installera Grafana i namnutrymmet 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

Öppna Grafana via en offentlig gateway genom att skapa en virtuell tjänst (ersätt example.com med din domän):

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

Spara den ovanstående resursen som grafana-virtual-service.yaml och tillämpa den sedan:

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

När du går till http://grafana.istio.example.com i webbläsaren bör du dirigeras till inloggningssidan för Grafana.

Distribuering av webbtjänster med Flagger

Flagger distribuerar Kubernetes och, om nödvändigt, horisontell automatisk skalning (HPA), och skapar sedan en serie objekt (Kubernetes-deployment, ClusterIP-tjänster och Istio virtuella tjänster). Dessa objekt avslöjar applikationen i service mesh och hanterar canary-analys och distributionsprocessen.

Automatiska canary-deployments med Flagger och Istio

Skapa ett testnamnutrymme med aktiverad Istio Sidecar-integration:

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

Skapa en deployment och en pod automatiskt för horisontell skalning:

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

Distribuera en testbelastningstjänst för att generera trafik under canary-analysen:

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

Skapa en anpassad canary-resurs (ersätt example.com med din domän):

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/"

Spara den ovanstående resursen som podinfo-canary.yaml och tillämpa den sedan:

kubectl apply -f ./podinfo-canary.yaml

Den ovanstående analysen, vid framgång, kommer att pågå i fem minuter, med HTTP-metriker som kontrolleras var 30:e sekund. Du kan bestämma den minimala tiden som krävs för att kontrollera och avancera canary-distributionen enligt följande formel: interval * (maxWeight / stepWeight). Canary CRD-fälten dokumenteras här.

Om några sekunder kommer Flagger att skapa canary-objekt:

# 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

Öppna webbläsaren och gå till app.istio.example.com, du bör se versionsnumret demo-applikationen.

Automatisk canary-analys och promotion

Flagger implementerar en styrcykel som gradvis flyttar trafik till canary samtidigt som den mäter nyckelprestandaindikatorer, såsom framgångsnivån för HTTP-förfrågningar, genomsnittlig svarstid och podens tillförlitlighet. Baserat på KPI-analysen avancerar eller avbryts canary, och analysresultaten publiceras i Slack.

Automatiska canary-deployments med Flagger och Istio

Canary-deploy starten initieras vid ändring av något av följande objekt:

  • Deploy PodSpec (containerns bild, kommandon, portar, env etc.)
  • ConfigMaps monteras som volymer eller omvandlas till miljövariabler
  • Hemligheter monteras som volymer eller omvandlas till miljövariabler

Starta canary-deploy vid uppdatering av containerbild:

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

Flagger upptäcker att versionen av deploy har ändrats och börjar analysera:

kubectl -n test describe canary/podinfo

Händelser:

Ny revision detekterad podinfo.test
Höjer upp podinfo.test
Väntar på att podinfo.test rollout ska slutföras: 0 av 1 uppdaterade repliker är tillgängliga
Främja podinfo.test canary vikt 5
Främja podinfo.test canary vikt 10
Främja podinfo.test canary vikt 15
Främja podinfo.test canary vikt 20
Främja podinfo.test canary vikt 25
Främja podinfo.test canary vikt 30
Främja podinfo.test canary vikt 35
Främja podinfo.test canary vikt 40
Främja podinfo.test canary vikt 45
Främja podinfo.test canary vikt 50
Kopiera podinfo.test mall-spec till podinfo-primary.test
Väntar på att podinfo-primary.test rollout ska slutföras: 1 av 2 uppdaterade repliker är tillgängliga
Promotion slutförd! Sänker ner podinfo.test

Under analysen kan resultaten av canary spåras med Grafana:

Automatiska canary-deployments med Flagger och Istio

Observera: om nya ändringar tillämpas på deploy under canary-analysen, kommer Flagger att starta om analysfasen.

Skapa en lista över alla "kanariefåglar" i din kluster:

watch kubectl get canaries --all-namespaces
NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
test        podinfo   Progressing   15       2019-01-16T14:05:07Z
prod        frontend  Succeeded     0        2019-01-15T16:15:07Z
prod        backend   Failed        0        2019-01-14T17:05:07Z

Om du har aktiverat Slack-notiser kommer du att få följande meddelanden:

Automatiska canary-deployments med Flagger och Istio

Automatisk återställning

Under canary-analysen kan du generera syntetiska HTTP 500-fel och hög svarstid för att kontrollera om Flagger stoppar deploy.

Skapa en testpod och utför följande åtgärd i den:

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 av HTTP 500-fel:

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

Generering av fördröjning:

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

När antalet misslyckade kontroller når en tröskel, dirigeras trafiken tillbaka till den primära kanalen, canary skalas ner till noll, och distributionen markeras som misslyckad.

Canary-fel och fördröjningsspikar registreras som Kubernetes-händelser och loggas av Flagger i JSON-format:

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

Startar canary-distribution för podinfo.test
Fortsätt podinfo.test canary-vikt 5
Fortsätt podinfo.test canary-vikt 10
Fortsätt podinfo.test canary-vikt 15
Avbryt podinfo.test framsteg framgångsgrad 69,17% < 99%
Avbryt podinfo.test framsteg framgångsgrad 61,39% < 99%
Avbryt podinfo.test framsteg framgångsgrad 55,06% < 99%
Avbryt podinfo.test framsteg framgångsgrad 47,00% < 99%
Avbryt podinfo.test framsteg framgångsgrad 37,00% < 99%
Avbryt podinfo.test framsteg begärningstid 1,515s > 500ms
Avbryt podinfo.test framsteg begärningstid 1,600s > 500ms
Avbryt podinfo.test framsteg begärningstid 1,915s > 500ms
Avbryt podinfo.test framsteg begärningstid 2,050s > 500ms
Avbryt podinfo.test framsteg begärningstid 2,515s > 500ms
Tillbaka rullning podinfo.test misslyckade kontroller tröskel nådd 10
Canary misslyckades! Skalning ner av podinfo.test

Om du har aktiverat Slack-notifikationer får du ett meddelande när tidsgränsen överskrids eller det maximala antalet misslyckade kontroller uppnås under analysen:

Automatiska canary-deployments med Flagger och Istio

Avslutningsvis

Att köra en service mesh, som Istio, ovanpå Kubernetes ger automatiska mått, loggar och protokoll, men distribution av arbetsbelastningar beror fortfarande på externa verktyg. Flagger strävar efter att förändra detta genom att lägga till Istio-möjligheter progressiv leverans.

Flagger är kompatibel med alla CI/CD-lösningar för Kubernetes, och canary-analyser kan enkelt utvidgas med webhooks för att utföra systemintegrationstest, acceptanstest, belastningstest eller andra användarkontroller. Eftersom Flagger är deklarativt och reagerar på Kubernetes-händelser kan det användas i GitOps-flöden tillsammans med Weave Flux eller JenkinsX. Om du använder JenkinsX kan du installera Flagger med jx-tillägg.

Flagger stöds av Weaveworks och möjliggör canary-distributioner i Weave Cloud. Projektet testas på GKE, EKS och "bare metal" med kubeadm.

Om du har förslag på förbättringar av Flagger, vänligen skicka en fråga eller PR på GitHub till stefanprodan/flagger. Bidrag är mer än välkomna!

Tack Ray Tsan.

Källa: habr.com

Köp pålitlig webbhotell med DDoS-skydd, VPS VDS-servrar 🔥 Köp pålitlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster