Zréck op Mikroservicer mat Istio. Deel 2

Note. iwwersat.: Éischten Deel Dës Serie war gewidmet fir d'Istio Fäegkeeten anzeféieren an se an Aktioun ze demonstréieren. Elo schwätze mer iwwer méi komplex Aspekter vun der Konfiguratioun an der Notzung vun dësem Service Mesh, a besonnesch iwwer fein gestëmmte Routing an Netzwierkverkéiersmanagement.

Mir erënneren Iech och drun datt den Artikel Konfiguratiounen benotzt (Manifester fir Kubernetes an Istio) aus dem Repository istio-Maîtrise.

Verkéier Management

Mat Istio erschéngen nei Fäegkeeten am Cluster fir ze bidden:

• Dynamesch Ufro Routing: Kanaresch Rollouts, A / B Testen;
• Laascht Equiliber: einfach a konsequent, baséiert op hashes;
• Erhuelung no Falen: timeouts, reverséiert, Circuit breakers;
• Feeler asetzen: Verspéidungen, erofgefall Ufroen, etc.

Wéi den Artikel weider geet, ginn dës Fäegkeeten illustréiert mat der gewielter Applikatioun als Beispill an nei Konzepter ginn laanscht de Wee agefouert. Déi éischt esou Konzept wäert sinn DestinationRules (dh Regelen iwwer den Empfänger vum Verkéier/Ufroen - ca. Iwwersetzung), mat der Hëllef vun deem mir A / B Testen aktivéieren.

A / B Testen: Destinatiounsregelen an der Praxis

A / B Testen gëtt benotzt a Fäll wou et zwou Versioune vun enger Applikatioun sinn (normalerweis si se visuell anescht) a mir sinn net 100% sécher wéi eng d'Benotzererfarung verbessert. Dofir lafe mir béid Versioune gläichzäiteg a sammelen Metriken.

Fir déi zweet Versioun vum Frontend z'installéieren, erfuerderlech fir A / B Testen ze demonstréieren, fuert de folgende Kommando:

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

Den Deployment Manifest fir déi gréng Versioun ënnerscheet sech op zwou Plazen:

1. D'Bild baséiert op engem aneren Tag - istio-green,
2. Pods hunn e Label version: green.

Well béid Deployementer e Label hunn app: sa-frontend, Ufroen duerch virtuelle Service geréckelt sa-external-services fir Service sa-frontend, gëtt op all seng Instanzen ëmgeleet an d'Laascht gëtt duerch verdeelt Ronn-Robin Algorithmus, wat zu der folgender Situatioun féiert:

Déi ugefrote Dateie goufen net fonnt

Dës Dateie goufen net fonnt well se a verschiddene Versioune vun der Applikatioun anescht benannt ginn. Loosst eis dëst sécher stellen:

$ 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

Et heescht dat index.html, fir eng Versioun vu statesche Dateien ze froen, kënne vum Lastbalancer un Pods geschéckt ginn, déi eng aner Versioun hunn, wou, aus offensichtleche Grënn, esou Dateien net existéieren. Dofir, fir datt d'Applikatioun funktionnéiert, musse mir eng Restriktioun setzen: "déi selwecht Versioun vun der Applikatioun déi index.html zerwéiert soll spéider Ufroen déngen".

Mir kommen do mat konsequent hash-baséierter Laaschtbalancéierung (Konsistent Hash Loadbalancing)... An dësem Fall Ufroe vum selwechte Client ginn op déiselwecht Backend Instanz geschéckt, fir déi eng virdefinéiert Eegeschafte benotzt gëtt - zum Beispill en HTTP-Header. Ëmgesat mat DestinationRules.

Destinatioun Regelen

Nodeem VirtualService eng Ufro un de gewënschten Service geschéckt, mat DestinationRules kënne mir Politiken definéieren, déi op Traffic applizéiert ginn, dee fir Instanzen vun dësem Service bestëmmt ass:

