Salta al contenuto > Deploy canary automatici con Flagger e Istio

Deploy canary automatici con Flagger e Istio

Deploy canary automatici con Flagger e Istio

Il CD è riconosciuto come una pratica di software aziendale, frutto dell'evoluzione naturale dei principi CI consolidate. Tuttavia, il CD resta un fenomeno piuttosto raro, probabilmente a causa della complessità della gestione e della paura di deploy fallimenti che influenzano la disponibilità del sistema.

Flagger è un operatore Kubernetes open source il cui obiettivo è eliminare le relazioni complicate. Automatizza la promozione dei deploy canary utilizzando il traffic shifting di Istio e le metriche di Prometheus per analizzare il comportamento dell'applicazione durante il rollout controllato.

Di seguito è riportata una guida passo passo per configurare e utilizzare Flagger in Google Kubernetes Engine (GKE).

Configurazione del cluster Kubernetes

Iniziate creando un cluster GKE con l'estensione Istio (se non avete un account GCP, potete registrarvi qui per ricevere crediti gratuiti).

Accedete a Google Cloud, create un progetto e abilitate la fatturazione per esso. Installate l'utilità da riga di comando gcloud e configurate il vostro progetto con gcloud init.

Impostate il progetto predefinito, la regione di calcolo e la zona (sostituite PROJECT_ID con il vostro progetto):

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

Attiva il servizio GKE e crea un cluster con HPA e add-on Istio:

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

Il comando sopra creerà un pool di nodi predefinito che include due VM n1-standard-2 (vCPU: 2, RAM 7,5 GB, disco: 30 GB). Idealmente, dovresti isolare i componenti Istio dai tuoi carichi di lavoro, ma non esiste un modo semplice per eseguire i pod Istio in un pool di nodi dedicati. I manifesti di Istio sono considerati di sola lettura e GKE annullerà qualsiasi modifica, ad esempio, il binding a un nodo o lo scollegamento da un pod.

Configura le credenziali per kubectl:

gcloud container clusters get-credentials istio

Crea un binding del ruolo di amministratore del cluster:

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

Installa lo strumento da riga di comando Helm:

brew install kubernetes-helm

Homebrew 2.0 è ora disponibile anche per Linux.

Crea un account di servizio e un binding del ruolo del cluster per Tiller:

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

Distribuisci Tiller nello spazio dei nomi kubectl -n kube-system edit cm kubelet-config-1.16:

helm init --service-account tiller

Dovresti considerare l'uso di SSL tra Helm e Tiller. Per ulteriori informazioni sulla protezione dell'installazione di Helm, vedi docs.helm.sh

Conferma le impostazioni:

kubectl -n istio-system get svc

Dopo alcuni secondi, GCP dovrebbe assegnare un indirizzo IP pubblico al servizio istio-ingressgateway.

Configurazione del gateway di ingresso Istio

Crea un indirizzo IP statico con il nome istio-gateway, utilizzando l'indirizzo IP del gateway Istio:

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

Ora hai bisogno di un dominio internet e dell'accesso al tuo registrar DNS. Aggiungi due record A (sostituisci example.com con il tuo dominio):

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

Assicurati che il wildcard DNS funzioni:

watch host test.istio.example.com

Crea un gateway pubblico Istio per fornire servizi al di fuori del service mesh tramite 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:
        - "*"

Salva il risorsa sopra indicata come public-gateway.yaml e poi applicalo:

kubectl apply -f ./public-gateway.yaml

Nessun sistema di produzione dovrebbe fornire servizi online senza SSL. Per proteggere il gateway di ingresso Istio con cert-manager, CloudDNS e Let’s Encrypt, ti preghiamo di leggere documentazione Flagger GKE.

Installazione di Flagger

Il componente GKE Istio non include un'istanza di Prometheus, che si occupa della raccolta dei dati di telemetria di Istio. Poiché Flagger utilizza le metriche Istio HTTP per eseguire l'analisi canary, è necessario distribuire la seguente configurazione di Prometheus, simile a quella fornita con lo schema ufficiale di Istio Helm.

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

