Vissza a mikroszolgáltatásokhoz az Istióval. 2. rész

Megjegyzés fordítás.: Első rész ennek a ciklusnak az volt a célja, hogy bemutassa az Istio lehetőségeit és azok működését. Most pedig a konfiguráció és a service mesh használatának összetettebb aspektusairól fogunk beszélni, különös figyelemmel a finoman hangolt útválasztásra és a hálózati forgalom kezelésére.

Továbbá emlékeztetjük, hogy a cikkben a Kubernetes és Istio konfigurációkat (manifesztációkat) használjuk a istio-mastery.

Forgalomkezelés

Az Istióval a klaszterben új lehetőségek nyílnak, amelyek lehetővé teszik:

• Dinamikus lekérdezés-útválasztás: kanárik kiadása, A/B tesztelés;
• Terheléselosztás: egyszerű és koherens, a hash-alapú;
• Újraindítások: időtúllépések, újrapróbálkozások, áramkör-védők;
• Zavarbebocsátás: késleltetések, kérésmegszakítások, stb.

A cikk folytatásában ezeket a lehetőségeket egy kiválasztott alkalmazás példáján keresztül mutatjuk be, miközben új fogalmakat is bemutatunk. Az első ilyen fogalom a DestinationRules (azaz a forgalom/kérés fogadójáról szóló szabályok — a fordító megjegyzése), amellyel aktiváljuk az A/B tesztelést.

A/B tesztelés:  DestinationRules a gyakorlatban

Az A/B tesztelést olyan esetekben alkalmazzuk, amikor két verzió létezik az alkalmazásból (általában vizuálisan különböznek), és nem vagyunk biztosak abban, hogy melyik javítja a felhasználói élményt. Ezért egyszerre futtatjuk mindkét verziót, és gyűjtjük a metrikákat.

A második verzió telepítéséhez, amely szükséges az A/B tesztelés bemutatásához, 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ó" deployment manifestuma két helyen eltér:

1. A kép egy másik címkén alapul — istio-green,
2. A Podok rendelkeznek egy címkével version: green.

Mivel mindkét deployment rendelkezik a app: sa-frontendcímkével, a sa-external-services virtuális szolgáltatás által irányított kérések sa-frontendfogják átirányítani az összes példányára, és a terhelés a körkörös módszersegítségével lesz elosztva, ami a következő helyzetet eredményezi:

Kért fájlok nem találhatóak

Ezek a fájlok nem találhatóak, mivel különböző nevek alatt szerepelnek az alkalmazás különböző verzióiban. 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, hogy index.html, a statikus fájlok egyik verzióját kérő, terheléselosztó által olyan podokhoz lehet küldeni, amelyek egy másik verzióval rendelkeznek, ahol, érthető okokból, az ilyen fájlok nem találhatóak. Ezért ahhoz, hogy az alkalmazás működjön, korlátozást kell beállítanunk: „az ugyanaz a verziója az alkalmazásnak, amely visszaadta az index.html-t, annak kell kezelnie a további kéréseket is».

Célunkat a hash-alapú következetes terheléselosztás segítségével érjük el (Következetes Hash Terheléselosztás). Ebben az esetben egy ügyfeletől érkező kérések ugyanahhoz a háttér-instanctushoz kerülnek elküldésre, erre egy előre meghatározott tulajdonságot használunk — például HTTP-fejlécet. A DestinationRules segítségével valósítjuk meg.

DestinationRules

Miután VirtualService irányította a kérést a megfelelő szolgáltatás felé, a DestinationRules segítségével meghatározhatjuk azokat a politikákat, amelyek a szolgáltatás instanciáira irányuló forgalomra lesznek alkalmazva:

forgalom irányítása Istio erőforrásokkal

Megjegyzés: Az Istio erőforrások hatása a hálózati forgalomra itt érthető formában van bemutatva. Pontosabban, a kérés melyik instanciára kerüljön küldésre, azt az Envoy határozza meg az Ingress Gateway-ben, amely a CRD-ben van beállítva.

A Destination Rules segítségével úgy állíthatjuk be a terheléselosztást, hogy következetes hash-eket használjon, és garantálja, hogy ugyanattól a szolgáltatásinstanciától kapjon választ ugyanaz a felhasználó. A következő konfiguráció lehetővé teszi ezt (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 hash az HTTP-fejléc tartalma alapján fog generálódni version.

Alkalmazza a konfigurációt a következő parancs segítségével:

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

Most futtassa az alábbi parancsot, és győződjön meg róla, hogy a megfelelő fájlokat kapja, amikor megadja a fejlécet version:

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

Megjegyzés: Különböző értékek hozzáadásához a fejlécben, és az eredmények teszteléséhez közvetlenül a böngészőben, használhatja ezt a bővítményt a Chrome-hoz SysWOW64 ezt itt a Firefox-hoz — megjegyz. a fordító).

