Automatyczne wdrożenia Canary za pomocą Flagger i Istio

Automatyczne wdrożenia Canary za pomocą Flagger i Istio

CD jest uznawany za praktykę dotyczącą oprogramowania dla przedsiębiorstw i stanowi naturalną ewolucję ustalonych zasad CI. Jednak CD jest nadal dość rzadkie, być może ze względu na złożoność zarządzania i obawę przed nieudanymi wdrożeniami wpływającymi na dostępność systemu.

Zgłaszający to operator Kubernetes typu open source, którego celem jest wyeliminowanie mylących relacji. Automatyzuje promowanie wdrożeń Canary przy użyciu przesunięć ruchu Istio i metryk Prometheus w celu analizowania zachowania aplikacji podczas zarządzanego wdrażania.

Poniżej znajduje się przewodnik krok po kroku dotyczący konfigurowania i używania narzędzia Flagger w Google Kubernetes Engine (GKE).

Konfigurowanie klastra Kubernetes

Zaczynasz od utworzenia klastra GKE z dodatkiem Istio (jeśli nie masz konta GCP, możesz się zarejestrować tutaj - aby otrzymać darmowe kredyty).

Zaloguj się do Google Cloud, utwórz projekt i włącz za niego rozliczenia. Zainstaluj narzędzie wiersza poleceń gcloud i skonfiguruj swój projekt za pomocą gcloud init.

Ustaw domyślny projekt, obszar obliczeniowy i strefę (zamień PROJECT_ID dla Twojego projektu):

gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

Włącz usługę GKE i utwórz klaster z dodatkami HPA i Istio:

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

Powyższe polecenie utworzy domyślną pulę węzłów składającą się z dwóch maszyn wirtualnych n1-standard-2 (vCPU: 2, RAM 7,5 GB, dysk: 30 GB). W idealnym przypadku komponenty Istio powinny być odizolowane od obciążeń, ale nie ma łatwego sposobu uruchamiania zasobników Istio w dedykowanej puli węzłów. Manifesty Istio są uznawane za przeznaczone tylko do odczytu, a GKE cofa wszelkie zmiany, takie jak powiązanie z węzłem lub odłączenie od poda.

Skonfiguruj poświadczenia dla kubectl:

gcloud container clusters get-credentials istio

Utwórz powiązanie roli administratora klastra:

kubectl create clusterrolebinding "cluster-admin-$(whoami)" 
--clusterrole=cluster-admin 
--user="$(gcloud config get-value core/account)"

Zainstaluj narzędzie wiersza poleceń Ster:

brew install kubernetes-helm

Homebrew 2.0 jest teraz dostępny także dla Linux.

Utwórz konto usługi i powiązanie roli klastra dla Tillera:

kubectl -n kube-system create sa tiller && 
kubectl create clusterrolebinding tiller-cluster-rule 
--clusterrole=cluster-admin 
--serviceaccount=kube-system:tiller

Rozwiń Tiller w przestrzeni nazw kube-system:

helm init --service-account tiller

Powinieneś rozważyć użycie protokołu SSL między Helmem a Tillerem. Aby uzyskać więcej informacji na temat ochrony instalacji Helm, zobacz docs.helm.sh

Potwierdź ustawienia:

kubectl -n istio-system get svc

Po kilku sekundach GCP powinien przypisać usłudze zewnętrzny adres IP istio-ingressgateway.

Konfigurowanie bramy wejściowej Istio

Utwórz statyczny adres IP z nazwą istio-gatewayprzy użyciu adresu IP bramy Istio:

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

Teraz potrzebujesz domeny internetowej i dostępu do swojego rejestratora DNS. Dodaj dwa rekordy A (zamień example.com do Twojej domeny):

istio.example.com   A ${GATEWAY_IP}
*.istio.example.com A ${GATEWAY_IP}

Sprawdź, czy działa symbol wieloznaczny DNS:

watch host test.istio.example.com

