Canary-Bereitstellung in Kubernetes #3: Istio

Verwenden von Istio+Kiali zum Starten und Visualisieren einer Canary-Bereitstellung

Artikel dieser Reihe

1. Canary-Bereitstellung in Kubernetes Nr. 1: Gitlab CI
2. Canary-Bereitstellung in Kubernetes #2: Argo-Rollouts
3. (Dieser Artikel)
4. Canary-Bereitstellung mit Jenkins-X Istio Flagger

Canary-Bereitstellung

Wir hoffen, dass Sie lesen der erste Teil, wo wir kurz erklärten, was Canary-Bereitstellungen sind, und zeigten, wie man sie mit Standard-Kubernetes-Ressourcen implementiert.

Istio

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

Bewerbung für Tests

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

Wir werden eine einfache Testanwendung mit Frontend-Nginx- und Backend-Python-Pods verwenden. Der Nginx-Pod leitet jede Anfrage einfach an den Backend-Pod um und fungiert als Proxy. Details finden Sie in den folgenden Yamls:

• frontend.yaml
• backend.yaml
• istio.yaml

Führen Sie die Testanwendung selbst aus

Wenn Sie meinem Beispiel folgen und diese Testanwendung selbst verwenden möchten, lesen Sie Projekt-Readme.

Erstbereitstellung

Wenn wir die erste Bereitstellung starten, sehen wir, dass die Pods unserer Anwendung nur zwei Container haben, das heißt, der Istio-Sidecar wird gerade implementiert:

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

Verkehrsgenerierung

Wir werden die folgende IP verwenden, um Datenverkehr zu generieren, der von den Frontend-Pods empfangen 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 hinzufügen frontend.istio-test zu unserer Hosts-Datei.

Mesh über Kiali anzeigen

Wir haben die Testanwendung und Istio zusammen mit Tracing, Grafana, Prometheus und Kiali installiert (Details siehe unten). Projekt-Readme). Deshalb können wir Kiali nutzen über:

istioctl dashboard kiali # admin:admin

Kiali visualisiert den aktuellen Verkehr über Mesh

Wie wir sehen, gehen 100 % des Datenverkehrs an den Frontend-Dienst und dann an die Frontend-Pods mit der Bezeichnung v1, da wir einen einfachen Nginx-Proxy verwenden, der Anfragen an den Backend-Dienst umleitet, der sie wiederum an die Backend-Pods weiterleitet mit Etikett v1.

Kiali funktioniert hervorragend mit Istio und bietet eine Box-Lösung für das Mesh-Rendering. Einfach toll.

Canary-Bereitstellung

Unser Backend verfügt bereits über zwei k8s-Bereitstellungen, eine für v1 und eine für v2. Jetzt müssen wir Istio nur noch anweisen, einen bestimmten Prozentsatz der Anfragen an v2 weiterzuleiten.

Schritt 1: 10 %

Und alles, was wir tun müssen, ist die Gewichtung des VirtualService anzupassen 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 reicht es, ihn nur noch 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 die Canary-Bereitstellung als abgeschlossen betrachtet werden und der gesamte Datenverkehr wird auf v2 umgeleitet:

Canary manuell testen

Nehmen wir an, wir senden jetzt 2 % aller Anfragen an das v10-Backend. Was wäre, wenn wir v2 manuell testen möchten, um sicherzustellen, dass alles wie erwartet funktioniert?

Wir können eine spezielle Übereinstimmungsregel hinzufügen, die auf HTTP-Headern basiert:

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 eine v2-Anfrage erzwingen, indem wir den Header senden:

Anfragen ohne Header unterliegen weiterhin dem Verhältnis 1/10:

Canary für zwei abhängige Versionen

Jetzt betrachten wir die Option, bei der wir Version v2 sowohl für das Frontend als auch für das Backend haben. Für beide haben wir angegeben, dass 10 % des Datenverkehrs an v2 gehen sollen:

Wir sehen, dass Frontend v1 und v2 beide den Datenverkehr im Verhältnis 1/10 zu Backend v1 und v2 weiterleiten.

Was wäre, wenn wir den Datenverkehr von Frontend-v2 nur an Backend-v2 weiterleiten müssten, weil er nicht mit v1 kompatibel ist? Dazu legen wir ein Verhältnis von 1/10 für das Frontend fest, das über Aushandlung steuert, welcher Datenverkehr zum Backend-v2 gelangt 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

Als Ergebnis bekommen wir, was wir brauchen:

Unterschiede zum manuellen Canary-Ansatz

В der erste Teil Wir haben die Canary-Bereitstellung manuell durchgeführt und dabei auch zwei k8s-Bereitstellungen verwendet. Dort haben wir das Verhältnis der Anfragen gesteuert, indem wir die Anzahl der Replikate geändert haben. Dieser Ansatz funktioniert, hat jedoch schwerwiegende Nachteile.

Istio ermöglicht es, das Verhältnis der Anfragen unabhängig von der Anzahl der Replikate zu bestimmen. Das bedeutet zum Beispiel, dass wir HPAs (Horizontal Pod Autoscaler) nutzen können und nicht entsprechend dem aktuellen Stand der Canary-Bereitstellung konfiguriert werden müssen.

Ergebnis

Istio funktioniert großartig und die Verwendung zusammen mit Kiali ergibt eine sehr leistungsstarke Kombination. Als nächstes steht auf meiner Interessenliste die Kombination von Spinnaker mit Istio für Automatisierung und Canary Analytics.

Source: habr.com