🥇Canary Deployment in Kubernetes #3: Istio

Verwendung von Istio+Kiali zur Durchführung und Visualisierung von Canary Deployments

Artikel dieser Reihe

Canary Deployment in Kubernetes #1: Gitlab CI
Canary Deployment in Kubernetes #2: Argo Rollouts
(dieser Artikel)
Canary Deployment mit Jenkins-X Istio Flagger

Canary Deployment

Wir hoffen, dass Sie gelesen haben den ersten Teil, wo wir kurz erklärt haben, was Canary Deployments sind und gezeigt haben, wie man sie mit Standardressourcen von Kubernetes umsetzt.

Istio

Und wir gehen davon aus, dass Sie beim Lesen dieses Artikels bereits wissen, was Istio ist. Wenn nicht, können Sie darüber lesen hier.

Testanwendung

Jeder Pod enthält zwei Container: unsere Anwendung und den istio-proxy.

Wir werden eine einfache Testanwendung mit den Pods frontend-nginx und backend in Python verwenden. Der Pod mit nginx leitet einfach jede Anfrage an den Pod mit dem Backend weiter und fungiert als Proxy. Die Details können in den folgenden Yamls näher betrachtet werden:

Eigenständiger Start der Testanwendung

Wenn Sie meinem Beispiel folgen und diese Testanwendung eigenständig nutzen möchten, siehe readme des Projekts.

Erster Deployment

Beim Start des ersten Deployments sehen wir, dass die Pods unserer Anwendung jeweils nur 2 Container haben, das heißt, die Istio Sidecar wird erst eingefügt:

Und wir sehen auch den Istio Gateway Loadbalancer im Namespace istio-system:

Erstellung des Traffics

Wir werden die folgende IP verwenden, um den Traffic zu generieren, der von den Frontend-Pods akzeptiert und an die Backend-Pods weitergeleitet wird:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Wir werden auch frontend.istio-test in unsere Hosts-Datei hinzufügen.

Mesh-Ansicht über Kiali

Wir haben eine Testanwendung und Istio zusammen mit Tracing, Grafana, Prometheus und Kiali installiert (weitere Details siehe readme des Projekts). Daher können wir Kiali über folgende Adresse nutzen:

istioctl dashboard kiali # admin:admin

Kiali visualisiert den aktuellen Verkehr durch das Mesh

Wie wir sehen, gelangt 100 % des Traffics zum Frontend-Service, dann zum Pod des Frontends mit dem Label v1, da wir einen einfachen Nginx-Proxy verwenden, der Anfragen an den Backend-Service weiterleitet, der wiederum sie an die Backend-Pods mit dem Label v1 weiterleitet.

Kiali funktioniert hervorragend mit Istio und bietet eine schlüsselfertige Lösung zur Visualisierung des Meshs. Einfach großartig.

Canary Deployment

Unser Backend hat bereits zwei k8s-Deployments, eines für v1 und eines für v2. Jetzt müssen wir lediglich Istio anweisen, einen bestimmten Prozentsatz der Anfragen an v2 weiterzuleiten.

Schritt 1: 10 %

Und alles, was wir tun müssen, ist, das Gewicht des VirtualService in istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Wir sehen, dass 10% der Anfragen an v2 umgeleitet werden.

Schritt 2: 50%

Und jetzt genügt es, den Wert auf 50% zu erhöhen:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Schritt 3: 100%

Jetzt kann das Canary Deployment als abgeschlossen betrachtet werden und der gesamte Traffic wird auf v2 umgeleitet:

Manuelles Testen von Canary

Angenommen, wir senden derzeit 10% aller Anfragen an das Backend v2. Was, wenn wir v2 manuell testen möchten, um sicherzustellen, dass alles wie erwartet funktioniert?

Wir können eine spezielle entsprechende Regel basierend auf HTTP-Headern hinzufügen:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Jetzt können wir mit curl v2 erzwingen, indem wir den Header senden:

Anfragen ohne Header werden weiterhin im Verhältnis 1/10 gesteuert:

Canary für zwei abhängige Versionen

Jetzt betrachten wir den Fall, in dem wir die Version v2 sowohl für das Frontend als auch für das Backend haben. Für beide haben wir angegeben, dass 10% des Traffics zu v2 gehen sollen:

Wir sehen, dass sowohl frontend v1 als auch v2 den Traffic im Verhältnis 1/10 auf backend v1 und v2 weiterleiten.

Was wäre, wenn wir den Traffic von frontend-v2 nur auf backend-v2 leiten müssten, weil es nicht mit v1 kompatibel ist? Dafür legen wir ein Verhältnis von 1/10 für das Frontend fest, welches kontrolliert, welcher Traffic auf backend-v2 gelangt, indem es sich auf sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Das Ergebnis ist das, was benötigt wird:

Unterschiede zum manuellen Canary-Ansatz

In dem ersten Teil Wir haben Canary Deployments manuell durchgeführt, indem wir ebenfalls zwei k8s Deployments verwendet haben. Dort haben wir das Verhältnis der Anfragen gesteuert, indem wir die Anzahl der Repliken geändert haben. Dieser Ansatz funktioniert, hat aber ernsthafte Nachteile.

Istio ermöglicht es, das Verhältnis der Anfragen unabhängig von der Anzahl der Repliken zu definieren. Das bedeutet zum Beispiel, dass wir HPAs (Horizontal Pod Autoscalers) verwenden können, und es muss nicht an den aktuellen Zustand des Canary Deployments angepasst werden.

Zusammenfassung

Istio funktioniert hervorragend, und in Kombination mit Kiali erhalten wir eine sehr leistungsstarke Kombination. Als Nächstes interessiert mich die Kombination von Spinnaker mit Istio zur Automatisierung und Canary-Analytik.

Quelle: habr.com