Die CD wird als Entwicklungspraxis für Unternehmenssoftware anerkannt und ist das Ergebnis einer natürlichen Weiterentwicklung etablierter CI-Prinzipien. CD kommt jedoch immer noch eher selten vor, möglicherweise aufgrund der Komplexität der Verwaltung und der Angst vor nicht erfolgreichen Bereitstellungen, die sich auf die Systemverfügbarkeit auswirken.
Flagger ist ein Open-Source-Kubernetes-Betreiber, der verwirrende Beziehungen beseitigen soll. Es automatisiert die Förderung kanarischer Bereitstellungen mithilfe von Istio-Verkehrsversätzen und Prometheus-Metriken, um das Anwendungsverhalten während des verwalteten Rollouts zu analysieren.
Im Folgenden finden Sie eine schrittweise Anleitung zum Konfigurieren und Verwenden von Flagger in der Google Kubernetes Engine (GKE).
Konfigurieren Sie den Kubernetes-Cluster
Sie erstellen zunächst einen GKE-Cluster mit einem Istio-Add-In (wenn Sie kein GCP-Konto haben, können Sie sich hier registrieren, um kostenlose Credits zu erhalten).
Melden Sie sich bei Google Cloud an, erstellen Sie ein Projekt und aktivieren Sie die Abrechnung. Installieren Sie das Befehlszeilenprogramm gcloud und gcloud init Ihr Projekt mit gcloud init .
PROJECT_ID Sie das Standardprojekt, den Berechnungsbereich und die Zone fest (ersetzen Sie PROJECT_ID durch 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
Mit dem obigen Befehl wird ein Standardknotenpool erstellt, der zwei VMs n1-standard-2 (vCPU: 2, RAM 7,5 GB, Festplatte: 30 GB). Im Idealfall lohnt es sich, Istio-Komponenten von ihren Workloads zu isolieren. Es gibt jedoch keine einfache Möglichkeit, Istio-Pods in einem dedizierten Knotenpool auszuführen. Istio-Manifeste gelten als schreibgeschützt, und GKE macht alle Änderungen rückgängig, z. B. das Binden an einen Knoten oder das Trennen von einem Herd.
Anmeldeinformationen für kubectl :
gcloud container clusters get-credentials istio
Erstellen Sie die Clusteradministrator-Rollenbindung:
kubectl create clusterrolebinding "cluster-admin-$(whoami)" \ --clusterrole=cluster-admin \ --user="$(gcloud config get-value core/account)"
Installieren Sie das Helm- Befehlszeilentool:
brew install kubernetes-helm
Homebrew 2.0 ist jetzt auch für Linux verfügbar.
Erstellen Sie ein Dienstkonto und eine Clusterrollenbindung für Tiller:
kubectl -n kube-system create sa tiller && \ kubectl create clusterrolebinding tiller-cluster-rule \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:tiller
Erweitern Sie Tiller im kube-system des kube-system :
helm init --service-account tiller
Sie sollten die Verwendung von SSL zwischen Helm und Tiller in Betracht ziehen. Weitere Informationen zum Sichern einer Helm-Installation finden Sie unter docs.helm.sh
Einstellungen bestätigen:
kubectl -n istio-system get svc
Nach einigen Sekunden sollte GCP eine externe IP-Adresse für den Dienst istio-ingressgateway .
Istio Input Gateway Setup
Erstellen Sie eine statische IP-Adresse namens istio-gateway mit der IP-Adresse des Istio-Gateways:
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 Internetdomain und Zugriff auf Ihren 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-Platzhalter funktioniert:
watch host test.istio.example.com
Erstellen Sie ein gemeinsames Istio-Gateway, um Dienste außerhalb des Dienstnetzes ü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 oben genannte Ressource als public-gateway.yaml und wenden Sie sie dann an:
kubectl apply -f ./public-gateway.yaml
Kein Produktionssystem sollte ohne SSL Dienste im Internet bereitstellen. Lesen Sie die Flagger GKE- Dokumentation, um das Istio-Gateway mit Cert-Manager, CloudDNS und Let's Encrypt zu schützen.
Flagger-Installation
Das GKE Istio-Add-In enthält nicht die Prometheus-Instanz, mit der der Istio-Telemetriedienst bereinigt wird. Da Flagger Istio-HTTP-Metriken verwendet, um eine Kanarienanalyse durchzuführen, müssen Sie die folgende Prometheus-Konfiguration bereitstellen, die der mit dem offiziellen Istio-Helm-Schema gelieferten ähnelt.
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
Erweitern Sie Flagger im istio-system des istio-Systems, istio-system Slack-Benachrichtigungen aktivieren:
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 einem beliebigen Namespace installieren, wenn es über Port 9090 mit dem Istio Prometheus-Dienst kommunizieren kann.
Flagger verfügt über ein Grafana-Dashboard für die Kanarienvogelanalyse. Installieren Sie Grafana im 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
Erweitern Sie Grafana über ein offenes 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 dann an:
kubectl apply -f ./grafana-virtual-service.yaml
Wenn Sie in einem Browser zu http://grafana.istio.example.com gehen, sollten Sie zur Grafana-Anmeldeseite weitergeleitet werden.
Bereitstellung von Webanwendungen mit Flagger
Flagger stellt Kubernetes bereit und erstellt bei Bedarf die horizontale automatische Skalierung (HPA). Anschließend werden eine Reihe von Objekten erstellt (Kubernetes-Bereitstellungen, ClusterIP-Dienste und virtuelle Istio-Dienste). Diese Objekte öffnen die Anwendung im Service-Mesh und verwalten die Kanarienanalyse und -werbung.
Erstellen Sie einen Test-Namespace mit aktivierter Istio Sidecar-Implementierung:
REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml
Erstellen Sie ein automatisches horizontales Skalierungswerkzeug für Bereitstellung und Herd:
kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml
Stellen Sie einen Testladeservice bereit, um während der Kanarienanalyse Datenverkehr zu generieren:
helm upgrade -i flagger-loadtester flagger/loadtester \ --namepace=test
Erstellen Sie eine benutzerdefinierte kanarische 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 bei Erfolg innerhalb von fünf Minuten durchgeführt, wobei die HTTP-Metriken jede halbe Minute überprüft werden. Sie können die Mindestzeit festlegen, die erforderlich ist, um eine kanarische Bereitstellung zu überprüfen und zu fördern, indem Sie die folgende Formel verwenden: interval * (maxWeight / stepWeight) . Kanarische CRD-Felder sind hier dokumentiert.
In wenigen Sekunden erstellt Flagger kanarische Objekte:
# 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 einen Browser und gehen Sie zu app.istio.example.com . Die Versionsnummer der Demo-Anwendung sollte app.istio.example.com .
Automatische Kanarienanalyse und Promotion
Flagger implementiert einen Regelkreis, der den Verkehr schrittweise auf den Kanarienvogel verlagert, während wichtige Leistungsindikatoren gemessen werden, z. B. die Erfolgsrate von HTTP-Anforderungen, die durchschnittliche Dauer von Anforderungen und die Leistung des Herdes. Basierend auf der Analyse wird der KPI-Kanarienvogel weiterentwickelt oder unterbrochen, und die Analyseergebnisse werden in Slack veröffentlicht.
Die kanarische Bereitstellung beginnt, wenn sich eines der folgenden Objekte ändert:
- Stellen Sie PodSpec bereit (Container-Image, Befehl, Ports, Umgebung usw.)
- ConfigMaps werden als Volumes bereitgestellt oder in Umgebungsvariablen konvertiert
- Geheimnisse werden als Volumes bereitgestellt oder in Umgebungsvariablen konvertiert
Starten einer kanarischen Bereitstellung beim Aktualisieren eines Container-Images:
kubectl -n test set image deployment/podinfo \ podinfod=quay.io/stefanprodan/podinfo:1.4.1
Flagger stellt fest, dass sich die Bereitstellungsversion geändert hat, und beginnt mit der Analyse:
kubectl -n test describe canary/podinfo Events: New revision detected podinfo.test Scaling up podinfo.test Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available Advance podinfo.test canary weight 5 Advance podinfo.test canary weight 10 Advance podinfo.test canary weight 15 Advance podinfo.test canary weight 20 Advance podinfo.test canary weight 25 Advance podinfo.test canary weight 30 Advance podinfo.test canary weight 35 Advance podinfo.test canary weight 40 Advance podinfo.test canary weight 45 Advance podinfo.test canary weight 50 Copying podinfo.test template spec to podinfo-primary.test Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available Promotion completed! Scaling down podinfo.test
Während der Analyse können kanarische Ergebnisse mit Grafana verfolgt werden:
Bitte beachten Sie: Wenn während der kanarischen Analyse neue Änderungen an der Bereitstellung vorgenommen werden, startet Flagger die Analysephase neu.
Erstellen Sie eine Liste aller "Kanarienvögel" 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 Meldungen:
Auto Rollback
Während der Kanarienanalyse können Sie synthetische HTTP 500-Fehler und eine hohe Antwortverzögerung generieren, um zu überprüfen, ob Flagger die Bereitstellung stoppt.
Erstellen Sie ein Test-Sub und führen Sie die folgenden Schritte 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
HTTP 500-Fehlergenerierung:
watch curl http://podinfo-canary:9898/status/500
Verzögerungsgenerierung:
watch curl http://podinfo-canary:9898/delay/1
Wenn die Anzahl der nicht erfolgreichen Überprüfungen den Schwellenwert erreicht, wird der Datenverkehr zurück zum primären Kanal geleitet, Canary wird auf Null skaliert und die Bereitstellung wird als nicht erfolgreich markiert.
Kanarische Fehler und Verzögerungsspitzen werden als Kubernetes-Ereignisse protokolliert und von Flagger im JSON-Format aufgezeichnet:
kubectl -n istio-system logs deployment/flagger -f | jq .msg Starting canary deployment for podinfo.test Advance podinfo.test canary weight 5 Advance podinfo.test canary weight 10 Advance podinfo.test canary weight 15 Halt podinfo.test advancement success rate 69.17% < 99% Halt podinfo.test advancement success rate 61.39% < 99% Halt podinfo.test advancement success rate 55.06% < 99% Halt podinfo.test advancement success rate 47.00% < 99% Halt podinfo.test advancement success rate 37.00% < 99% Halt podinfo.test advancement request duration 1.515s > 500ms Halt podinfo.test advancement request duration 1.600s > 500ms Halt podinfo.test advancement request duration 1.915s > 500ms Halt podinfo.test advancement request duration 2.050s > 500ms Halt podinfo.test advancement request duration 2.515s > 500ms Rolling back podinfo.test failed checks threshold reached 10 Canary failed! Scaling down podinfo.test
Wenn Sie Slack-Benachrichtigungen aktiviert haben, erhalten Sie eine Nachricht, wenn die Frist erreicht ist oder wenn die maximale Anzahl fehlgeschlagener Überprüfungen während der Analyse erreicht ist:
Abschließend
Das Starten eines Service-Meshs wie Istio zusätzlich zu Kubernetes bietet automatische Metriken, Protokolle und Protokolle. Die Bereitstellung von Workloads hängt jedoch weiterhin von externen Tools ab. Flagger versucht dies zu ändern, indem es die progressiven Bereitstellungsfunktionen von Istio hinzufügt.
Flagger ist mit jeder Kubernetes CI / CD-Lösung kompatibel. Die Kanarienanalyse kann mithilfe von Webhooks problemlos erweitert werden, um Systemintegrations- / Abnahmetests, Stresstests oder andere Benutzertests durchzuführen. Da Flagger deklarativ ist und auf Kubernetes-Ereignisse reagiert, kann es in GitOps-Pipelines mit Weave Flux oder JenkinsX verwendet werden . Wenn Sie JenkinsX verwenden, können Sie Flagger mit jx-Add-Ons installieren.
Flagger wird von Weaveworks unterstützt und bietet kanarische Bereitstellungen für Weave Cloud . Das Projekt wird auf GKE, EX und Bare Metal mit Kubeadm getestet.
Wenn Sie Vorschläge zur Verbesserung von Flagger haben, senden Sie bitte eine Frage oder PR an GitHub unter stefanprodan / flagger . Beiträge sind herzlich willkommen!
Vielen Dank, Ray Tsang .