Bali menyang microservices karo Istio. Bagean 2

Cathetan. nerjemahake.: Bagéan pisanan Seri iki darmabakti kanggo ngenalake kapabilitas Istio lan nuduhake tumindak kasebut. Saiki kita bakal pirembagan bab aspèk luwih Komplek saka konfigurasi lan nggunakake bolong layanan iki, lan ing tartamtu, bab nuntun sacoro apik lan ngatur lalu lintas jaringan.

Kita uga ngelingake yen artikel nggunakake konfigurasi (manifestasi kanggo Kubernetes lan Istio) saka gudang istio-nguwasani.

manajemen lalu lintas

Kanthi Istio, kapabilitas anyar katon ing kluster kanggo nyedhiyakake:

• Nuntun panyuwunan dinamis: rollouts kenari, testing A/B;
• Ngimbangi beban: prasaja lan konsisten, adhedhasar hash;
• Recovery sawise tiba: wektu entek, nyoba maneh, pemutus sirkuit;
• Nyisipake kesalahan: telat, panjaluk sing dibuwang, lsp.

Nalika artikel kasebut diterusake, kemampuan kasebut bakal digambarake nggunakake aplikasi sing dipilih minangka conto lan konsep anyar bakal dienalake ing dalan. Konsep kasebut pisanan bakal DestinationRules (yaiku aturan babagan panampa lalu lintas / panjaluk - kira-kira transl.), kanthi bantuan kita ngaktifake tes A/B.

Pengujian A/B: DestinationRules ing laku

Pengujian A/B digunakake ing kasus sing ana rong versi aplikasi (biasane beda visual) lan kita ora yakin 100% sing bakal nambah pengalaman pangguna. Mulane, kita mbukak loro versi bebarengan lan ngumpulake metrik.

Kanggo masang versi kapindho saka frontend, dibutuhake kanggo nuduhake testing A/B, jalanake printah ing ngisor iki:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

Manifestasi penyebaran kanggo versi ijo beda-beda ing rong panggonan:

1. Gambar kasebut adhedhasar tag sing beda - istio-green,
2. Pods duwe label version: green.

Wiwit loro panyebaran duwe label app: sa-frontend, panjalukan sing dituntun dening layanan virtual sa-external-services kanggo layanan sa-frontend, bakal dialihake menyang kabeh kedadean lan beban bakal disebarake liwat algoritma round-robin, sing bakal nyebabake kahanan ing ngisor iki:

File sing dijaluk ora ditemokake

File-file kasebut ora ditemokake amarga jenenge beda ing versi aplikasi sing beda. Ayo priksa iki:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

Iki tegese index.html, njaluk siji versi file statis, bisa dikirim dening load balancer menyang pods sing duwe versi sing beda, ing ngendi, kanthi alasan sing jelas, file kasebut ora ana. Mula, supaya aplikasi kasebut bisa digunakake, kita kudu nyetel watesan: "versi aplikasi sing padha karo index.html kudu nglayani panjalukan sakteruse".

Kita bakal teka kanthi konsistensi basis hash load balancing (Konsisten Hash Loadbalancing). Ing kasus iki panjalukan saka klien padha dikirim menyang conto backend padha, kanggo properti sing wis ditemtokake digunakake - contone, header HTTP. Dilaksanakake nggunakake DestinationRules.

Aturan Tujuan

Sawise Layanan Virtual ngirim panjalukan menyang layanan sing dikarepake, nggunakake DestinationRules kita bisa nemtokake kabijakan sing bakal ditrapake kanggo lalu lintas sing dituju kanggo conto layanan iki:

Manajemen lalu lintas karo sumber daya Istio

komentar: Dampak sumber daya Istio ing lalu lintas jaringan ditampilake ing kene kanthi cara sing gampang dingerteni. Kanggo tepat, keputusan kanggo ngirim panjalukan kasebut digawe dening Utusan ing Ingress Gateway sing dikonfigurasi ing CRD.