Verkéier Gestioun mat Istio Ressourcen

Remarque: Den Impakt vun Istio Ressourcen op Netzverkéier gëtt hei op eng Manéier presentéiert déi einfach ze verstoen ass. Fir präzis ze sinn, ass d'Entscheedung iwwer wéi eng Instanz d'Ufro ze schécken ass vum Envoy an der Ingress Gateway konfiguréiert an der CRD gemaach.

Mat Destinatiounsregelen kënne mir Laaschtbalancéierung konfiguréieren fir konsequent Hashes ze benotzen an dofir suergen datt déiselwecht Serviceinstanz op dee selwechte Benotzer reagéiert. Déi folgend Konfiguratioun erlaabt Iech dëst z'erreechen (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 gëtt generéiert baséiert op den Inhalt vum HTTP Header version.

Fëllt d'Konfiguratioun mat dem folgenden Kommando un:

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

Fuert elo de Kommando hei ënnen a gitt sécher datt Dir déi richteg Dateie kritt wann Dir den Header spezifizéiert version:

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

Remarque: Fir verschidde Wäerter am Header ze addéieren an d'Resultater direkt am Browser ze testen, kënnt Dir benotzen dëser Extensioun zu Chrome (oder dëst fir Firefox - ca. Iwwersetzung).

Allgemeng huet DestinationRules méi Fäegkeeten am Beräich vun der Belaaschtung - kuckt no Detailer an offiziell Dokumentatioun.

Ier Dir VirtualService weider studéiert, loosst eis déi "gréng Versioun" vun der Applikatioun an déi entspriechend Verkéiersrichtungsregel läschen andeems Dir déi folgend Kommandoen ausféiert:

$ 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: Virtuell Servicer an der Praxis

Schatten ("Shielding") oder Spigelen ("Spigelen") benotzt a Fäll wou mir eng Verännerung vun der Produktioun testen wëllen ouni d'Endbenotzer ze beaflossen: fir dëst ze maachen, duplizéiere mir ("Spigel") Ufroen op eng zweet Instanz wou déi gewënscht Ännerunge gemaach goufen, a kucken d'Konsequenzen. Einfach gesot, dëst ass wann Äre Kolleg déi kriteschst Thema wielt an eng Pull-Ufro mécht a Form vun esou engem riesegen Dreckstipp datt keen et wierklech iwwerpréift.

Fir dëst Szenario an Aktioun ze testen, loosst eis eng zweet Instanz vu SA-Logic mat Bugs erstellen (buggy) andeems Dir de folgende Kommando ausféiert:

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

An elo loosse mer de Kommando lafen fir sécherzestellen datt all Instanzen mat app=sa-logic Si hunn och Etiketten mat den entspriechende Versiounen:

$ 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

Service sa-logic zielt Pods mat engem Label app=sa-logic, sou datt all Ufroe ënnert all Instanzen verdeelt ginn:

... awer mir wëllen datt Ufroe op v1 Instanzen geschéckt ginn an op v2 Instanzen gespigelt ginn:

Mir wäerten dëst duerch VirtualService a Kombinatioun mat DestinationRule erreechen, wou d'Regele d'Subsets a Strecken vum VirtualService zu engem spezifesche Subset bestëmmen.

Definéieren Ënnersätz an Destinatiounsregelen

