Ang CD ay kinikilala bilang isang enterprise software practice at resulta ng natural na ebolusyon ng mga itinatag na prinsipyo ng CI. Gayunpaman, ang CD ay bihira pa rin, marahil dahil sa pagiging kumplikado ng pamamahala at ang takot sa mga nabigong deployment na nakakaapekto sa availability ng system.
ay isang open source Kubernetes operator na naglalayong alisin ang nakakalito na mga relasyon. I-automate nito ang pag-promote ng mga canary deployment gamit ang Istio traffic offset at Prometheus metrics para suriin ang gawi ng application sa panahon ng pinamamahalaang rollout.
Nasa ibaba ang hakbang-hakbang na gabay sa pag-set up at paggamit ng Flagger sa Google Kubernetes Engine (GKE).
Pagse-set up ng Kubernetes cluster
Magsisimula ka sa paggawa ng cluster ng GKE gamit ang Istio add-on (kung wala kang GCP account, maaari kang mag-sign up - upang makakuha ng mga libreng kredito).
Mag-sign in sa Google Cloud, gumawa ng proyekto, at paganahin ang pagsingil para dito. I-install ang command line utility at i-set up ang iyong proyekto gamit ang gcloud init.
Itakda ang default na proyekto, compute area, at zone (palitan PROJECT_ID para sa iyong proyekto):
gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-aI-enable ang serbisyo ng GKE at gumawa ng cluster na may mga add-on ng HPA at 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_PERMISSIVEAng utos sa itaas ay lilikha ng default na node pool kasama ang dalawang VM n1-standard-2 (vCPU: 2, RAM 7,5 GB, disk: 30 GB). Sa isip, dapat mong ihiwalay ang mga bahagi ng Istio mula sa iyong mga workload, ngunit walang madaling paraan upang patakbuhin ang Istio Pods sa isang nakalaang pool ng mga node. Itinuturing na read-only ang mga manifest ng Istio at ia-undo ng GKE ang anumang mga pagbabago, gaya ng pag-link sa isang node o pagtanggal sa isang pod.
Mag-set up ng mga kredensyal para sa kubectl:
gcloud container clusters get-credentials istioGumawa ng isang cluster administrator role binding:
kubectl create clusterrolebinding "cluster-admin-$(whoami)"
--clusterrole=cluster-admin
--user="$(gcloud config get-value core/account)"I-install ang command line tool :
brew install kubernetes-helmAvailable na rin ang Homebrew 2.0 para sa .
Gumawa ng service account at cluster role binding para sa Tiller:
kubectl -n kube-system create sa tiller &&
kubectl create clusterrolebinding tiller-cluster-rule
--clusterrole=cluster-admin
--serviceaccount=kube-system:tillerPalawakin ang Tiller sa namespace kube-system:
helm init --service-account tillerDapat mong isaalang-alang ang paggamit ng SSL sa pagitan ng Helm at Tiller. Para sa higit pang impormasyon tungkol sa pagprotekta sa iyong pag-install ng Helm, tingnan
Kumpirmahin ang mga setting:
kubectl -n istio-system get svcPagkatapos ng ilang segundo, dapat magtalaga ang GCP ng isang panlabas na IP address para sa serbisyo istio-ingressgateway.
Kino-configure ang Istio Ingress Gateway
Gumawa ng static na IP address na may pangalan istio-gatewaygamit ang IP address ng Istio gateway:
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-central1Ngayon ay kailangan mo ng internet domain at access sa iyong DNS registrar. Magdagdag ng dalawang A record (palitan example.com sa iyong domain):
istio.example.com A ${GATEWAY_IP}
*.istio.example.com A ${GATEWAY_IP}I-verify na gumagana ang wildcard ng DNS:
watch host test.istio.example.comGumawa ng generic na gateway ng Istio para magbigay ng mga serbisyo sa labas ng service mesh sa 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:
- "*"I-save ang mapagkukunan sa itaas bilang public-gateway.yaml at pagkatapos ay ilapat ito:
kubectl apply -f ./public-gateway.yamlWalang sistema ng produksyon ang dapat magbigay ng mga serbisyo sa Internet nang walang SSL. Para ma-secure ang Istio ingress gateway gamit ang cert-manager, CloudDNS at Let's Encrypt, pakibasa Flagger G.K.E.
Pag-install ng Flagger
Ang GKE Istio add-on ay hindi kasama ang isang Prometheus instance na naglilinis sa serbisyo ng telemetry ng Istio. Dahil gumagamit ang Flagger ng mga sukatan ng Istio HTTP upang magsagawa ng pagsusuri sa canary, kailangan mong i-deploy ang sumusunod na configuration ng Prometheus, katulad ng isa na kasama ng opisyal na schema ng Istio Helm.
REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/gke/istio-prometheus.yamlIdagdag ang Flagger Helm repository:
helm repo add flagger [https://flagger.app](https://flagger.app/)Palawakin ang Flagger sa namespace istio-systemsa pamamagitan ng pagpapagana ng mga notification ng 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=flaggerMaaari mong i-install ang Flagger sa anumang namespace hangga't maaari itong makipag-ugnayan sa serbisyo ng Istio Prometheus sa port 9090.
Ang Flagger ay mayroong Grafana dashboard para sa canary analysis. I-install ang Grafana sa namespace 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-meIlantad ang Grafana sa pamamagitan ng isang bukas na gateway sa pamamagitan ng paglikha ng isang virtual na serbisyo (palitan example.com sa iyong domain):
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-grafanaI-save ang mapagkukunan sa itaas bilang grafana-virtual-service.yaml at pagkatapos ay ilapat ito:
kubectl apply -f ./grafana-virtual-service.yamlKapag lumipat sa http://grafana.istio.example.com sa browser, dapat kang idirekta sa pahina ng pag-login ng Grafana.
Pag-deploy ng mga web application gamit ang Flagger
Nagde-deploy ang Flagger ng mga Kubernetes at awtomatikong nag-scale out (HPA), pagkatapos ay gumagawa ng isang serye ng mga bagay (mga pag-deploy ng Kubernetes, mga serbisyo ng ClusterIP, at mga virtual na serbisyo ng Istio). Inilalantad ng mga bagay na ito ang aplikasyon sa mesh ng serbisyo at kontrolin ang pagsusuri at pag-unlad ng canary.
Gumawa ng test namespace na may naka-enable na Istio Sidecar injection:
REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/namespaces/test.yamlGumawa ng deployment at pod automatic scale-out tool:
kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
kubectl apply -f ${REPO}/artifacts/canaries/hpa.yamlMag-deploy ng test load service para makabuo ng trapiko sa panahon ng canary analysis:
helm upgrade -i flagger-loadtester flagger/loadtester
--namepace=testGumawa ng custom na mapagkukunan ng canary (palitan example.com sa iyong domain):
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/"I-save ang mapagkukunan sa itaas bilang podinfo-canary.yaml at pagkatapos ay ilapat ito:
kubectl apply -f ./podinfo-canary.yamlAng pagsusuri sa itaas, kung matagumpay, ay tatakbo nang limang minuto, sinusuri ang mga sukatan ng HTTP bawat kalahating minuto. Maaari mong tukuyin ang minimum na oras na kinakailangan upang mapatunayan at i-promote ang isang canary deployment gamit ang sumusunod na formula: interval * (maxWeight / stepWeight). Ang mga patlang ng Canary CRD ay dokumentado .
Pagkatapos ng ilang segundo, gagawa ang Flagger ng mga canary object:
# 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/podinfoMagbukas ng browser at pumunta sa app.istio.example.com, dapat mong makita ang numero ng bersyon .
Awtomatikong pagsusuri at promosyon ng canary
Nagpapatupad ang Flagger ng control loop na unti-unting naglilipat ng trapiko sa canary habang sinusukat ang mga pangunahing sukatan ng performance gaya ng rate ng tagumpay ng kahilingan sa HTTP, average na tagal ng kahilingan, at kalusugan ng pod. Batay sa pagsusuri ng KPI, ang kanaryo ay na-promote o naantala, at ang mga resulta ng pagsusuri ay nai-publish sa Slack.
Nati-trigger ang pag-deploy ng Canary kapag nagbago ang isa sa mga sumusunod na object:
- I-deploy ang PodSpec (larawan ng container, command, port, env, atbp.)
- Ang ConfigMaps ay naka-mount bilang mga volume o nakamapa sa mga variable ng kapaligiran
- Ang mga lihim ay naka-mount bilang mga volume o na-convert sa mga variable ng kapaligiran
Patakbuhin ang pag-deploy ng canary kapag nag-a-update ng imahe ng lalagyan:
kubectl -n test set image deployment/podinfo
podinfod=quay.io/stefanprodan/podinfo:1.4.1Nakita ng Flagger na nagbago ang bersyon ng deployment at sinimulan itong i-parse:
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.testSa panahon ng pagsusuri, maaaring masubaybayan ang mga resulta ng canary gamit ang Grafana:
Pakitandaan na kung ang mga bagong pagbabago ay ilalapat sa isang deployment sa panahon ng pagsusuri ng canary, ire-restart ng Flagger ang yugto ng pagsusuri.
Gumawa ng listahan ng lahat ng canary sa iyong cluster:
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:07ZKung pinagana mo ang mga notification ng Slack, matatanggap mo ang mga sumusunod na mensahe:
Awtomatikong rollback
Sa panahon ng pagsusuri sa canary, maaari kang bumuo ng mga synthetic na HTTP 500 na error at mataas na latency ng pagtugon upang makita kung pipigilan ng Flagger ang deployment.
Gumawa ng test pod at gawin ang sumusunod dito:
kubectl -n test run tester
--image=quay.io/stefanprodan/podinfo:1.2.1
-- ./podinfo --port=9898
kubectl -n test exec -it tester-xx-xx shPagbuo ng HTTP 500 na mga error:
watch curl http://podinfo-canary:9898/status/500Pagbuo ng pagkaantala:
watch curl http://podinfo-canary:9898/delay/1Kapag ang bilang ng mga nabigong pagsusuri ay umabot sa threshold, ang trapiko ay iruruta pabalik sa pangunahing channel, ang canary ay ini-scale sa zero, at ang deployment ay minarkahan bilang nabigo.
Ang mga canary error at latency spike ay naka-log bilang mga kaganapan sa Kubernetes at ni-log ng Flagger sa JSON na format:
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.testKung pinagana mo ang mga notification ng Slack, makakatanggap ka ng mensahe kapag nalampasan na ang deadline o naabot na ang maximum na bilang ng mga nabigong pagsusuri sa pagsusuri:
Sa pagtatapos
Ang pagpapatakbo ng service mesh tulad ng Istio bilang karagdagan sa Kubernetes ay magbibigay ng mga awtomatikong sukatan, log, at protocol, ngunit ang deployment ng workload ay nakadepende pa rin sa mga external na tool. Nilalayon ng Flagger na baguhin ito sa pamamagitan ng pagdaragdag ng mga kakayahan ng Istio .
Tugma ang Flagger sa anumang solusyon ng Kubernetes CI/CD, at madaling mapalawak ang pagsusuri sa canary upang magsagawa ng system integration/acceptance test, load test, o anumang iba pang custom na pagsusuri. Dahil ang Flagger ay deklaratibo at tumutugon sa mga kaganapan sa Kubernetes, maaari itong magamit sa mga pipeline ng GitOps kasama ng o . Kung gumagamit ka ng JenkinsX maaari mong i-install ang Flagger gamit ang mga jx addon.
Sinusuportahan ang flagger at nagbibigay ng mga canary deployment sa . Sinusubukan ang proyekto sa GKE, EKS, at bare metal gamit ang kubeadm.
Kung mayroon kang mga mungkahi upang mapabuti ang Flagger, mangyaring magsumite ng isyu o PR sa GitHub sa . Ang mga kontribusyon ay higit sa malugod na tinatanggap!
salamat .
Pinagmulan: www.habr.com