ProHoster > Automatische Canary-Deployments mit Flagger und Istio

Automatische Canary-Deployments mit Flagger und Istio

Automatische Canary-Deployments mit Flagger und Istio

Continuous Delivery (CD) hat sich als Praxis im Bereich Unternehmenssoftware etabliert und ist das Ergebnis einer natürlichen Evolution fest verankerter CI-Prinzipien. Trotz seiner Bedeutung bleibt CD jedoch rar, möglicherweise aufgrund der Komplexität des Managements und der Angst vor misslungenen Deployments, die die Verfügbarkeit des Systems beeinträchtigen.

Flagger ist ein Open-Source-Kubernetes-Operator, dessen Ziel es ist, komplexe Abhängigkeiten zu eliminieren. Er automatisiert die Förderung von Canary-Deployments mithilfe von Istios Traffic-Shifting und Prometheus-Metriken, um das Verhalten der Anwendung während eines kontrollierten Rollouts zu analysieren.

Im Folgenden finden Sie eine Schritt-für-Schritt-Anleitung zur Einrichtung und Nutzung von Flagger in Google Kubernetes Engine (GKE).

Einrichtung des Kubernetes-Clusters

Sie beginnen mit der Erstellung eines GKE-Clusters mit aktivierter Istio-Erweiterung (falls Sie kein GCP-Konto haben, können Sie sich anmelden hier um kostenlose Credits zu erhalten).

Melden Sie sich bei Google Cloud an, erstellen Sie ein Projekt und aktivieren Sie die Abrechnung dafür. Installieren Sie das Befehlszeilenwerkzeug gcloud und konfigurieren Sie Ihr Projekt mit gcloud init.

Legen Sie das Standardprojekt, die Compute-Region und die Zone fest (ersetzen Sie PROJECT_ID für Ihr Projekt):

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

Aktivieren Sie den GKE-Dienst und erstellen Sie einen Cluster mit HPA und Istio-Add-ons:

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

Der obige Befehl erstellt einen standardmäßigen Node-Pool mit zwei VMs. n1-standard-2 (vCPU: 2, RAM 7,5 GB, Disk: 30 GB). Idealerweise sollten Sie die Istio-Komponenten von Ihren Arbeitslasten isolieren, jedoch gibt es keine einfache Möglichkeit, Istio-Pods in einem dedizierten Node-Pool auszuführen. Istio-Manifestdateien sind schreibgeschützt, und GKE wird alle Änderungen, wie z. B. eine Bindung an einen Node oder das Trennen von einem Pod, zurücksetzen.

Konfigurieren Sie die Anmeldeinformationen für kubectl:

gcloud container clusters get-credentials istio

Erstellen Sie eine Cluster-Administrator-Rollenbindung:

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

Installieren Sie das Kommandozeilenwerkzeug Helm:

brew install kubernetes-helm

Homebrew 2.0 ist jetzt auch verfügbar für Linux.

Erstellen Sie ein Dienstkonto und eine Cluster-Rollenbindung für Tiller:

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

Bereitstellen von Tiller im Namespace kube-system:

helm init --service-account tiller

Es wird empfohlen, SSL zwischen Helm und Tiller zu verwenden. Weitere Informationen zum Schutz der Helm-Installation finden Sie unter docs.helm.sh

Bestätigen Sie die Einstellungen:

kubectl -n istio-system get svc

In wenigen Sekunden sollte GCP eine externe IP-Adresse für den Dienst zuweisen istio-ingressgateway.

Konfiguration des Istio-Eingangsgateways

Erstellen Sie eine statische IP-Adresse mit dem Namen istio-gateway, indem Sie die IP-Adresse des Istio-Gateways verwenden:

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

Jetzt benötigen Sie eine Internet-Domain und Zugang zu Ihrem DNS-Registrar. Fügen Sie zwei A-Einträge hinzu (ersetzen Sie example.com durch Ihre Domain):

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

Stellen Sie sicher, dass der DNS-Wildcard funktioniert:

watch host test.istio.example.com

Erstellen Sie ein gemeinsames Istio-Gateway, um Dienste außerhalb des Service Mesh über HTTP bereitzustellen:

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:
        - "*"

Speichern Sie die obige Ressource als public-gateway.yaml und wenden Sie sie dann an:

kubectl apply -f ./public-gateway.yaml

Kein Produktionssystem sollte Dienste im Internet ohne SSL bereitstellen. Um das Istio-Eingangstor mit cert-manager, CloudDNS und Let’s Encrypt abzusichern, lesen Sie bitte die Dokumentation Flagger GKE.

Installation von Flagger

Die GKE Istio-Implementierung enthält keinen Prometheus-Instanz, die den Telemetrie-Dienst von Istio bereinigt. Da Flagger Istio-HTTP-Metriken für die Durchführung der Canary-Analyse verwendet, müssen Sie die folgende Prometheus-Konfiguration bereitstellen, die ähnlich der offiziellen Istio Helm-Chart ist.

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