Kanthi Aturan Tujuan, kita bisa ngatur imbangan beban kanggo nggunakake hash sing konsisten lan mesthekake yen conto layanan sing padha nanggapi pangguna sing padha. Konfigurasi ing ngisor iki ngidini sampeyan entuk iki (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - hash bakal digawe adhedhasar isi header HTTP version.

Aplikasi konfigurasi kanthi printah ing ngisor iki:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

Saiki jalanake printah ing ngisor iki lan priksa manawa sampeyan entuk file sing bener nalika sampeyan nemtokake header version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

komentar: Kanggo nambah nilai beda ing header lan nyoba asil langsung ing browser, sampeyan bisa nggunakake extension iki menyang Chrome (utawa karo iki kanggo Firefox - kira-kira. transl.).

Umumé, DestinationRules duwe kemampuan luwih akeh ing babagan keseimbangan beban - priksa rincian ing dokumentasi resmi.

Sadurunge sinau VirtualService luwih lanjut, ayo mbusak "versi ijo" aplikasi lan aturan arah lalu lintas sing cocog kanthi nggunakake printah ing ngisor iki:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

Mirroring: Layanan Virtual ing Praktek

Shading (“pelindung”) utawa Mirroring ("mirroring") digunakake ing kasus ngendi kita arep kanggo nyoba owah-owahan ing produksi tanpa mengaruhi pangguna pungkasan: kanggo nindakake iki, kita duplikat ("pangilon") panjalukan kanggo Kayata liya ngendi owah-owahan sing dikarepake wis digawe, lan katon ing jalaran. Cukup, iki nalika kolega sampeyan milih masalah sing paling kritis lan nggawe panjaluk tarik ing bentuk bongkahan rereget sing ora ana sing bisa mriksa.

Kanggo nguji skenario iki ing tumindak, ayo nggawe conto kapindho SA-Logic kanthi bug (buggy) kanthi nglakokake printah ing ngisor iki:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

Lan saiki ayo mbukak printah kanggo mesthekake yen kabeh kedadean karo app=sa-logic Dheweke uga duwe label kanthi versi sing cocog:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

layanan sa-logic target pods karo label app=sa-logic, supaya kabeh panjalukan bakal disebarake ing antarane kabeh kedadeyan:

... nanging kita pengin panjalukan dikirim menyang v1 instans lan mirrored kanggo v2 instances:

Kita bakal entuk iki liwat VirtualService ing kombinasi karo DestinationRule, ing ngendi aturan bakal nemtokake subset lan rute VirtualService menyang subset tartamtu.

Nemtokake Subset ing Aturan Tujuan

Subset (subset) ditemtokake dening konfigurasi ing ngisor iki (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. Tuan rumah (host) nemtokake manawa aturan iki mung ditrapake kanggo kasus nalika rute menyang layanan kasebut sa-logic;
2. Irah-irahan (name) subset digunakake nalika nuntun menyang subset kedadean;
3. Label (label) nemtokake pasangan nilai kunci sing kudu dicocogake kanggo dadi bagean saka subset.

Aplikasi konfigurasi kanthi printah ing ngisor iki:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

Saiki subset wis ditetepake, kita bisa nerusake lan ngatur VirtualService kanggo aplikasi aturan kanggo panjalukan kanggo sa-logika supaya padha:

1. Dituntun menyang subset v1,
2. Dicerminake menyang subset v2.

Manifesto ing ngisor iki ngidini sampeyan entuk rencana (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

Ora ana panjelasan sing dibutuhake ing kene, mula ayo ndeleng tumindak kasebut:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

Ayo nambahake beban kanthi nelpon printah ing ngisor iki:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

Ayo goleki asil ing Grafana, ing ngendi sampeyan bisa ndeleng manawa versi bug (buggy) nyebabake kegagalan kanggo ~ 60% panjalukan, nanging ora ana kegagalan sing mengaruhi pangguna pungkasan amarga ditanggapi dening layanan sing mlaku.

Respon sukses saka macem-macem versi layanan sa-logika

Ing kene kita pisanan weruh carane VirtualService ditrapake kanggo Utusan layanan kita: nalika sa-web-app ndadekake panjalukan kanggo sa-logic, iku liwat sidecar Utusan, kang - liwat VirtualService - dikonfigurasi kanggo rute panjalukan kanggo v1 subset lan mirror request kanggo v2 subset saka layanan sa-logic.

Aku ngerti, sampeyan bisa uga wis mikir sing Layanan Virtual iku prasaja. Ing bagean sabanjure, kita bakal nggedhekake kanthi ujar manawa dheweke uga apik banget.

Canary rollouts

Canary Deployment minangka proses nggulung versi anyar saka aplikasi menyang sawetara pangguna. Iki digunakake kanggo mesthekake yen ora ana masalah ing rilis lan mung sawise iku, wis yakin karo kualitas (rilis), disebarake menyang pangguna liyane.оpamirsa luwih gedhe.

Kanggo nduduhake rollout kenari, kita bakal terus nggarap subset buggy у sa-logic.

Aja mbuwang wektu ing trifles lan langsung ngirim 20% pangguna menyang versi bug (iki bakal makili rollout kenari kita), lan 80% isih kanggo layanan normal. Kanggo nindakake iki, gunakake VirtualService ing ngisor iki (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 iku bobot (weight), sing nemtokake persentase panjalukan sing bakal diarahake menyang panampa utawa subset saka panampa.

Ayo nganyari konfigurasi VirtualService sadurungé kanggo sa-logic kanthi printah ing ngisor iki:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... lan kita bakal langsung weruh manawa sawetara panjaluk nyebabake gagal:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices ngaktifake rollouts kenari: Ing kasus iki, kita wis mbatesi potensial impact saka masalah kanggo 20% saka basis pangguna. Apik banget! Saiki, ing saben kasus nalika kita ora yakin kode kita (kanthi tembung liyane - tansah ...), kita bisa nggunakake mirroring lan rollouts kenari.

Wektu entek lan nyoba maneh

Nanging kewan omo ora mesthi ana ing kode kasebut. Ing dhaptar saka "8 Misconceptions babagan Computing Distributed"Kaping pisanan yaiku kapercayan sing salah yen" jaringan kasebut dipercaya. Ing kasunyatan, jaringan ora dipercaya, lan mulane kita butuh wektu entek (wektu entek) lan nyoba maneh (nyoba maneh).

Kanggo demonstrasi, kita bakal terus nggunakake versi masalah sing padha sa-logic (buggy), lan kita bakal simulasi unreliability jaringan kanthi gagal acak.

Ayo layanan kita karo kewan omo duwe 1/3 kasempatan njupuk dawa banget kanggo nanggapi, 1/3 kasempatan kanggo mungkasi karo Internal Server Error, lan 1/3 kasempatan kasil bali kaca.

Kanggo nyuda dampak saka masalah kasebut lan nggawe urip luwih apik kanggo pangguna, kita bisa:

1. nambah wektu entek yen layanan njupuk luwih saka 8 detik kanggo nanggapi,
2. coba maneh yen panjalukan gagal.

Kanggo implementasine, kita bakal nggunakake definisi sumber daya ing ngisor iki (sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. Wektu entek kanggo panyuwunan disetel dadi 8 detik;
2. Panyuwunan dicoba maneh 3 kaping;
3. Lan saben nyoba dianggep ora kasil yen wektu respon ngluwihi 3 detik.

Iki minangka optimasi amarga pangguna ora kudu ngenteni luwih saka 8 detik lan kita bakal nggawe telung upaya anyar kanggo entuk tanggapan yen gagal, nambah kemungkinan nanggepi sing sukses.

Aplikasi konfigurasi sing dianyari kanthi printah ing ngisor iki:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

Lan priksa ing grafik Grafana manawa jumlah tanggapan sing sukses wis tambah ing ndhuwur:

Dandan ing statistik respon sing sukses sawise nambah wektu entek lan nyoba maneh

Sadurunge pindhah menyang bagean sabanjure (utawa luwih, menyang bagean sabanjure artikel, amarga ing iki ora bakal ana eksperimen praktis - kira-kira transl.), mbusak sa-logic-buggy lan VirtualService kanthi nglakokake printah ing ngisor iki:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

Circuit Breaker lan Pola Bulkhead

Kita ngomong babagan rong pola penting ing arsitektur microservice sing ngidini sampeyan entuk pemulihan (penyembuhan diri) layanan.

Sirkuit Sirkuit ("pemutus sirkuit") digunakake kanggo mungkasi panjalukan sing teka menyang conto layanan sing dianggep ora sehat lan mulihake nalika panjaluk klien dialihake menyang conto sing sehat saka layanan kasebut (sing nambah persentase respon sing sukses). (Cathetan: Katrangan sing luwih rinci babagan pola bisa ditemokake, contone, kene.)

Kepala Bulk ("pemisahan") ngisolasi kegagalan layanan saka mengaruhi kabeh sistem. Contone, Service B rusak lan layanan liyane (klien Service B) nggawe panjalukan kanggo Service B, nyebabake kanggo exhaust blumbang thread lan ora bisa kanggo layanan panjalukan liyane (sanajan ora saka Service B). (Cathetan: Katrangan sing luwih rinci babagan pola bisa ditemokake, contone, kene.)

Aku bakal ngilangi rincian implementasine saka pola kasebut amarga gampang ditemokake dokumentasi resmi, lan aku uga pengin nuduhake otentikasi lan wewenang, sing bakal dibahas ing bagean sabanjure artikel kasebut.

PS saka penerjemah

Waca uga ing blog kita:

• "Bali menyang microservices karo Istio": bagean 1 (pambuka kanggo fitur utama), bagean 3 (otentikasi lan wewenang);
• «Conduit - bolong layanan entheng kanggo Kubernetes";
• «Apa iku bolong layanan lan kenapa aku butuh siji [kanggo aplikasi maya karo microservices]?".

Source: www.habr.com