Aggiungi il repository Flagger Helm:

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

Distribuisci Flagger nello spazio dei nomi istio-system, attivando le notifiche Slack:

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

Puoi installare Flagger in qualsiasi spazio dei nomi, purché possa interagire con il servizio Istio Prometheus sulla porta 9090.

Flagger dispone di un pannello di controllo Grafana per analisi canary. Installa Grafana nello spazio dei nomi 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

Esponi Grafana attraverso il gateway pubblico creando un servizio virtuale (sostituisci example.com con il tuo dominio):

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

Salva la risorsa sopra come grafana-virtual-service.yaml e poi applicala:

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

Navigando a http://grafana.istio.example.com nel browser dovresti essere reindirizzato alla pagina di accesso di Grafana.

Distribuzione di applicazioni web con Flagger

Flagger distribuisce Kubernetes e, se necessario, il ridimensionamento automatico orizzontale (HPA), crea quindi una serie di oggetti (deploy Kubernetes, servizi ClusterIP e servizi virtuali Istio). Questi oggetti espongono l'applicazione nella service mesh e gestiscono l'analisi e la promozione canary.

Deploy canary automatici con Flagger e Istio

Crea uno spazio dei nomi di test con l'iniezione Istio Sidecar abilitata:

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

Crea un deploy e uno strumento di scaling orizzontale automatico per il pod:

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

Implementa un servizio di carico di test per generare traffico durante l'analisi canary:

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

Crea una risorsa canary personalizzata (sostituisci example.com con il tuo dominio):

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

Salva la risorsa sopra indicata come podinfo-canary.yaml e poi applicala:

kubectl apply -f ./podinfo-canary.yaml

L'analisi sopra riportata, in caso di successo, verrà eseguita entro cinque minuti con controlli delle metriche HTTP ogni trenta secondi. Puoi determinare il tempo minimo necessario per verificare e promuovere il canary deployment utilizzando la seguente formula: interval * (maxWeight / stepWeight). I campi Canary CRD sono documentati qui.

Dopo qualche secondo, Flagger creerà gli oggetti canary:

# 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

Apri il browser e vai a app.istio.example.com, dovresti vedere il numero di versione dell'app demo.

Analisi e promozione automatica del canary

Flagger implementa un ciclo di gestione che sposta progressivamente il traffico verso il canary, misurando nel contempo le principali metriche di prestazione, come il tasso di successo delle richieste HTTP, la durata media delle richieste e la disponibilità del pod. In base all'analisi dei KPI, il canary viene promosso o interrotto, e i risultati dell'analisi vengono pubblicati in Slack.

Deploy canary automatici con Flagger e Istio

Il deployment del canary viene avviato quando viene modificato uno dei seguenti oggetti:

  • PodSpec del deployment (immagine del contenitore, comandi, porte, variabili d'ambiente, ecc.)
  • ConfigMaps montati come volumi o trasformati in variabili d'ambiente
  • Secrets montati come volumi o trasformati in variabili d'ambiente

Avvio del deploy canary durante l'aggiornamento dell'immagine del container:

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

Flagger rileva che la versione del deploy è cambiata e inizia ad analizzarla:

kubectl -n test describe canary/podinfo

Eventi:

Nuova revisione rilevata podinfo.test
Scaling up podinfo.test
In attesa del completamento del rollout di podinfo.test: 0 di 1 repliche aggiornate disponibili
Avanza il peso canary di podinfo.test a 5
Avanza il peso canary di podinfo.test a 10
Avanza il peso canary di podinfo.test a 15
Avanza il peso canary di podinfo.test a 20
Avanza il peso canary di podinfo.test a 25
Avanza il peso canary di podinfo.test a 30
Avanza il peso canary di podinfo.test a 35
Avanza il peso canary di podinfo.test a 40
Avanza il peso canary di podinfo.test a 45
Avanza il peso canary di podinfo.test a 50
Copia della specifica del template di podinfo.test in podinfo-primary.test
In attesa del completamento del rollout di podinfo-primary.test: 1 di 2 repliche aggiornate disponibili
Promozione completata! Scaling down podinfo.test

Durante l'analisi, i risultati canary possono essere monitorati tramite Grafana:

Deploy canary automatici con Flagger e Istio

Nota: se vengono applicate nuove modifiche al deploy durante l'analisi canary, Flagger riavvierà la fase di analisi.

Compila un elenco di tutti i "canarini" nel tuo cluster:

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

Se hai attivato le notifiche Slack, riceverai i seguenti messaggi:

Deploy canary automatici con Flagger e Istio

Rollback automatico

Durante l'analisi canary, è possibile generare errori sintentici HTTP 500 e alte latenze di risposta per verificare se Flagger interromperà il deployment.

Crea un pod di test e esegui il seguente comando:

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

Generazione di errori HTTP 500:

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

Generazione di latenze:

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

Quando il numero di controlli falliti raggiunge la soglia, il traffico viene reindirizzato al canale principale, il canary viene scalato a zero e il deployment viene contrassegnato come fallito.

Errori canary e picchi di latenze vengono registrati come eventi Kubernetes e registrati da Flagger in formato JSON:

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

Avvio del deployment canary per podinfo.test
Aumenta il peso canary di podinfo.test 5
Aumenta il peso canary di podinfo.test 10
Aumenta il peso canary di podinfo.test 15
Interrompi il tasso di successo dell'avanzamento di podinfo.test 69.17% < 99%
Interrompi il tasso di successo dell'avanzamento di podinfo.test 61.39% < 99%
Interrompi il tasso di successo dell'avanzamento di podinfo.test 55.06% < 99%
Interrompi il tasso di successo dell'avanzamento di podinfo.test 47.00% < 99%
Interrompi il tasso di successo dell'avanzamento di podinfo.test 37.00% < 99%
Interrompi la durata della richiesta di avanzamento di podinfo.test 1.515s > 500ms
Interrompi la durata della richiesta di avanzamento di podinfo.test 1.600s > 500ms
Interrompi la durata della richiesta di avanzamento di podinfo.test 1.915s > 500ms
Interrompi la durata della richiesta di avanzamento di podinfo.test 2.050s > 500ms
Interrompi la durata della richiesta di avanzamento di podinfo.test 2.515s > 500ms
Rollback di podinfo.test fallito, soglia di controlli superata 10
Canary fallito! Scaling down podinfo.test

Se hai attivato le notifiche Slack, riceverai un messaggio quando viene superata la scadenza o si raggiunge il numero massimo di controlli falliti durante l'analisi:

Deploy canary automatici con Flagger e Istio

In conclusione

L'esecuzione di un service mesh come Istio, oltre a Kubernetes, fornisce metriche automatiche, registri e protocolli, ma il deployment dei carichi di lavoro dipende ancora da strumenti esterni. Flagger mira a cambiare questa situazione, aggiungendo a Istio capacità di consegna progressiva.

Flagger è compatibile con qualsiasi soluzione CI/CD per Kubernetes e l'analisi canary può essere facilmente estesa utilizzando webhook per eseguire test sistematici di integrazione/accettazione, test di carico o qualsiasi altra verifica da parte dell'utente. Poiché Flagger è dichiarativo e reagisce agli eventi di Kubernetes, può essere utilizzato nei pipeline GitOps insieme a Weave Flux o JenkinsX. Se utilizzi JenkinsX, puoi installare Flagger con i plugin jx.

Flagger è supportato da Weaveworks e fornisce deploy canary in Weave Cloud. Il progetto è testato su GKE, EKS e su hardware bare metal con kubeadm.

Se hai suggerimenti per migliorare Flagger, ti preghiamo di inviare una domanda o un PR su GitHub all'indirizzo stefanprodan/flagger. I contributi sono più che benvenuti!

Grazie Ray Tsan.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS | ProHoster