Fügen Sie das Flagger Helm-Repository hinzu:

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

Deployen Sie Flagger im Namespace istio-system, einschließlich Slack-Benachrichtigungen:

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

Sie können Flagger in jedem Namespace installieren, sofern er mit dem Istio Prometheus-Dienst über Port 9090 kommunizieren kann.

Flagger bietet ein Grafana-Dashboard für die Canary-Analyse. Installieren Sie Grafana im Namespace 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

Öffnen Sie Grafana über das öffentliche Gateway, indem Sie einen virtuellen Dienst erstellen (ersetzen Sie example.com durch Ihre Domain):

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

Speichern Sie die oben genannte Ressource als grafana-virtual-service.yaml und wenden Sie sie anschließend an:

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

Wenn Sie zu http://grafana.istio.example.com navigieren, sollten Sie zur Anmeldeseite von Grafana weitergeleitet werden.

Bereitstellung von Webanwendungen mit Flagger

Flagger implementiert Kubernetes und, falls erforderlich, horizontale automatische Skalierung (HPA) und erstellt dann eine Reihe von Objekten (Kubernetes-Deployments, ClusterIP-Dienste und Istio-virtuelle Dienste). Diese Objekte öffnen die Anwendung im Service-Mesh und verwalten die Canary-Analyse und das Rollout.

Automatische Canary-Deployments mit Flagger und Istio

Erstellen Sie einen Test-namespace mit aktiviertem Istio Sidecar-Deployment:

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

Erstellen Sie ein Deployment und ein automatisches Horizontal-Pod-Skalierungswerkzeug:

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

Starten Sie einen Testlastdienst zur Traffic-Generierung während der Canary-Analyse:

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

Erstellen Sie eine benutzerdefinierte Canary-Ressource (ersetzen Sie example.com durch Ihre Domain):

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

Speichern Sie die oben genannte Ressource als podinfo-canary.yaml und wenden Sie sie dann an:

kubectl apply -f ./podinfo-canary.yaml

Die obige Analyse wird, sofern erfolgreich, innerhalb von fünf Minuten durchgeführt, wobei die HTTP-Metriken alle fünfzehn Sekunden überprüft werden. Die minimale Zeit, die für die Überprüfung und das Fortschreiten des Canary-Deployments erforderlich ist, kann mit folgender Formel bestimmt werden: intervall * (maxWeight / stepWeight). Die Felder der Canary CRD werden dokumentiert. hier.

In wenigen Sekunden wird Flagger Canary-Objekte erstellen:

# 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

Öffnen Sie den Browser und gehen Sie zu app.istio.example.com, Sie sollten die Versionsnummer sehen. der Demo-Anwendung..

Automatische Canary-Analyse und -Fortschritt

Flagger implementiert einen Steuerungszyklus, der den Verkehr schrittweise auf die Canary-Instanz verschiebt, während gleichzeitig wichtige Leistungskennzahlen wie die Erfolgsquote der HTTP-Anfragen, die durchschnittliche Anfragedauer und die Pods-Verfügbarkeit gemessen werden. Basierend auf der KPI-Analyse wird die Canary-Version vorangetrieben oder gestoppt, und die Analyseergebnisse werden in Slack veröffentlicht.

Automatische Canary-Deployments mit Flagger und Istio

Das Canary-Deployment wird ausgelöst, wenn eines der folgenden Objekte geändert wird:

  • Deployment PodSpec (Container-Image, Befehl, Ports, Umgebungsvariablen usw.)
  • ConfigMaps, die als Volumes gemountet oder in Umgebungsvariablen umgewandelt werden
  • Secrets, die als Volumes gemountet oder in Umgebungsvariablen umgewandelt werden

Start des Canary-Deployments beim Aktualisieren des Container-Images:

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

Flagger erkennt eine Änderung der Deployment-Version und beginnt mit deren Analyse:

kubectl -n test describe canary/podinfo

Ereignisse:

Neue Revision für podinfo.test erkannt
Scaling von podinfo.test
Warten auf den Abschluss des Rollouts von podinfo.test: 0 von 1 aktualisierten Replikaten sind verfügbar
Erhöhung des Canary-Gewichts für podinfo.test auf 5
Erhöhung des Canary-Gewichts für podinfo.test auf 10
Erhöhung des Canary-Gewichts für podinfo.test auf 15
Erhöhung des Canary-Gewichts für podinfo.test auf 20
Erhöhung des Canary-Gewichts für podinfo.test auf 25
Erhöhung des Canary-Gewichts für podinfo.test auf 30
Erhöhung des Canary-Gewichts für podinfo.test auf 35
Erhöhung des Canary-Gewichts für podinfo.test auf 40
Erhöhung des Canary-Gewichts für podinfo.test auf 45
Erhöhung des Canary-Gewichts für podinfo.test auf 50
Kopieren der Podinfo.test-Template-Spezifikation nach podinfo-primary.test
Warten auf den Abschluss des Rollouts von podinfo-primary.test: 1 von 2 aktualisierten Replikaten sind verfügbar
Beförderung abgeschlossen! Scaling von podinfo.test.

