🥇Balik deui ka microservices sareng Istio. Bagian 2

Catetan. narjamahkeun.: Bagian munggaran Séri ieu dikhususkeun pikeun ngenalkeun kamampuan Istio sareng nunjukkeun aranjeunna dina aksi. Ayeuna urang bakal ngobrol ngeunaan aspék leuwih kompleks tina konfigurasi sarta pamakéan bolong jasa ieu, sarta hususna, ngeunaan finely katala routing sarta manajemén lalulintas jaringan.

Kami ogé ngingetan yén tulisan éta ngagunakeun konfigurasi (manifestasi pikeun Kubernetes sareng Istio) tina gudang. istio-ngawasaan.

Manajemén Lalu Lintas

Kalayan Istio, kamampuan anyar muncul dina kluster pikeun nyayogikeun:

Routing pamundut dinamis: rollouts kanaria, nguji A / B;
Balancing beban: basajan tur konsisten, dumasar kana hashes;
Pamulihan sanggeus ragrag: timeouts, retries, circuit breakers;
Inserting kasalahan: reureuh, requests turun, jsb.

Nalika tulisan diteruskeun, kamampuan ieu bakal diilustrasi nganggo aplikasi anu dipilih salaku conto sareng konsép anyar bakal diwanohkeun sapanjang jalan. Konsep sapertos anu munggaran bakal DestinationRules (nyaéta aturan ngeunaan panarima patalimarga/paménta - kira-kira transl.), kalayan bantuan anu urang ngaktipkeun A / B nguji.

A / B nguji: DestinationRules dina prakna

A / B nguji dipaké dina kasus dimana aya dua versi tina hiji aplikasi (biasana aranjeunna visually béda) sarta kami henteu 100% yakin mana nu bakal ngaronjatkeun pangalaman pamaké. Ku alatan éta, urang ngajalankeun duanana versi sakaligus tur ngumpulkeun metrics.

Pikeun nyebarkeun versi kadua frontend, anu diperyogikeun pikeun nunjukkeun tés A / B, jalankeun paréntah di handap ieu:

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

Manifestasi panyebaran pikeun "vérsi héjo" béda dina dua tempat:

Gambar dumasar kana tag anu béda - istio-green,
Pods gaduh labél version: green.

Kusabab duanana deployments boga labél a app: sa-frontend,paménta dialihkeun ku jasa virtual sa-external-services pikeun layanan sa-frontend, bakal dialihkeun ka sadaya instansi sarta beban bakal disebarkeun ngaliwatan algoritma round-robin, anu bakal ngakibatkeun kaayaan di handap ieu:

Berkas anu dipénta henteu kapendak

Berkas-berkas ieu henteu kapendak sabab namina béda dina vérsi aplikasi anu béda. Hayu urang pastikeun ieu:

$ 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

Ieu ngandung harti yén index.html, requesting hiji versi file statik, bisa dikirim ku load balancer ka pods nu boga versi béda, dimana, alesan atra, file sapertos teu aya. Janten, supados aplikasi tiasa dianggo, urang kedah netepkeun larangan: "versi sarua tina aplikasi nu dilayanan index.html kedah ngawula requests saterusna".

Urang bakal ka ditu ku kasaimbangan beban dumasar-hash anu konsisten (Konsisten Hash Loadbalancing)... Dina hal ieu requests ti klien sarua dikirim ka conto backend sarua, pikeun nu sipat geus siap dipaké - contona, hiji lulugu HTTP. Dilaksanakeun nganggo DestinationRules.

Aturan Tujuan

sanggeus VirtualService dikirim pamundut ka layanan nu dipikahoyong, ngagunakeun DestinationRules urang bisa nangtukeun kawijakan anu bakal dilarapkeun ka lalulintas ditakdirkeun pikeun instansi jasa ieu:

Manajemén lalulintas kalawan sumberdaya Istio

nyarios: Dampak sumberdaya Istio on lalulintas jaringan dibere dieu dina cara anu gampang ngartos. Janten tepatna, kaputusan ngeunaan conto anu ngirim pamenta dilakukeun ku Utusan di Ingress Gateway anu dikonpigurasi dina CRD.

Kalayan Aturan Tujuan, urang tiasa ngonpigurasikeun kasaimbangan beban pikeun ngagunakeun hashes anu konsisten sareng mastikeun yén conto jasa anu sami ngaréspon ka pangguna anu sami. Konfigurasi di handap ieu ngamungkinkeun anjeun pikeun ngahontal ieu (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 dihasilkeun dumasar kana eusi lulugu HTTP version.

Larapkeun konfigurasi kalayan paréntah di handap ieu:

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

Ayeuna jalankeun paréntah di handap ieu sareng pastikeun anjeun kéngingkeun file anu leres nalika anjeun netepkeun lulugu version:

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

nyarios: Pikeun nambahkeun nilai béda dina lulugu jeung nguji hasil langsung dina browser, Anjeun bisa make extension ieu kana Chrome (atawa kalawan ieu pikeun Firefox - approx. tarjamah.).

Sacara umum, DestinationRules gaduh langkung seueur kamampuan dina bidang balancing beban - pariksa detil dina dokuméntasi resmi.

Sateuacan ngulik VirtualService langkung jauh, hayu urang ngahapus "versi héjo" tina aplikasi sareng aturan arah lalu lintas anu saluyu ku ngajalankeun paréntah di handap ieu:

$ 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: Jasa Virtual dina Prakték

Bayangan (“ngalindungan”) atawa Mirroring (“ngeunteung”) dipaké dina kasus dimana urang rék nguji parobahan dina produksi tanpa mangaruhan pamaké tungtung: ngalakukeun ieu, urang duplikat ("eunteung") requests ka conto kadua dimana parobahan nu dipikahoyong geus dijieun, sarta kasampak di konsékuansi. Kantun nempatkeun, ieu nalika batur sapagawean anjeun milih masalah anu paling kritis sareng ngadamel pamenta tarik dina bentuk kokotor anu ageung anu teu aya anu tiasa marios deui.

Pikeun nguji skenario ieu dina aksi, hayu urang nyieun conto kadua SA-Logic kalawan bug (buggy) ku ngajalankeun paréntah di handap ieu:

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

Tur ayeuna hayu urang ngajalankeun paréntah pikeun mastikeun yén sakabéh instansi kalawan app=sa-logic Éta ogé gaduh labél sareng versi anu saluyu:

$ 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

palayanan sa-logic nargétkeun pods kalawan labél a app=sa-logic, ku kituna sadaya pamundut bakal disebarkeun ka sadaya instansi:

... tapi kami hoyong pamundut dikirim ka instansi v1 sareng dicerminkeun kana instansi v2:

Kami bakal ngahontal ieu ngaliwatan VirtualService dina kombinasi sareng DestinationRule, dimana aturan bakal nangtukeun subset sareng rute VirtualService ka subset khusus.

Nangtukeun Subset dina Aturan Tujuan

Subset (subkumpulan) ditangtukeun ku konfigurasi di handap ieu (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

Host (host) ngahartikeun yén aturan ieu manglaku ngan pikeun kasus nalika jalur mana arah jasa sa-logic;
Judul (name) subset dipaké nalika routing ka subset instansi;
Label (label) nangtukeun pasangan konci-nilai nu instansi kudu cocog pikeun jadi bagian tina subset.

Larapkeun konfigurasi kalayan paréntah di handap ieu:

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

Ayeuna yén subset diartikeun, urang tiasa ngaléngkah sareng ngonpigurasikeun VirtualService pikeun nerapkeun aturan pikeun pamundut ka sa-logika supados aranjeunna:

Dialihkeun ka sawaréh v1,
Dicerminkeun kana sawaréh v2.

Manifesto di handap ieu ngamungkinkeun anjeun pikeun ngahontal rencana anjeun (sa-logika-subset-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

Henteu aya katerangan anu diperyogikeun di dieu, janten hayu urang tingali dina tindakan:

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

Hayu urang tambahkeun beban ku nelepon paréntah di handap ieu:

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

Hayu urang tingali hasil dina Grafana, dimana anjeun tiasa ningali yén versi ku bug (buggy) nyababkeun kagagalan pikeun ~ 60% tina pamundut, tapi henteu aya kagagalan ieu mangaruhan pangguna akhir sabab direspon ku jasa anu ngajalankeun.

réspon suksés tina versi béda tina layanan sa-logika

Di dieu urang mimiti ningali kumaha VirtualService diterapkeun ka Envoys tina jasa kami: iraha sa-web-app ngajadikeun pamundut ka sa-logic, éta ngaliwatan sidecar Utusan, nu - via VirtualService - geus ngonpigurasi kana jalur pamundut ka sawaréh v1 jeung eunteung pamundut ka sawaréh v2 tina jasa. sa-logic.

Kuring terang, anjeun panginten panginten yén Layanan Virtual saderhana. Dina bagian salajengna, urang bakal ngalegaan éta ku nyarios yén aranjeunna ogé saé pisan.

Kanaria rollouts

Canary Deployment mangrupikeun prosés ngaluncurkeun vérsi énggal tina aplikasi ka sajumlah leutik pangguna. Hal ieu dianggo pikeun mastikeun yén teu aya masalah dina sékrési sareng ngan saatos éta, parantos yakin kana kualitasna (pelepasan), nyebarkeun éta ka pangguna sanés.оpanongton gedé.

Pikeun demonstrate rollouts kanaria, urang bakal neruskeun gawé bareng subset a buggy у sa-logic.

Hayu urang ulah runtah waktu on trifles sarta geura-giru ngirim 20% pamaké pikeun versi kalawan bug (ieu bakal ngagambarkeun rollout kenari urang), sarta sésana 80% ka layanan normal. Jang ngalampahkeun ieu, paké VirtualService di handap ieu (sa-logika-subset-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 nyaéta beurat (weight), nu nangtukeun persentase pamundut nu bakal diarahkeun ka panarima atawa sawaréh ti panarima.

Hayu urang ngamutahirkeun konfigurasi VirtualService saméméhna pikeun sa-logic kalayan paréntah di handap ieu:

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

... sareng urang bakal langsung ningali yén sababaraha pamundut ngakibatkeun 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 ngaktifkeun rollouts kanaria: Dina hal ieu, kami geus ngahususkeun dampak poténsi masalah pikeun 20% tina basa pamaké. Éndah! Ayeuna, dina unggal kasus nalika urang teu yakin kana kode urang (dina kecap sejen - salawasna ...), urang tiasa nganggo mirroring na rollouts kanaria.

Timeouts na retries

Tapi bug henteu salawasna mungkas dina kode. Dina daptar ti "8 Misconceptions ngeunaan komputasi disebarkeun"Di tempat munggaran nyaéta kapercayaan anu salah yén" jaringan tiasa dipercaya. Dina kanyataanana jaringan teu dipercaya, jeung alesan ieu urang kudu timeouts (waktuna) sareng nyobian deui (nyobian deui).

Pikeun demonstrasi kami bakal terus nganggo versi masalah anu sami sa-logic (buggy), sarta kami bakal simulate unreliability tina jaringan jeung gagal acak.

Hayu jasa kami kalawan bug boga 1/3 kasempetan nyandak panjang teuing pikeun ngabales, 1/3 kasempetan tungtung hiji Kasalahan Server internal, sarta 1/3 kasempetan junun balik kaca.

Pikeun ngirangan dampak masalah sapertos kitu sareng ngajantenkeun kahirupan langkung saé pikeun pangguna, urang tiasa:

tambahkeun waktosna upami palayanan peryogi langkung lami ti 8 detik kanggo ngaréspon,
cobian deui upami pamundutna gagal.

Pikeun palaksanaan, urang bakal nganggo definisi sumberdaya di handap ieu (sa-logika-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

Waktu béak pikeun pamundut disetel ka 8 detik;
Requests dicoba deui 3 kali;
Sarta unggal usaha dianggap gagal lamun waktu respon ngaleuwihan 3 detik.

Ieu mangrupikeun optimasi sabab pangguna henteu kedah ngantosan langkung ti 8 detik sareng kami bakal ngadamel tilu usaha anyar pikeun kéngingkeun réspon upami gagal, ningkatkeun kasempetan réspon anu suksés.

Larapkeun konfigurasi anu diropéa nganggo paréntah di handap ieu:

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

Sareng parios dina grafik Grafana yén jumlah réspon anu suksés parantos ningkat di luhur:

Perbaikan dina statistik respon suksés sanggeus nambahkeun timeouts na retries

Sateuacan ngaléngkah ka bagian salajengna (atawa rada, ka bagian saterusna artikel, sabab dina ieu moal aya deui percobaan praktis - approx. transl.), mupus sa-logic-buggy sareng VirtualService ku ngajalankeun paréntah di handap ieu:

$ 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 jeung Bulkhead Pola

Urang ngobrol ngeunaan dua pola penting dina arsitektur microservice nu ngidinan Anjeun pikeun ngahontal recovery diri (nyageurkeun diri) jasa.

circuit breaker ("pemutus sirkuit") dipaké pikeun nungtungan requests datang ka hiji conto ladenan nu dianggap teu damang tur malikkeun eta bari requests klien dialihkeun ka instansi cageur tina jasa éta (anu ngaronjatkeun persentase réspon suksés). (Catetan: Katerangan anu langkung rinci ngeunaan pola tiasa dipendakan, contona, di dieu.)

Bulkhead ("partisi") ngasingkeun gagal jasa tina mangaruhan sakabéh sistem. Salaku conto, Service B rusak sareng jasa anu sanés (klien Service B) naroskeun ka Service B, nyababkeun éta béakna kolam renang benang sareng teu tiasa ngalayanan pamundut anu sanés (sanaos sanés ti Service B). (Catetan: Katerangan anu langkung rinci ngeunaan pola tiasa dipendakan, contona, di dieu.)

Kuring bakal ngaleungitkeun rinci palaksanaan pola ieu sabab gampang pikeun manggihan di dokuméntasi resmi, Sareng kuring ogé hoyong nunjukkeun kaaslianana sareng otorisasina, anu bakal dibahas dina bagian salajengna tulisan.

PS ti penerjemah

Baca ogé dina blog urang:

"Balik deui ka microservices sareng Istio": bagian 1 (perkenalan kana fitur utama), bagian 3 (auténtikasi sareng otorisasi);
«Conduit - bolong jasa ringan pikeun Kubernetes";
«Naon ari jasa bolong sareng naha kuring peryogi éta [pikeun aplikasi awan sareng microservices]?".

sumber: www.habr.com

Deui ka microservices kalawan Istio. Bagian 2