Nota. transl.: Questa serie hè stata dedicata à l'introduzione di e capacità d'Istio è à dimustrà in azzione. Avà parlemu di aspetti più cumplessi di a cunfigurazione è l'usu di sta rete di serviziu, è in particulare, di u routing finamente sintonizatu è a gestione di u trafficu di a rete.
Ricurdemu ancu chì l'articulu usa cunfigurazioni (manifesti per Kubernetes è Istio) da u repository .
gestione di u trafficu
Cù Istio, novi capacità appariscenu in u cluster per furnisce:
- Instradamentu dinamicu di e dumande: rollouts canari, test A/B;
- Equilibratu di carica: simplice è coherente, basatu annantu à l'hash;
- Recuperazione dopu a caduta: timeouts, retry, circuit breakers;
- Inserisce i difetti: ritardi, richieste abbandunate, etc.
Cume l'articulu cuntinueghja, sti capacità seranu illustrati usendu l'applicazione scelta cum'è un esempiu è novi cuncetti seranu intrudutti in u caminu. U primu tali cuncettu serà DestinationRules (vale à dì regule nantu à u destinatariu di u trafficu / dumande - circa trad.), cù l'aiutu di quale avemu attivatu a prova A / B.
Test A/B: Reguli di destinazione in pratica
A prova A / B hè aduprata in i casi induve ci sò duie versioni di una applicazione (di solitu sò visualmente sfarente) è ùn simu micca 100% sicuri di quale hà da migliurà l'esperienza d'utilizatore. Dunque, eseguimu e duie versioni simultaneamente è recullemu metriche.
Per implementà a seconda versione di u frontend, necessaria per dimustrà a prova A/B, eseguite u cumandimu seguente:
$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green createdU manifestu di implementazione per a versione verde differisce in dui posti:
- L'imaghjini hè basatu annantu à una diversa tag -
istio-green, - I baccelli anu una etichetta
version: green.
Perchè e duie implementazioni anu una etichetta app: sa-frontend, richieste instradate da u serviziu virtuale sa-external-services per serviziu sa-frontend, serà redirezzione à tutte e so istanze è a carica serà distribuita attraversu , chì porta à a situazione seguente:
I schedari dumandati ùn sò micca stati truvati
Questi schedari ùn sò micca stati truvati perchè sò chjamati diversamente in diverse versioni di l'applicazione. Assicuratevi di questu:
$ 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 Questu significa chì index.html, dumandendu una versione di i schedarii statichi, pò esse mandatu da u balancer di carica à pods chì anu una versione diversa, induve, per ragioni evidenti, tali schedari ùn esistenu micca. Dunque, per chì l'applicazione funziona, avemu bisognu di stabilisce una restrizione: "a listessa versione di l'appiecazione chì serve index.html duveria serve e richieste sussegwente».
Arriveremu cun un bilanciamentu di carica coherente basatu in hash (Balanciamentu di carica Hash Coerente). In stu casu e dumande da u stessu cliente sò mandate à a stessa istanza backend, per quale una pruprietà predefinita hè aduprata - per esempiu, un capu HTTP. Implementatu cù DestinationRules.
Reguli di destinazione
Dopu Serviziu Virtual mandatu una dumanda à u serviziu desideratu, usendu DestinationRules pudemu definisce e pulitiche chì saranu applicate à u trafficu destinatu à l'istanze di stu serviziu:
Gestione di u trafficu cù risorse Istio
Vita: L'impattu di e risorse Istio nantu à u trafficu di a rete hè prisentatu quì in una manera chì hè faciule da capisce. Per esse precisu, a decisione nantu à quale istanza di mandà a dumanda hè fatta da l'Envoy in u Ingress Gateway cunfiguratu in u CRD.
Cù Regoli di Destinazione, pudemu cunfigurà u bilanciamentu di carica per utilizà hash coherenti è assicurà chì a stessa istanza di serviziu risponde à u stessu utilizatore. A cunfigurazione seguente permette di ottene questu ():
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: sa-frontend
spec:
host: sa-frontend
trafficPolicy:
loadBalancer:
consistentHash:
httpHeaderName: version # 1 1 - l'hash serà generatu basatu annantu à u cuntenutu di l'intestazione HTTP version.
Applica a cunfigurazione cù u cumandimu seguitu:
$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created Avà eseguite u cumandimu quì sottu è assicuratevi di ottene i fugliali ghjustu quandu specificate l'intestazione version:
$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep mainVita: Per aghjunghje diversi valori in l'intestazione è pruvà i risultati direttamente in u navigatore, pudete aduprà à Chrome (o per Firefox - circa. trad.).
In generale, DestinationRules hà più capacità in l'area di bilanciamentu di carica - verificate per i dettagli in .
Prima di studià VirtualService più, sguassate a "versione verde" di l'applicazione è a regula di a direzzione di u trafficu currispundente eseguendu i seguenti cumandamenti:
$ 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” deletedMirroring: servizii virtuali in pratica
Ombra ("schermatura") o Mirroring ("spechju") utilizatu in i casi induve vulemu pruvà un cambiamentu in a produzzione senza affettà l'utilizatori finali: per fà questu, duplicemu ("specchiu") dumande à una seconda istanza induve i cambiamenti desiderati sò stati fatti, è fighjate e cunsequenze. Simply put, questu hè quandu u vostru cullega sceglie u prublema più criticu è face una dumanda di pull in forma di una massa tamanta di terra chì nimu pò veramente rivisione.
Per pruvà stu scenariu in azzione, creemu una seconda istanza di SA-Logic cù bugs (buggy) eseguendu u cumandimu seguente:
$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created È avà, eseguisce u cumandamentu per assicurà chì tutti i casi cù app=sa-logic Hanu ancu etichette cù e versioni currispundenti:
$ 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 sirvizziu sa-logic mira pods cù una etichetta app=sa-logic, cusì tutte e dumande seranu distribuite trà tutti i casi:
... ma vulemu chì e dumande sò mandate à istanze v1 è specchiate à istanze v2:
Avemu da ottene questu attraversu VirtualService in cumbinazione cù DestinationRule, induve e regule determinanu i subsets è rotte di VirtualService à un subset specificu.
Definizione di i sottumessi in e regule di destinazione
Subsets (sottogruppi) sò determinate da a cunfigurazione seguente ():
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) definisce chì sta regula s'applica solu à i casi quandu a strada và versu u serviziusa-logic; - tituli (
name) i subsets sò usati quandu u routing à l'istanze di subset; - Etichetta (
label) definisce i coppie di chjave-valore chì l'istanze devenu cuncordà per diventà parti di u subset.
Applica a cunfigurazione cù u cumandimu seguitu:
$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic createdAvà chì i subsets sò definiti, pudemu avanzà è cunfigurà u VirtualService per applicà e regule à e dumande à sa-logic per chì:
- Inviatu à un subset
v1, - Mirrored à un subset
v2.
U manifestu seguente permette di ottene i vostri piani ():
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: v2Nisuna spiegazione necessaria quì, dunque vedimu solu in azione:
$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic createdAghjunghjemu a carica chjamendu u cumandimu seguitu:
$ while true; do curl -v http://$EXTERNAL_IP/sentiment
-H "Content-type: application/json"
-d '{"sentence": "I love yogobella"}';
sleep .8; done Fighjemu i risultati in Grafana, induve pudete vede chì a versione cù bugs (buggy) risultati in fallimentu per ~ 60% di e dumande, ma nimu di sti fallimenti affettanu l'utilizatori finali in quantu sò risposti da un serviziu in esecuzione.
Risposti successi di diverse versioni di u serviziu sa-logic
Quì avemu vistu prima cumu VirtualService hè appiicata à l'Envoys di i nostri servizii: quandu sa-web-app fa una dumanda à sa-logic, passa per u sidecar Envoy, chì - via VirtualService - hè cunfiguratu per indirizzà a dumanda à u subset v1 è speculare a dumanda à u subset v2 di u serviziu. sa-logic.
So, vi putissi digià pinsà chì i servizii Virtual hè sèmplice. In a sezione dopu, espansione nantu à questu dicendu chì sò ancu veramente grandi.
Rollouts canarini
Canary Deployment hè u prucessu di sparghje una nova versione di una applicazione à un picculu numeru di utilizatori. Hè utilizatu per assicurà chì ùn ci sò micca prublemi in a liberazione è solu dopu chì, digià cunfidendu in a so qualità (di liberazione), distribuisce à l'altri utilizatori.оaudience più grande.
Per dimustrà i rollouts canari, continueremu à travaglià cù un subset buggy у sa-logic.
Ùn perdemu u tempu in trifles è mandate immediatamente 20% di l'utilizatori à a versione cù bugs (questu rapprisentarà u nostru rollout canari), è u restu 80% à u serviziu normale. Per fà questu, utilizate u seguente VirtualService ():
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 hè u pesu (weight), chì specifica u percentualità di e dumande chì saranu dirette à un destinatariu o un subset di u destinatariu.
Aghjurnà a cunfigurazione precedente di VirtualService per sa-logic cù u cumandimu seguente:
$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured... è videremu subitu chì alcune dumande portanu à fallimenti:
$ 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: 500VirtualServices permette i rollouts canari: In questu casu, avemu ristrettu l'impattu potenziale di i prublemi à u 20% di a basa d'utilizatori. Meravigliosa! Avà, in ogni casu, quandu ùn simu sicuru di u nostru codice (in altre parolle - sempre ...), pudemu aduprà mirroring è rollouts canari.
Timeouts è riprova
Ma i bug ùn finiscinu micca sempre in u codice. In a lista da ""In u primu locu hè a credenza erronea chì "a reta hè affidabile". In realità a reta ùn affidabile, è per quessa avemu bisognu di timeouts (timeouts) è riprova (riprova).
Per a dimustrazione, continueremu à aduprà a stessa versione di prublema sa-logic (buggy), è simuleremu l'inaffidabilità di a reta cù fallimenti aleatorii.
Chì u nostru serviziu cù bugs hà una chance 1/3 di piglià troppu tempu per risponde, una chance 1/3 di finisce cù un Errore di u Servitore Internu, è una chance 1/3 di rinvià a pagina.
Per mitigà l'impattu di tali prublemi è migliurà a vita di l'utilizatori, pudemu:
- aghjunghje un timeout se u serviziu dura più di 8 seconde per risponde,
- riprova se a dumanda falla.
Per l'implementazione, useremu a seguente definizione di risorse ():
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- U timeout per a dumanda hè stabilitu à 8 seconde;
- E dumande sò ripruvate 3 volte;
- È ogni tentativu hè cunsideratu senza successu se u tempu di risposta supera 3 seconde.
Questa hè una ottimisazione perchè l'utilizatore ùn deve micca aspittà più di 8 seconde è faremu trè novi tentativi per ottene una risposta in casu di fallimenti, aumentendu a chance di una risposta riescita.
Applica a cunfigurazione aghjurnata cù u cumandimu seguitu:
$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configuredÈ verificate in i grafici Grafana chì u numeru di risposti successi hè aumentatu sopra:
Migliuramentu in statistiche di risposta di successu dopu l'aghjunzione di timeouts è riprova
Prima di passà à a sezione dopu (o piuttostu, à a prossima parte di l'articulu, perchè in questu ùn ci sarà più esperimenti pratichi - approx. transl.), sguassà sa-logic-buggy è VirtualService eseguendu i seguenti cumandamenti:
$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deletedCircuit Breaker è mudelli Bulkhead
Parlemu di dui mudelli impurtanti in l'architettura di microserviziu chì permettenu di ottene l'autorecuperazione (auto-guarigione) servizii.
Circuit Breaker ("circuit breaker") utilizatu per finisce e richieste chì venenu à una istanza di un serviziu chì hè cunsideratu insalubre è restaurà mentre e richieste di i clienti sò redirette à istanze sane di quellu serviziu (chì aumenta u percentualità di risposti successi). (Nota: Una descrizzione più dettagliata di u mudellu pò esse truvata, per esempiu, .)
Bulkhead ("partition") isola i fallimenti di serviziu da affettà tuttu u sistema. Per esempiu, u serviziu B hè rottu è un altru serviziu (cliente di u serviziu B) fa una dumanda à u serviziu B, chì pruvucarà à esaurisce u so filu di filu è ùn pò micca serve à altre dumande (ancu s'ellu ùn sò micca da u serviziu B). (Nota: Una descrizzione più dettagliata di u mudellu pò esse truvata, per esempiu, .)
Ometterà i dettagli di implementazione di sti mudelli perchè sò faciuli di truvà , è vogliu ancu veramente vede l'autentificazione è l'autorizazione, chì seranu discututi in a parti dopu di l'articulu.
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- "Torna à i microservizi cù Istio": , ;
- «";
- «».
Source: www.habr.com