Während der Analyse können die Ergebnisse des Canary-Tests mit Grafana überwacht werden:

Automatische Canary-Deployments mit Flagger und Istio

Hinweis: Wenn während der Canary-Analyse neue Änderungen auf das Deployment angewendet werden, wird Flagger die Analysephase neu starten.

Erstellen Sie eine Liste aller "Canarys" in Ihrem Cluster:

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

Wenn Sie Slack-Benachrichtigungen aktiviert haben, erhalten Sie die folgenden Nachrichten:

Automatische Canary-Deployments mit Flagger und Istio

Automatisches Rollback

Während der Canary-Analyse können synthetische HTTP 500-Fehler und hohe Antwortverzögerungen erzeugt werden, um zu überprüfen, ob Flagger den Deployment-Prozess stoppt.

Erstellen Sie einen Test-Pod und führen Sie die folgende Aktion aus:

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

Erzeugung von HTTP 500-Fehlern:

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

Erzeugung von Verzögerungen:

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

Wenn die Anzahl der fehlgeschlagenen Prüfungen den Schwellenwert erreicht, wird der Verkehr zurück zum primären Kanal geleitet, der Canary-Pod auf null skaliert und das Deployment als fehlgeschlagen markiert.

Canary-Fehler und Spitzen bei den Verzögerungen werden als Kubernetes-Ereignisse registriert und von Flagger im JSON-Format protokolliert:

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

Starten der Canary-Bereitstellung für podinfo.test
Fortschritt des Canary-Gewichts von podinfo.test 5
Fortschritt des Canary-Gewichts von podinfo.test 10
Fortschritt des Canary-Gewichts von podinfo.test 15
Halten der Erfolgsquote der podinfo.test-Vorrückung 69,17% < 99%
Halten der Erfolgsquote der podinfo.test-Vorrückung 61,39% < 99%
Halten der Erfolgsquote der podinfo.test-Vorrückung 55,06% < 99%
Halten der Erfolgsquote der podinfo.test-Vorrückung 47,00% < 99%
Halten der Erfolgsquote der podinfo.test-Vorrückung 37,00%  500ms
Halten der Anforderungsdauer der podinfo.test-Vorrückung 1,600s > 500ms
Halten der Anforderungsdauer der podinfo.test-Vorrückung 1,915s > 500ms
Halten der Anforderungsdauer der podinfo.test-Vorrückung 2,050s > 500ms
Halten der Anforderungsdauer der podinfo.test-Vorrückung 2,515s > 500ms
Rollback von podinfo.test fehlgeschlagene Überprüfungen, Schwellenwert erreicht 10
Canary fehlgeschlagen! Verringere die Skalierung von podinfo.test

Wenn Sie Slack-Benachrichtigungen aktiviert haben, erhalten Sie eine Nachricht, wenn die Frist überschritten wird oder die maximale Anzahl fehlgeschlagener Überprüfungen während der Analyse erreicht wird:

Automatische Canary-Deployments mit Flagger und Istio

Zusammenfassung

Der Betrieb einer Service-Mesh-Lösung wie Istio zusätzlich zu Kubernetes bietet automatische Metriken, Protokolle und Logs, jedoch hängt die Bereitstellung von Workloads weiterhin von externen Werkzeugen ab. Flagger zielt darauf ab, diese Situation zu ändern, indem es Istio-Funktionalitäten hinzufügt progressive Auslieferung.

Flagger ist mit allen CI/CD-Lösungen für Kubernetes kompatibel, und die Canary-Analyse kann leicht erweitert werden durch Webhooks für systemische Integrations-/Abnahmetests, Lasttests oder andere benutzerdefinierte Überprüfungen. Da Flagger deklarativ ist und auf Kubernetes-Ereignisse reagiert, kann es in GitOps-Pipelines zusammen mit Weave Flux oder JenkinsX. Wenn Sie JenkinsX verwenden, können Sie Flagger mit jx-Erweiterungen installieren.

Flagger wird unterstützt von Weaveworks und ermöglicht Canary-Deployments in Weave Cloud. Das Projekt wird auf GKE, EKS und „bare metal“ mit kubeadm getestet.

Wenn Sie Vorschläge zur Verbesserung von Flagger haben, senden Sie bitte Ihre Fragen oder PR auf GitHub an stefanprodan/flagger. Beiträge sind jederzeit willkommen!

Danke Ray Chan.

Quelle: habr.com

Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen 🔥 Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster