🥇Canary-Bereitstellung in Kubernetes #1: Gitlab CI

Wir werden Gitlab CI und manuelles GitOps verwenden, um die Canary-Bereitstellung in Kubernetes zu implementieren und zu verwenden

Artikel aus dieser Serie:

(Dieser Artikel)
Canary-Bereitstellung mit ArgoCI
Canary-Bereitstellung mit Istio
Canary-Bereitstellung mit Jenkins-X Istio Flagger

Wir werden die Canary-Bereitstellung manuell über GitOps durchführen und die wichtigsten Kubernetes-Ressourcen erstellen/ändern. Dieser Artikel dient in erster Linie der Einführung mit der Funktionsweise der Bereitstellung in Kubernetes Canary, da es effektivere Automatisierungsmethoden gibt, die wir in den folgenden Artikeln betrachten werden.

https://www.norberteder.com/canary-deployment/

Canary-Bereitstellung

Bei der Canary-Strategie werden Updates zunächst nur auf eine Teilmenge der Benutzer angewendet. Durch Überwachung, Protokolldaten, manuelle Tests oder andere Feedbackkanäle wird die Version getestet, bevor sie für alle Benutzer freigegeben wird.

Kubernetes-Bereitstellung (laufendes Update)

Die Standardstrategie für die Kubernetes-Bereitstellung ist das Rolling-Update, bei dem eine bestimmte Anzahl von Pods mit neuen Versionen der Images gestartet wird. Wenn sie ohne Probleme erstellt wurden, werden Pods mit alten Versionen von Bildern beendet und neue Pods parallel erstellt.

GitOps

Wir verwenden GitOps in diesem Beispiel, weil wir:

Verwendung von Git als Single Source of Truth
Wir verwenden Git Operations für Build und Bereitstellung (außer Git Tag/Merge sind keine anderen Befehle erforderlich).

Beispiel

Nehmen wir eine bewährte Vorgehensweise: ein Repository für Anwendungscode und eines für die Infrastruktur.

Anwendungs-Repository

Dies ist eine sehr einfache Python+Flask-API, die eine Antwort als JSON zurückgibt. Wir werden das Paket über GitlabCI erstellen und das Ergebnis an die Gitlab-Registrierung übertragen. In der Registry haben wir zwei verschiedene Release-Versionen:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Der einzige Unterschied zwischen ihnen besteht in der Änderung in der zurückgegebenen JSON-Datei. Wir nutzen diese Anwendung, um möglichst einfach zu visualisieren, mit welcher Version wir kommunizieren.

Infrastruktur-Repository

In dieser Rübe werden wir über GitlabCI auf Kubernetes bereitstellen, .gitlab-ci.yml выглядит следующим образом:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

Um es selbst auszuführen, benötigen Sie einen Cluster. Sie können Gcloud verwenden:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Du musst forken https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure und eine Variable erstellen KUBECONFIG in GitlabCI, das die Konfiguration für den Zugriff enthält kubectl zu Ihrem Cluster.

Sie können lesen, wie Sie Anmeldeinformationen für einen Cluster (Gcloud) erhalten. hierher.

Infrastruktur Yaml

Im Infrastruktur-Repository haben wir folgende Dienste:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

Und Einsatz in deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Und ein weiterer Einsatz in deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Beachten Sie, dass für app-deploy noch keine Replikate definiert sind.

Durchführen der Erstbereitstellung

Um die Erstbereitstellung zu starten, können Sie die GitlabCI-Pipeline manuell im Master-Zweig starten. Danach kubectl sollte folgendes ausgeben:

Wir sehen app Bereitstellung mit 10 Replikaten und App-Canary mit 0. Es gibt auch einen LoadBalancer, über den wir zugreifen können curl über externe IP:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Wir sehen, dass unsere Testanwendung nur „v1“ zurückgibt.

Canary-Bereitstellung wird ausgeführt

Schritt 1: Geben Sie für einige Benutzer eine neue Version frei

Wir setzen die Anzahl der Replikate in der Datei „deploy-canary.yaml“ und im Image der neuen Version auf 1:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Im Ordner deploy.yaml Wir haben die Anzahl der Replikate auf 9 geändert:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Wir pushen diese Änderungen in das Repository, von dem aus die Bereitstellung startet (über GitlabCI) und sehen als Ergebnis:

Unser Dienst verweist auf beide Bereitstellungen, da beide über die App-Auswahl verfügen. Aufgrund der Standard-Randomisierung von Kubernetes sollten wir bei etwa 10 % der Anfragen unterschiedliche Antworten sehen:

Der aktuelle Status unserer Anwendung (GitOps, übernommen von Git als Single Source Of Truth) ist das Vorhandensein von zwei Bereitstellungen mit aktiven Replikaten, eines für jede Version.

Etwa 10 % der Benutzer werden mit einer neuen Version vertraut und testen sie ungewollt. Jetzt ist es an der Zeit, die Protokolle und Überwachungsdaten auf Fehler zu überprüfen, um Probleme zu finden.

Schritt 2: Geben Sie die neue Version für alle Benutzer frei

Wir haben entschieden, dass alles gut gelaufen ist und müssen nun die neue Version allen Benutzern zur Verfügung stellen. Dazu aktualisieren wir einfach deploy.yaml Installieren einer neuen Version des Images und die Anzahl der Replikate gleich 10. In deploy-canary.yaml Wir setzen die Anzahl der Replikate wieder auf 0. Nach der Bereitstellung sieht das Ergebnis wie folgt aus:

Zusammenfassend

Für mich hilft die manuelle Ausführung der Bereitstellung auf diese Weise zu verstehen, wie einfach sie mit k8s konfiguriert werden kann. Da Sie mit Kubernetes alles über eine API aktualisieren können, können diese Schritte durch Skripte automatisiert werden.

Außerdem muss ein Tester-Einstiegspunkt (LoadBalancer oder über Ingress) implementiert werden, über den nur auf die neue Version zugegriffen werden kann. Es kann zum manuellen Durchsuchen verwendet werden.

In zukünftigen Artikeln werden wir uns andere automatisierte Lösungen ansehen, die den Großteil unserer Arbeit umsetzen.

Lesen Sie auch andere Artikel in unserem Blog:

Source: habr.com

Canary-Bereitstellung in Kubernetes Nr. 1: Gitlab CI