🥇Vissza a mikroszolgáltatásokhoz az Istio-val. 2. rész

Jegyzet. ford.: Első rész Ez a sorozat az Istio képességeinek bemutatására és azok gyakorlati bemutatására irányult. Most a szolgáltatásháló konfigurációjának és használatának összetettebb aspektusairól fogunk beszélni, és különösen a finoman hangolt útválasztásról és a hálózati forgalom kezeléséről.

Arra is emlékeztetünk, hogy a cikk konfigurációkat használ (a Kubernetes és az Istio esetében) a tárolóból. istio-mesterség.

forgalomirányítás

Az Istio-val új képességek jelennek meg a fürtben, amelyek biztosítják:

Dinamikus kérés-útválasztás: Canary rollouts, A/B tesztelés;
Terhelés elosztás: egyszerű és következetes, hash-ek alapján;
Esések utáni felépülés: időtúllépések, újrapróbálkozások, megszakítók;
Beillesztési hibák: késések, elutasított kérések stb.

Ahogy a cikk folytatódik, ezeket a képességeket a kiválasztott alkalmazás példájaként szemléltetjük, és az út során új fogalmakat vezetünk be. Az első ilyen koncepció az lesz DestinationRules (azaz a forgalom/kérések címzettjére vonatkozó szabályok - kb. ford.), melynek segítségével aktiváljuk az A/B tesztelést.

A/B tesztelés: DestinationRules a gyakorlatban

Az A/B tesztelést olyan esetekben alkalmazzák, amikor egy alkalmazásnak két verziója van (általában ezek vizuálisan különböznek egymástól), és nem vagyunk 100%-ban biztosak abban, hogy melyik javítja a felhasználói élményt. Ezért mindkét verziót egyidejűleg futtatjuk, és mérőszámokat gyűjtünk.

Az A/B tesztelés demonstrálásához szükséges frontend második verziójának üzembe helyezéséhez futtassa a következő parancsot:

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

A zöld verzió telepítési jegyzéke két helyen különbözik:

A kép egy másik címkén alapul - istio-green,
A hüvelyeknek van címkéje version: green.

Mivel mindkét telepítésnek van címkéje app: sa-frontend,virtuális szolgáltatás által irányított kérések sa-external-services szolgáltatásért sa-frontend, át lesz irányítva az összes példányára, és a terhelés elosztásra kerül körmérkőzéses algoritmus, ami a következő helyzethez vezet:

A kért fájlok nem találhatók

Ezek a fájlok nem találhatók, mert az alkalmazás különböző verzióiban eltérő nevük van. Győződjünk meg erről:

$ 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

Ez azt jelenti index.html, amely statikus fájlok egy verzióját kéri, a terheléselosztó elküldheti más verziójú podokra, ahol nyilvánvaló okokból nem léteznek ilyen fájlok. Ezért ahhoz, hogy az alkalmazás működjön, korlátozást kell beállítanunk: "az alkalmazás ugyanazon verziójának, amely az index.html fájlt szolgálta ki, ki kell szolgálnia a következő kéréseket".

Ezt a következetes hash-alapú terheléselosztással érjük el (Konzisztens hash terheléselosztás)... Ebben az esetben ugyanattól az ügyféltől származó kérések ugyanahhoz a háttérpéldányhoz kerülnek, amelyhez egy előre meghatározott tulajdonságot használnak – például egy HTTP-fejlécet. A DestinationRules használatával valósítva meg.

DestinationRules

Miután a VirtualService kérést küldött a kívánt szolgáltatásnak, a DestinationRules segítségével meghatározhatunk házirendeket, amelyek a szolgáltatás példányaira irányuló forgalomra vonatkoznak:

Forgalomirányítás Istio erőforrásokkal

Megjegyzés: Az Istio erőforrásainak a hálózati forgalomra gyakorolt hatását itt könnyen érthető módon mutatjuk be. Pontosabban, a döntést arról, hogy melyik példánynak küldje el a kérelmet, a megbízott hozza meg a CRD-ben konfigurált Belépési átjáróban.