A DestinationRules-nak valójában még több lehetősége van a terheléselosztás terén — részletekért kérjük érdeklődjön a hivatalos dokumentációban.

Mielőtt tovább tanulmányoznánk a VirtualService-t, töröljük az alkalmazás „zöld verzióját” és a kapcsolódó forgalomirányító szabályt az alábbi parancsok végrehajtásával:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” törölve
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” törölve

Tükrözés: Virtual Services a gyakorlatban

Shadowing („árnyékolás”) vagy Mirroring („tükrözés”) akkor alkalmazandó, amikor szeretnénk tesztelni egy változtatást a termelési környezetben anélkül, hogy a végfelhasználókat érintenénk: ehhez duplikáljuk (tükrözzük) a kéréseket egy másik példányra, ahol a szükséges változtatások megtörténtek, és figyeljük meg a következményeket. Egyszerűbben fogalmazva, amikor a kollégád a legkritikusabb hibát választja ki és pull requestet küld be egy olyan hatalmas, zűrzavart okozó blokkban, hogy senki sem tudja igazából véleményezni.

Az előző forgatókönyv teszteléséhez hozzunk létre egy második SA-Logic példányt hibákkal (buggy), az alábbi parancs végrehajtásával:

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

Most futtassuk le a parancsot, hogy megbizonyosodjunk róla, hogy minden példányra vonatkozik app=sa-logic még a megfelelő verzíkkel ellátott címkékkel is rendelkezik:

$ 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élja a címkével ellátott podok app=sa-logic, ezért az összes kérés megosztásra kerül az összes példány között:

… de szeretnénk, ha a kérések az v1 verziójú példányokhoz irányulnának, és tükröződnének az v2 verziójú példányokra:

Ezt a VirtualService és az DestinationRule kombinációján keresztül érjük el, ahol a szabályok meghatározzák az almintákat és a VirtualService útvonalait a konkrét alminta felé.

Alminták meghatározása Destination Rules-ben