Subsets (Subset) ginn duerch déi folgend Konfiguratioun bestëmmt (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. Host (host) definéiert datt dës Regel nëmme fir Fäll gëlt wann de Wee Richtung Service geet sa-logic;
2. Titelen (name) Subsets gi benotzt wann Dir op Ënnerset Instanzen routéiert;
3. Label (label) definéiert d'Schlëssel-Wäertpairen, déi Instanzen musse passen fir en Deel vum Ënnerset ze ginn.

Fëllt d'Konfiguratioun mat dem folgenden Kommando un:

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

Elo datt d'Subsets definéiert sinn, kënne mir weidergoen an de VirtualService konfiguréieren fir Reegelen op Ufroe fir sa-Logik z'applizéieren sou datt se:

1. Gitt op eng Ënnergrupp v1,
2. Gespiegelt zu engem Ënnerdeel v2.

De folgende Manifest erlaabt Iech Är Pläng z'erreechen (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

Keng Erklärung néideg hei, also loosst eis et just an Aktioun gesinn:

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

Loosst eis d'Laascht addéieren andeems Dir de folgende Kommando rufft:

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

Loosst eis d'Resultater am Grafana kucken, wou Dir kënnt gesinn datt d'Versioun mat Bugs (buggy) Resultater zu Echec fir ~ 60% vun Ufroen, awer keng vun dëse Feeler beaflossen Endbenotzer wéi se vun engem lafende Service geäntwert ginn.

Erfollegräich Äntwerte vu verschiddene Versioune vum sa-logic Service

Hei hu mir fir d'éischt gesinn wéi VirtualService op d'Envoyen vun eise Servicer applizéiert gëtt: wéini sa-web-app mécht eng Demande un sa-logic, geet et duerch de Sidecar Envoy, deen - iwwer VirtualService - konfiguréiert ass fir d'Ufro un de v1 Ënnerdeel ze routen an d'Ufro un de v2 Ënnerdeel vum Service ze spigelen sa-logic.

Ech weess, Dir mengt scho vläicht datt Virtual Services einfach ass. An der nächster Sektioun wäerte mir dat erweideren andeems se soen datt se och wierklech super sinn.

Kanaresch Rollouts

Canary Deployment ass de Prozess fir eng nei Versioun vun enger Applikatioun un eng kleng Zuel vu Benotzer auszerollen. Et gëtt benotzt fir sécherzestellen datt et keng Probleemer an der Verëffentlechung gëtt an eréischt duerno, schonn zouversiichtlech a senger (Verëffentlechung) Qualitéit, verdeelt se un aner Benotzer.оméi grouss Publikum.

Fir Kanaresch Rollouts ze demonstréieren, wäerte mir weider mat engem Ënnerdeel schaffen buggy у sa-logic.

Loosst d'Zäit net op Trifles verschwenden an direkt 20% vun de Benotzer op d'Versioun mat Käfere schécken (dëst wäert eis Kanaresch Rollout representéieren), an déi reschtlech 80% op den normale Service. Fir dëst ze maachen, benotzt de folgende VirtualService (sa-logic-subsets-kanaresch-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 ass d'Gewiicht (weight), wat de Prozentsaz vun Ufroen spezifizéiert, déi un en Empfänger oder e Subset vum Empfänger geleet ginn.

Loosst eis déi viregt VirtualService Konfiguratioun aktualiséieren fir sa-logic mat dem folgenden Kommando:

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

... a mir wäerten direkt gesinn datt e puer Ufroe zu Feeler féieren:

$ 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 erméiglechen Kanaresch Rollouts: An dësem Fall hu mir de potenziellen Impakt vun den Themen op 20% vun der Benotzerbasis verklengert. Wonnerbar! Elo, an all Fall wa mir net sécher sinn vun eisem Code (an anere Wierder - ëmmer ...), kënne mir Spigelen a Kanaresch Rollouts benotzen.

Timeouts an nei Versuche

Awer Bugs kommen net ëmmer am Code op. An der Lëscht vun "8 Mëssverständnis iwwer Distributed Computing"Op der éischter Plaz ass de falsche Glawen datt "d'Netz zouverlässeg ass." A Wierklechkeet d'Netz Net zouverlässeg, an aus dësem Grond brauche mir Timeouts (Timeout) an erëm probéiert (Wiederprobéiert).

Fir Demonstratioun wäerte mir weider déi selwecht Problemversioun benotzen sa-logic (buggy), a mir simuléieren d'Onzouverlässegkeet vum Netz mat zoufälleg Feeler.

Loosst eise Service mat Bugs eng 1/3 Chance hunn fir ze laang ze äntweren, eng 1/3 Chance fir mat engem Interne Serverfehler opzehalen, an eng 1/3 Chance fir d'Säit erfollegräich zréckzekommen.

Fir den Impakt vun esou Probleemer ze reduzéieren an d'Liewen fir d'Benotzer besser ze maachen, kënne mir:

1. füügt en Timeout un wann de Service méi wéi 8 Sekonnen dauert fir ze reagéieren,
2. probéiert nach eng Kéier wann d'Ufro feelt.

Fir Ëmsetzung benotze mir déi folgend Ressourcedefinitioun (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. Den Timeout fir d'Ufro ass op 8 Sekonnen gesat;
2. Ufroe ginn 3 Mol erëm probéiert;
3. An all Versuch gëtt als net erfollegräich ugesinn wann d'Äntwertzäit méi wéi 3 Sekonnen ass.

Dëst ass eng Optimisatioun well de Benotzer net méi wéi 8 Sekonnen muss waarden a mir wäerten dräi nei Versuche maachen fir eng Äntwert am Fall vu Feeler ze kréien, wat d'Chance op eng erfollegräich Äntwert erhéijen.

Fëllt déi aktualiséiert Konfiguratioun mat dem folgenden Kommando un:

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

A kuckt an de Grafana Grafike datt d'Zuel vun den erfollegräichen Äntwerten uewen eropgaang ass:

Verbesserungen an erfollegräicher Äntwertstatistiken no der bäigefüügt vun Timeouts an Neiversichten

Ier Dir op déi nächst Rubrik plënnert (oder éischter, zum nächsten Deel vum Artikel, well an dësem gëtt et keng praktesch Experimenter méi - ca. Iwwersetzung), läschen sa-logic-buggy a VirtualService andeems Dir déi folgend Kommandoen ausféiert:

$ 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 a Bulkhead Muster

Mir schwätzen iwwer zwee wichteg Musteren an der Mikroservicearchitektur, déi Iech erlaabt Iech SelbstErhuelung z'erreechen (Selbstheilung) Servicer.

Circuit Breaker ("circuit breaker") benotzt fir Ufroe, déi op eng Instanz vun engem Service kommen, deen als ongesond ugesi gëtt, ofzeschléissen an et ze restauréieren, während Clientsufroen op gesond Instanzen vun deem Service ëmgeleet ginn (wat de Prozentsaz vun erfollegräichen Äntwerten erhéicht). (Notiz: Eng méi detailléiert Beschreiwung vum Muster ka fonnt ginn, z.B. hei.)

Schoss ("Partition") isoléiert Servicefehler fir de ganze System ze beaflossen. Zum Beispill ass de Service B gebrach an en anere Service (De Client vum Service B) mécht eng Ufro un de Service B, wouduerch hien säi Fuedempool ausléist an net fäeg ass aner Ufroen ze servéieren (och wa se net vum Service B sinn). (Notiz: Eng méi detailléiert Beschreiwung vum Muster ka fonnt ginn, z.B. hei.)

Ech wäert d'Implementatiounsdetailer vun dëse Mustere ofleeën, well se einfach ze fannen sinn offiziell Dokumentatioun, an ech wëll och wierklech Authentifikatioun an Autorisatioun weisen, déi am nächsten Deel vum Artikel diskutéiert ginn.

PS vum Iwwersetzer

Liest och op eisem Blog:

• "Zréck op Mikroservicer mat Istio": Deel 1 (Aféierung an d'Haaptmerkmale), Deel 3 (Authentifikatioun an Autorisatioun);
• «Conduit - liicht Service Mesh fir Kubernetes";
• «Wat ass e Service Mesh a firwat brauch ech een [fir eng Cloud Applikatioun mat Mikroservicer]?".

Source: will.com