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.
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ć
Zaloguj się do Google Cloud, utwórz projekt i włącz za niego rozliczenia. Zainstaluj narzędzie wiersza poleceń 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ń
brew install kubernetes-helm
Homebrew 2.0 jest teraz dostępny także dla
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
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-gateway
przy 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
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-system
włą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.
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
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
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.
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:
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 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:
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
Flagger jest kompatybilny z dowolnym rozwiązaniem CI/CD dla Kubernetes, a analizę Canary można łatwo rozszerzyć
Obsługiwany program zgłaszający
Jeśli masz sugestie dotyczące ulepszenia narzędzia Flagger, prześlij zgłoszenie lub PR w serwisie GitHub pod adresem
Dzięki
Źródło: www.habr.com