Wdrożenie Canary w Kubernetes #3: Istio

Użycie Istio+Kiali do uruchomienia i wizualizacji wdrożenia Canary

Artykuły z tej serii

1. Wdrożenie Canary w Kubernetes nr 1: Gitlab CI
2. Wdrożenie Canary w Kubernetes nr 2: Wdrożenia Argo
3. (Ten artykuł)
4. Wdrożenie Canary przy użyciu Jenkins-X Istio Flagger

Wdrożenie na Wyspach Kanaryjskich

Mamy nadzieję, że czytasz pierwsza część, gdzie pokrótce wyjaśniliśmy czym są wdrożenia Canary i pokazaliśmy jak je wdrożyć przy wykorzystaniu standardowych zasobów Kubernetesa.

Podobnie

Zakładamy, że czytając ten artykuł, już wiesz, czym jest Istio. Jeśli nie, możesz o tym przeczytać tutaj.

Wniosek o testy

Każdy pod zawiera dwa kontenery: naszą aplikację i istio-proxy.

Będziemy używać prostej aplikacji testowej z podami frontend-nginx i backend python. Pod Nginx po prostu przekieruje każde żądanie do modułu zaplecza i będzie działać jako serwer proxy. Szczegóły można znaleźć w następujących plikach yaml:

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

Samodzielne uruchomienie aplikacji testowej

Jeśli chcesz pójść za moim przykładem i samodzielnie skorzystać z tej aplikacji testowej, zobacz plik readme projektu.

Początkowe wdrożenie

Kiedy uruchamiamy pierwsze wdrożenie, widzimy, że pody naszej aplikacji mają tylko 2 kontenery, czyli wózek boczny Istio jest dopiero wdrażany:

W przestrzeni nazw widzimy także Istio Gateway Loadbalancer istio-system:

Generowanie ruchu

Będziemy używać następującego adresu IP do generowania ruchu, który będzie odbierany przez frontend pody i przekazywany do backend podów:

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

Dodamy również frontend.istio-test do naszego pliku hosts.

Zobacz siatkę przez Kiali

Zainstalowaliśmy aplikację testową i Istio wraz z Tracing, Grafana, Prometheus i Kiali (szczegóły poniżej). plik readme projektu). Dlatego możemy używać Kiali poprzez:

istioctl dashboard kiali # admin:admin

Kiali wizualizuje bieżący ruch poprzez Mesh

Jak widzimy, 100% ruchu trafia do usługi frontendowej, a następnie do podów frontendowych z etykietą v1, ponieważ używamy prostego proxy nginx, który przekierowuje żądania do usługi backendowej, która z kolei przekierowuje je do podów backendowych z etykietą v1.

Kiali świetnie współpracuje z Istio i zapewnia pudełkowe rozwiązanie do renderowania siatki. Po prostu świetnie.

Wdrożenie na Wyspach Kanaryjskich

Nasz backend ma już dwa wdrożenia K8s, jedno dla wersji 1 i jedno dla wersji 2. Teraz musimy tylko powiedzieć Istio, aby przekazywał określony procent żądań do wersji 2.

Krok 1: 10%

Wszystko, co musimy zrobić, to dostosować wagę VirtualService w 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

Widzimy, że 10% żądań jest przekierowywanych do wersji 2.

Krok 2: 50%

A teraz wystarczy zwiększyć go do 50%:

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

Krok 3: 100%

Teraz wdrożenie Canary można uznać za zakończone i cały ruch jest przekierowywany do wersji 2:

Ręczne testowanie Canary

Załóżmy, że wysyłamy teraz 2% wszystkich żądań do backendu wersji 10. Co jeśli chcemy ręcznie przetestować wersję 2, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami?

Możemy dodać specjalną regułę dopasowywania opartą na nagłówkach HTTP:

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

Teraz używając curl, możemy wymusić żądanie v2, wysyłając nagłówek:

Żądania bez nagłówka będą nadal realizowane według współczynnika 1/10:

Kanarek dla dwóch wersji zależnych

Teraz rozważymy opcję, w której mamy wersję v2 zarówno dla frontendu, jak i backendu. W obu przypadkach określiliśmy, że 10% ruchu powinno trafiać do wersji 2:

Widzimy, że frontend v1 i v2 oba ruchu do przodu w stosunku 1/10 do backendu v1 i v2.

Co by było, gdybyśmy musieli przekazywać ruch tylko z frontendu-v2 do backend-v2, ponieważ nie jest on kompatybilny z v1? Aby to zrobić, ustawimy dla frontendu współczynnik 1/10, który kontroluje, jaki ruch dociera do backendu-v2 za pomocą negocjacji 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

W rezultacie otrzymujemy to, czego potrzebujemy:

Różnice w stosunku do ręcznego podejścia Canary

В część pierwsza Wdrożenie Canary przeprowadziliśmy ręcznie, również przy użyciu dwóch wdrożeń K8s. Tam kontrolowaliśmy stosunek żądań zmieniając liczbę replik. To podejście działa, ale ma poważne wady.

Istio umożliwia określenie proporcji żądań niezależnie od liczby replik. Oznacza to na przykład, że możemy używać HPA (Autoskalerów Horyzontalnych Podów) i nie musimy ich konfigurować zgodnie z aktualnym stanem wdrożenia Canary.

Łączny

Istio działa świetnie, a użycie go razem z Kiali tworzy bardzo potężną kombinację. Następnym na mojej liście zainteresowań jest połączenie Spinnakera z Istio w celu automatyzacji i analityki Canary.

Źródło: www.habr.com