Utwórz ogólną bramę Istio, aby świadczyć usługi poza siatką usług za pośrednictwem protokołu HTTP:

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:
        - "*"

Zapisz powyższy zasób jako public-gateway.yaml, a następnie zastosuj go:

kubectl apply -f ./public-gateway.yaml

Żaden system produkcyjny nie powinien świadczyć usług w Internecie bez protokołu SSL. Aby zabezpieczyć bramę przychodzącą Istio za pomocą menedżera certyfikatów, CloudDNS i Let's Encrypt, przeczytaj dokumentacja Osoba zgłaszająca G.K.E.

Instalacja flagera

Dodatek GKE Istio nie zawiera instancji Prometheus, która czyści usługę telemetryczną Istio. Ponieważ Flagger używa metryk Istio HTTP do przeprowadzania analizy kanarkowej, należy wdrożyć następującą konfigurację Prometheusa, podobną do tej dostarczanej z oficjalnym schematem Istio Helm.

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/gke/istio-prometheus.yaml

Dodaj repozytorium Flagger Helm:

helm repo add flagger [https://flagger.app](https://flagger.app/)

Rozwiń Flagger do przestrzeni nazw istio-systemwłączając powiadomienia Slack:

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

Możesz zainstalować Flaggera w dowolnej przestrzeni nazw, o ile może on komunikować się z usługą Istio Prometheus na porcie 9090.

Flagger ma pulpit Grafana do analizy kanarek. Zainstaluj Grafanę w przestrzeni nazw 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

Udostępnij Grafanę przez otwartą bramę, tworząc usługę wirtualną (zamień example.com do Twojej domeny):

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

Zapisz powyższy zasób jako grafana-virtual-service.yaml, a następnie zastosuj go:

kubectl apply -f ./grafana-virtual-service.yaml

Kiedy zamierzam http://grafana.istio.example.com Twoja przeglądarka powinna przekierować Cię na stronę logowania Grafana.

Wdrażanie aplikacji internetowych za pomocą Flaggera

Flagger wdraża Kubernetes i, jeśli to konieczne, poziome autoskalowanie (HPA), następnie tworzy serię obiektów (wdrożenia Kubernetes, usługi ClusterIP i usługi wirtualne Istio). Obiekty te udostępniają aplikację siatce usług i zarządzają analizą i promocją kanarek.

Automatyczne wdrożenia Canary za pomocą Flagger i Istio

Utwórz testową przestrzeń nazw z włączoną implementacją Istio Sidecar:

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml

Utwórz narzędzie do wdrożenia i automatycznego skalowania poziomego dla kapsuły:

kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml

Wdróż usługę testu obciążenia, aby wygenerować ruch podczas analizy Canary:

helm upgrade -i flagger-loadtester flagger/loadtester 
--namepace=test

Utwórz niestandardowy zasób kanarkowy (zamień example.com do Twojej domeny):

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/"

Zapisz powyższy zasób jako podinfo-canary.yaml, a następnie zastosuj go:

kubectl apply -f ./podinfo-canary.yaml

Jeśli powyższa analiza zakończy się pomyślnie, będzie trwała pięć minut, sprawdzając metryki HTTP co pół minuty. Minimalny czas wymagany do przetestowania i promowania wdrożenia Canary można określić, korzystając z następującego wzoru: interval * (maxWeight / stepWeight). Pola Canary CRD są udokumentowane tutaj.

Po kilku sekundach Flagger utworzy obiekty typu kanarek:

# 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

Otwórz przeglądarkę i przejdź do app.istio.example.com, powinieneś zobaczyć numer wersji aplikacje demonstracyjne.

Automatyczna analiza i promocja kanarków

Flagger implementuje pętlę kontroli, która stopniowo przenosi ruch do Canary, mierząc jednocześnie kluczowe wskaźniki wydajności, takie jak współczynnik powodzenia żądań HTTP, średni czas trwania żądania i stan podów. Na podstawie analizy KPI kanarek zostaje awansowany lub skreślony, a wyniki analizy publikowane są w Slacku.

Automatyczne wdrożenia Canary za pomocą Flagger i Istio

Wdrożenie Canary jest wyzwalane, gdy zmienia się jeden z następujących obiektów:

  • Wdróż PodSpec (obraz kontenera, polecenie, porty, środowisko itp.)
  • ConfigMaps są montowane jako woluminy lub konwertowane na zmienne środowiskowe
  • Wpisy tajne są montowane jako woluminy lub konwertowane na zmienne środowiskowe

Uruchom wdrożenie Canary podczas aktualizacji obrazu kontenera:

kubectl -n test set image deployment/podinfo 
podinfod=quay.io/stefanprodan/podinfo:1.4.1

Flagger wykrywa zmianę wersji wdrożenia i zaczyna ją analizować:

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

Podczas analizy wyniki kanarków można monitorować za pomocą programu Grafana:

Automatyczne wdrożenia Canary za pomocą Flagger i Istio

Uwaga: jeśli podczas analizy Canary zostaną zastosowane nowe zmiany we wdrożeniu, Flagger ponownie rozpocznie fazę analizy.

Zrób listę wszystkich kanarków w twoim skupisku:

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

Jeśli włączyłeś powiadomienia Slack, otrzymasz następujące wiadomości:

Automatyczne wdrożenia Canary za pomocą Flagger i Istio

Automatyczne wycofanie

Podczas analizy Canary możesz wygenerować syntetyczne błędy HTTP 500 i duże opóźnienia odpowiedzi, aby sprawdzić, czy Flagger zatrzyma wdrożenie.

Utwórz kapsułę testową i wykonaj w niej następujące czynności:

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

Generowanie błędów HTTP 500:

watch curl http://podinfo-canary:9898/status/500

Generowanie opóźnienia:

watch curl http://podinfo-canary:9898/delay/1

Gdy liczba nieudanych kontroli osiągnie próg, ruch jest kierowany z powrotem do kanału podstawowego, funkcja Canary jest skalowana do zera, a wdrożenie jest oznaczane jako zakończone niepowodzeniem.

Błędy Canary i skoki opóźnień są rejestrowane jako zdarzenia Kubernetes i rejestrowane przez Flaggera w formacie JSON:

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

Jeśli masz włączone powiadomienia na Slacku, otrzymasz wiadomość, gdy przekroczony zostanie termin uzupełnienia lub osiągnięcia maksymalnej liczby nieudanych recenzji w analizie:

Automatyczne wdrożenia Canary za pomocą Flagger i Istio

Na zakończenie

Uruchomienie siatki usług, takiej jak Istio, na Kubernetesie zapewni automatyczne metryki, dzienniki i dzienniki, ale wdrażanie obciążeń nadal zależy od narzędzi zewnętrznych. Flagger ma na celu to zmienić, dodając możliwości Istio dostawa progresywna.

Flagger jest kompatybilny z dowolnym rozwiązaniem CI/CD dla Kubernetes, a analizę Canary można łatwo rozszerzyć webhooki w celu przeprowadzenia testów integracji/akceptacji systemu, testów obciążeniowych lub innych testów niestandardowych. Ponieważ Flagger ma charakter deklaratywny i odpowiada na zdarzenia Kubernetes, może być używany w potokach GitOps wraz z Strumień splotu lub Jenkins X. Jeśli używasz JenkinsX, możesz zainstalować Flaggera z dodatkami jx.

Obsługiwany program zgłaszający Splot i zapewnia wdrożenia na Wyspach Kanaryjskich Splot chmurę. Projekt jest testowany na GKE, EKS i bare metal z kubeadm.

Jeśli masz sugestie dotyczące ulepszenia narzędzia Flagger, prześlij zgłoszenie lub PR w serwisie GitHub pod adresem stefanprodan/flager. Wpłaty są więcej niż mile widziane!

Dzięki Ray Tsang.

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

Dodaj komentarz