A Destination Rules segítségével beállíthatjuk a terheléselosztást úgy, hogy konzisztens hash-eket használjon, és biztosítsa, hogy ugyanaz a szolgáltatáspéldány ugyanannak a felhasználónak válaszoljon. A következő konfiguráció lehetővé teszi ennek elérését (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 - a kivonat a HTTP-fejléc tartalma alapján jön létre version.

Alkalmazza a konfigurációt a következő paranccsal:

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

Most futtassa az alábbi parancsot, és győződjön meg arról, hogy a megfelelő fájlokat kapja meg a fejléc megadásakor version:

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

Megjegyzés: Ha különböző értékeket szeretne hozzáadni a fejléchez, és közvetlenül a böngészőben teszteli az eredményeket, használhatja ezt a kiterjesztést a Chrome-hoz (vagy ezzel Firefoxhoz - kb. fordítás.).

Általánosságban elmondható, hogy a DestinationRules több lehetőséggel rendelkezik a terheléselosztás területén – a részletekért tekintse meg hivatalos dokumentáció.

A VirtualService további tanulmányozása előtt töröljük az alkalmazás „zöld verzióját” és a megfelelő forgalmi irány szabályt a következő parancsok futtatásával:

$ 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

Tükrözés: Virtuális szolgáltatások a gyakorlatban

Árnyékolós ("árnyékolás") vagy Tükrözés ("tükrözés") olyan esetekben használjuk, amikor a végfelhasználók befolyásolása nélkül akarunk tesztelni egy termelési változást: ehhez megkettőzzük („tükrözzük”) a kéréseket egy második példányra, ahol a kívánt változtatások megtörténtek, és megvizsgáljuk a következményeket. Egyszerűen fogalmazva, ilyenkor a kollégája kiválasztja a legkritikusabb problémát, és olyan hatalmas szennyeződés formájában kér lehívást, hogy senki sem tudja felülvizsgálni.

A forgatókönyv működésbeli teszteléséhez hozzuk létre az SA-Logic második példányát hibákkal (buggy) a következő parancs futtatásával:

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

Most pedig futtassuk a parancsot, hogy megbizonyosodjunk arról, hogy az összes példány a app=sa-logic A megfelelő verziókkal ellátott címkékkel is rendelkeznek:

$ 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

Szolgáltatás sa-logic címkével ellátott hüvelyeket célozza meg app=sa-logic, így minden kérés el lesz osztva az összes példány között:

... de azt szeretnénk, hogy a kérések a v1 példányokra kerüljenek elküldésre, és tükröződjenek a v2 példányokra:

Ezt a VirtualService és a DestinationRule kombináció segítségével érjük el, ahol a szabályok határozzák meg a VirtualService részhalmazait és útvonalait egy adott részhalmazhoz.

Részhalmazok meghatározása a rendeltetési szabályokban

Részhalmazok (részhalmazok) a következő konfiguráció határozza meg (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

Házigazda (host) meghatározza, hogy ez a szabály csak azokra az esetekre vonatkozik, amikor az útvonal a szolgáltatás felé tart sa-logic;
Címek (name) részhalmazokat használnak az alhalmaz példányokhoz való irányítás során;
Címke (label) határozza meg azokat a kulcs-érték párokat, amelyeknek a példányoknak meg kell felelniük ahhoz, hogy az alhalmaz részévé váljanak.

Alkalmazza a konfigurációt a következő paranccsal:

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

Most, hogy az alhalmazok definiáltak, továbbléphetünk, és beállíthatjuk a VirtualService-t, hogy szabályokat alkalmazzon a sa-logic kérésekre, így azok:

Egy részhalmazba irányítva v1,
Egy részhalmazhoz tükrözve v2.

A következő kiáltvány lehetővé teszi, hogy elérje terveit (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

Itt nincs szükség magyarázatra, nézzük csak működés közben:

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

Adjuk hozzá a terhelést a következő parancs meghívásával:

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

Nézzük meg a Grafana eredményeit, ahol láthatjuk, hogy a hibákkal (buggy) a kérések kb. 60%-a meghibásodását eredményezi, de ezek a hibák egyike sem érinti a végfelhasználókat, mivel egy futó szolgáltatás válaszol rájuk.

A sa-logic szolgáltatás különböző verzióinak sikeres válaszai

Itt láttuk először, hogyan alkalmazzák a VirtualService-t szolgáltatásaink küldötteire: mikor sa-web-app kérelmet nyújt be sa-logic, átmegy az oldalkocsis Envoy-n, amely a VirtualService-en keresztül úgy van beállítva, hogy a kérést a v1 részhalmazba irányítsa, és tükrözze a kérést a szolgáltatás v2 részhalmazába. sa-logic.

Tudom, már azt gondolhatja, hogy a Virtuális szolgáltatások egyszerű. A következő részben ezt kibővítjük azzal, hogy ezek is igazán nagyszerűek.

Canary Rollouts

A Canary Deployment egy alkalmazás új verziójának bevezetése kis számú felhasználó számára. Arra szolgál, hogy megbizonyosodjon arról, hogy nincs probléma a kiadásban, és csak ezt követően, már bízva a (kiadás) minőségében, terjessze más felhasználóknak.оnagyobb közönség.

A kanári kihelyezések bemutatásához továbbra is egy részhalmazsal dolgozunk buggy у sa-logic.

Ne vesztegessük az időt apróságokra, és azonnal küldjük a felhasználók 20%-át a hibákat tartalmazó verzióra (ez a kanári bevezetésünket jelenti), a maradék 80%-ot pedig a normál szolgáltatásba. Ehhez használja a következő 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 a súly (weight), amely a címzetthez vagy a címzett részhalmazához irányított kérések százalékos arányát adja meg.

Frissítsük a VirtualService korábbi konfigurációját sa-logic a következő paranccsal:

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

... és azonnal látni fogjuk, hogy egyes kérések kudarcokhoz vezetnek:

$ 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

A VirtualServices lehetővé teszi a kanári közzétételt: Ebben az esetben a problémák lehetséges hatását a felhasználói bázis 20%-ára szűkítettük. Csodálatos! Most már minden olyan esetben, amikor nem vagyunk biztosak a kódunkban (más szóval mindig...), használhatunk tükrözést és kanári kiterjesztéseket.

Időtúllépések és újrapróbálkozások

A hibák azonban nem mindig kerülnek a kódba. A listában innen: "8 Tévhitek az elosztott számítástechnikáról„Első helyen az a téves hiedelem áll, hogy „a hálózat megbízható”. Valójában a hálózat nincs megbízható, ezért időkorlátokra van szükségünk (időtúllépések) és újra próbálkozik (újra próbálkozik).

A demonstrációhoz továbbra is ugyanazt a problémás verziót fogjuk használni sa-logic (buggy), és véletlenszerű hibákkal szimuláljuk a hálózat megbízhatatlanságát.

Hagyja, hogy a hibákat tartalmazó szolgáltatásunknak 1/3-a eséllyel túl sokáig tart a válaszadás, 1/3-a annak, hogy belső szerverhibával végződjön, és 1/3-a esélye annak, hogy sikeresen visszaküldi az oldalt.

Az ilyen problémák hatásának mérséklése és a felhasználók életének jobbá tétele érdekében:

adjon hozzá időtúllépést, ha a szolgáltatás 8 másodpercnél tovább tart a válaszadáshoz,
próbálja újra, ha a kérés sikertelen.

A megvalósításhoz a következő erőforrás-definíciót fogjuk használni (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

A kérés időkorlátja 8 másodpercre van beállítva;
A kérelmeket 3 alkalommal próbálják meg újra;
És minden próbálkozás sikertelennek minősül, ha a válaszidő meghaladja a 3 másodpercet.

Ez egy optimalizálás, mert a felhasználónak nem kell 8 másodpercnél többet várnia, és három új kísérletet teszünk, hogy hiba esetén választ kapjunk, növelve a sikeres válasz esélyét.

Alkalmazza a frissített konfigurációt a következő paranccsal:

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

És nézze meg a Grafana grafikonokon, hogy a sikeres válaszok száma a fentiekre nőtt:

Javítások a sikeres válaszadási statisztikákban az időtúllépések és az újrapróbálkozások hozzáadása után

Mielőtt továbblépne a következő részre (vagy inkább a cikk következő részére, mert ebben nem lesz több gyakorlati kísérlet - kb. ford.), törölje sa-logic-buggy és a VirtualService a következő parancsok futtatásával:

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

Megszakító és válaszfal minták

A mikroszolgáltatási architektúra két fontos mintájáról beszélünk, amelyek lehetővé teszik az ön-helyreállítás elérését (öngyógyító) szolgáltatásokat.

Biztosíték ("biztosíték") a szolgáltatás egészségtelennek ítélt példányához érkező kérések leállítására és visszaállítására szolgál, miközben az ügyfélkérelmek átirányításra kerülnek a szolgáltatás egészséges példányaira (ami növeli a sikeres válaszok százalékos arányát). (Megjegyzés: A minta részletesebb leírása megtalálható pl. itt.)

Válaszfal ("partíció") elszigeteli a szolgáltatási hibákat attól, hogy azok az egész rendszert érintsék. Például a B szolgáltatás megszakad, és egy másik szolgáltatás (a B szolgáltatás kliense) kérést küld a B szolgáltatásnak, aminek következtében az kimeríti a szálkészletét, és nem tud más kéréseket kiszolgálni (még akkor sem, ha azok nem a B szolgáltatástól származnak). (Megjegyzés: A minta részletesebb leírása megtalálható pl. itt.)

Ezeknek a mintáknak a megvalósítási részleteit elhagyom, mert könnyen megtalálhatóak hivatalos dokumentáció, és nagyon szeretném bemutatni a hitelesítést és az engedélyezést is, amelyekről a cikk következő részében lesz szó.

PS a fordítótól

Olvassa el blogunkon is:

"Vissza a mikroszolgáltatásokhoz az Istióval": 1. rész (bevezetés a főbb jellemzőkbe), 3. rész (hitelesítés és engedélyezés);
«Csővezeték - könnyű szervizháló a Kubernetes számára";
«Mi az a szolgáltatásháló, és miért van szükségem rá [mikroszolgáltatásokkal rendelkező felhőalkalmazásokhoz]?".

Forrás: will.com

Vissza a mikroszolgáltatásokhoz az Istio-val. 2. rész