🥇 Torna à i microservizi cù Istio. Parte 2

Nota. transl.: Prima parte 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 istio-maestria.

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 created

U 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 algoritmu round-robin, 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 (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 - 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 main

Vita: Per aghjunghje diversi valori in l'intestazione è pruvà i risultati direttamente in u navigatore, pudete aduprà sta estensione à Chrome (o cun questu per Firefox - circa. trad.).

In generale, DestinationRules hà più capacità in l'area di bilanciamentu di carica - verificate per i dettagli in documentazione ufficiale.

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” deleted

Mirroring: 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 (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) definisce chì sta regula s'applica solu à i casi quandu a strada và versu u serviziu sa-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 created

Avà 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 (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

Nisuna 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 created

Aghjunghjemu 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 (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 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: 500

VirtualServices 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 "8 Cuncepzioni sbagliate nantu à l'informatica distribuita"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 (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

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” deleted

Circuit 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, ccà.)

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, ccà.)

Ometterà i dettagli di implementazione di sti mudelli perchè sò faciuli di truvà documentazione ufficiale, è 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": parte 1 (introduzione à e caratteristiche principali), parte 3 (autentificazione è autorizazione);
«Conduit - maglia di serviziu ligera per Kubernetes";
«Cosa hè una rete di serviziu è perchè ne aghju bisognu [per una applicazione in nuvola cù microservizi]?».

Source: www.habr.com

Torna à i microservizi cù Istio. Parte 2