Alminták (subsets) az alábbi konfigurációval vannak meghatározva (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. A host (host) meghatározza, hogy ez a szabály csak akkor érvényes, ha az útvonal a szolgáltatás irányába halad sa-logic;
2. A neve (name) az alminták használatakor érvényesülnek az alminták példányaira való irányítás során;
3. A címke (label) meghatározza azokat a kulcs-érték párokat, amelyeknek meg kell felelniük az példányoknak ahhoz, hogy a részhalmaz részét képezzék.

Alkalmazza a konfigurációt a következő parancs segítségével:

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

Most, hogy a részhalmazok meg vannak határozva, folytathatjuk a VirtualService beállítását, hogy alkalmazzuk a szabályokat a sa-logic-ra érkező kérésekre, hogy ezek:

1. irányítva legyenek a részhalmazhoz v1,
2. tükrözve legyenek a részhalmazhoz v2.

A következő manifest lehetővé teszi a kívánt eredmény elérését (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ázatokra, nézzük meg a működést:

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

Hozzáadunk terhelést az alábbi parancs végrehajtásával:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "Imádom a yogobellát"}'; 
    sleep .8; done

Nézzük meg az eredményeket a Grafana-ban, ahol látható, hogy a hibás verzió (buggy) körülbelül 60%-os hibaarányt eredményez, de ezek a hibák nem érintik a végfelhasználókat, mivel ők a működő szolgáltatást kapják.

A sa-logic szolgáltatás különböző verzióinak válaszainak sikeressége

Itt először láttuk, hogyan alkalmazzák a VirtualService-t a szolgáltatásaink Envoy-jainak viszonyában: amikor sa-web-app kérést intéz a sa-logic, akkor az áthalad a sidecar Envoy-on, amely — a VirtualService-en keresztül — a kérés routing-jára van beállítva, hogy az v1 részhalmazhoz irányítson és v2 részhalmazhoz tükrözze a kérést. sa-logic.

Tudom: máris eszetekbe jutott, hogy a Virtual Services egyszerűek. A következő szakaszban ezt a véleményt kiterjesztjük azzal, hogy valóban nagyszerűek is.

Kanári kiadások

A Canary Deployment egy új alkalmazásverzió kiadásának folyamata kis számú felhasználó számára. Ezt használják, hogy megbizonyosodjanak a kiadás hibátlanságáról, és csak ezután, miután biztosak a kiadás minőségében, terjesztik el a szélesebb közönségnek.óA kanári kiadások bemutatására folytatjuk a munkát a részhalmazzal

ne legyünk apróságra kényesek, és azonnal 20%-ot irányítsunk a hibás verzióra (ez lesz a kanári kiadásunk), míg a fennmaradó 80%-ot a normális szolgáltatáshoz. Ehhez alkalmazzuk a következő VirtualService-t ( buggy sa-logic-subsets-canary-vs.yaml sa-logic.

Ne hagyjuk magunkat apróságokkal foglalkozni, és rögtön 20 % -ot küldünk a hibás verzióra (ez lesz a kanári kiadásunk), míg a maradék 80 % a normál szolgáltatásra. Ehhez a következő VirtualService-t alkalmazzuk (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 — ez a súly (súly), amely meghatározza a kérések százalékát, amelyeket a célpont vagy a célpont alcsoportra irányítanak.

Frissítjük a korábbi VirtualService konfigurációt a sa-logic következő parancs segítségével:

$ 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 a kérések egy része hibákhoz vezet:

$ 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 aktíválja a kanári telepítéseket: ebben az esetben a problémák potenciális hatásait 20 %-ra csökkentettük a felhasználói bázisból. Remek! Most, amikor nem vagyunk biztosak a kódunkban (más szóval — mindig...), használhatjuk a tükrözést és a kanári telepítéseket.

Időkiesések és újrapróbálkozások

De nem mindig a hibák találhatók a kódban. Az "8 tévhit a elosztott számítástechnikában" lista élén szerepel az a téves nézet, hogy "a hálózat megbízható". Valójában a hálózat nem megbízható, és ezért szükségünk van időkiesésekre (timeouts) és újrapróbálkozásokra (retries).

Az illusztrációhoz ugyanazt a probléma verziót használjuk, sa-logic (buggy), de a hálózat megbízhatatlanságát véletlenszerű hibákkal szimuláljuk.

Tegyük fel, hogy a hibákkal teli szolgáltatásunk 1/3 eséllyel ad túl hosszú választ, 1/3 eséllyel Internal Server Error-t generál, és 1/3 eséllyel sikeresen szolgáltatja az oldalt.

A hasonló problémák következményeinek enyhítésére és a felhasználók életének javítására a következő lehetőségeket választhatjuk:

1. hozzáadunk egy időkiesést, ha a szolgáltatás 8 másodpercnél tovább válaszol,
2. újrapróbálkozást indítunk el, ha a kérés hibát okoz.

A megvalósításhoz a következő erőforrást használjuk (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. A kérés időkorlátja 8 másodpercre van beállítva;
2. A kérési újrapróbálkozások három alkalommal történnek.
3. Minden kísérlet sikertelennek számít, ha a válaszidő meghaladja a 3 másodpercet.

Ezzel optimalizáltunk, mivel a felhasználónak nem kell 8 másodpercnél tovább várnia, és három újabb kísérletet teszünk a válasz megkapására hibák esetén, 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 konfigurálva

És ellenőrizze a Grafana grafikonokon, hogy a sikeres válaszok száma meghaladta a következőt:

Javulások a sikeres válaszok statisztikájában a timeout-ok és újrapróbálkozások hozzáadása után

Mielőtt a következő szakaszra lépnénk (vagyis a cikk következő részére, mivel ebben a részben nem lesz több gyakorlati kísérlet - a fordító megjegyzése), távolítsa el sa-logic-buggy és a VirtualService, a következő parancsok végrehajtásával:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” törölve
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” törölve

Ciklus megszakító és bulkhead minták

Két fontos mintáról van szó a mikroszolgáltatás-architektúrában, amelyek lehetővé teszik a szolgáltatások önálló helyreállítását (self-healing) a szolgáltatások számára.

Ciklus megszakító („automatikus megszakító”) arra szolgál, hogy leállítsa a kérések fogadását egy olyan szolgáltatás példányon, amelyet egészségtelennek tartanak, és lehetővé tegye a helyreállítását, miközben az ügyfélkéréseket az egészséges példányokra irányítják (ami növeli a sikeres válaszok arányát). (A fordító megjegyzése: Részletesebb leírás a mintáról például itt található, itt.)

Bulkhead („választófal”) izolálja a szolgáltatások hibáit, megakadályozva, hogy az egész rendszer megsérüljön. Például, ha a B szolgáltatás hibás, egy másik szolgáltatás (a B szolgáltatás ügyfele) kérdést tesz fel a B szolgáltatásnak, amely következtében kimeríti a szálpoolszámait, és nem tud más kéréseket kiszolgálni (még akkor is, ha azok nem a B szolgáltatásra vonatkoznak). (A fordító megjegyzése: Részletesebb leírás a mintáról például itt található, itt.)

A minták megvalósításának részleteit kihagyom, mert ezeket könnyen meg lehet találni hivatalos dokumentációban, és nagyon érdekes lenne bemutatni az autentikációt és jogosultságkezelést, amiről a következő cikk részben szó lesz.

Fejlesztési eszközök, amelyek Kubernetesben futnak

Olvasson további információkat a blogunkban:

• „Vissza a mikroszolgáltatásokhoz az Istióval”: 1. rész (az alapvető funkciók bemutatása), 3. rész (autentikáció és jogosultságkezelés);
• «Conduit — könnyű service mesh a Kuberneteshez»;
• «Mi az a service mesh és miért van szükségem [felhőalapú mikroszolgáltatásokhoz]?».

Forrás: habr.com