Takaisin mikropalveluihin Istion kanssa. Osa 2

Huomautus. käännös: Ensimmäinen osa Tämä sarja oli omistettu Istion ominaisuuksien esittelylle ja niiden esittelylle toiminnassa. Nyt puhumme tämän palveluverkon konfiguroinnin ja käytön monimutkaisemmista näkökohdista ja erityisesti hienosäädetystä reitityksestä ja verkkoliikenteen hallinnasta.

Muistutamme myös, että artikkeli käyttää konfiguraatioita (Kubernetesin ja Istion manifesteja) arkistosta istio-mestaruus.

liikenteen hallinta

Istion avulla klusteriin tulee uusia ominaisuuksia, jotka tarjoavat:

• Dynaaminen pyynnön reititys: Canary rollouts, A/B-testaus;
• Kuormituksen tasapainoittaminen: yksinkertainen ja johdonmukainen, perustuu tiivisteisiin;
• Toipuminen kaatumisen jälkeen: aikakatkaisut, uudelleenyritykset, katkaisijat;
• Vikojen lisääminen: viivästykset, hylätyt pyynnöt jne.

Artikkelin edetessä näitä ominaisuuksia havainnollistetaan käyttämällä esimerkkinä valittua sovellusta ja uusia konsepteja esitellään matkan varrella. Ensimmäinen tällainen käsite on DestinationRules (eli säännöt liikenteen/pyyntöjen vastaanottajasta - noin käännös.), jonka avulla aktivoimme A/B-testauksen.

A/B-testaus: DestinationRules käytännössä

A/B-testausta käytetään tapauksissa, joissa sovelluksesta on kaksi versiota (yleensä ne ovat visuaalisesti erilaisia) emmekä ole 100% varmoja, kumpi parantaa käyttökokemusta. Siksi käytämme molempia versioita samanaikaisesti ja keräämme mittareita.

Ota käyttöön käyttöliittymän toinen versio, joka tarvitaan A/B-testauksen esittelyyn, suorittamalla seuraava komento:

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

Vihreän version käyttöönottoluettelo eroaa kahdesta syystä:

1. Kuva perustuu eri tagiin - istio-green,
2. Paloissa on etiketti version: green.

Koska molemmilla käyttöönotoilla on tunniste app: sa-frontend,virtuaalipalvelun reitittämät pyynnöt sa-external-services palvelua varten sa-frontend, ohjataan kaikkiin esiintymiinsä ja kuorma jaetaan round robin -algoritmi, joka johtaa seuraavaan tilanteeseen:

Pyydettyjä tiedostoja ei löytynyt

Näitä tiedostoja ei löytynyt, koska ne on nimetty eri sovelluksen eri versioissa. Varmistetaan tämä:

$ 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

Tämä tarkoittaa, että index.html, joka pyytää yhtä versiota staattisista tiedostoista, voi lähettää kuormituksen tasapainottimella koteloihin, joilla on eri versio, jos tällaisia ​​tiedostoja ei ilmeisistä syistä ole olemassa. Siksi, jotta sovellus toimisi, meidän on asetettava rajoitus: "saman sovelluksen version, joka palveli index.html:tä, tulee palvella myöhempiä pyyntöjä'.

Pääsemme siihen johdonmukaisella hash-pohjaisella kuormituksen tasapainotuksella (Johdonmukainen hash-kuormituksen tasapainotus). Tässä tapauksessa saman asiakkaan pyynnöt lähetetään samaan tausta-instanssiin, jolle käytetään ennalta määritettyä ominaisuutta - esimerkiksi HTTP-otsikkoa. Toteutettu DestinationRules-säännöillä.

DestinationRules

Jälkeen Virtuaalipalvelu Lähetti pyynnön haluttuun palveluun, DestinationRules-säännöillä voimme määrittää käytännöt, joita sovelletaan tämän palvelun esiintymiin kohdistettuun liikenteeseen:

Liikenteenhallinta Istion resursseilla

Huomata: Istion resurssien vaikutus verkkoliikenteeseen on esitetty tässä helposti ymmärrettävällä tavalla. Tarkemmin sanottuna päätöksen siitä, mihin instansseihin pyyntö lähettää, tekee lähettiläs CRD:ssä määritetyssä Ingress Gatewayssä.

Kohdesääntöjen avulla voimme määrittää kuormituksen tasapainotuksen käyttämään johdonmukaisia ​​hajautusarvoja ja varmistaa, että sama palveluinstanssi vastaa samalle käyttäjälle. Seuraavalla kokoonpanolla voit saavuttaa tämän (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 luodaan HTTP-otsikon sisällön perusteella version.

Käytä kokoonpanoa seuraavalla komennolla:

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

Suorita nyt alla oleva komento ja varmista, että saat oikeat tiedostot, kun määrität otsikon version:

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

Huomata: Voit lisätä eri arvoja otsikkoon ja testata tuloksia suoraan selaimessa tämä laajennus Chromeen (tai tämän kanssa Firefoxille - noin. käännös.).

Yleensä DestinationRulesilla on enemmän ominaisuuksia kuormituksen tasapainottamisen alalla - katso lisätietoja kohdasta virallinen dokumentaatio.

Ennen kuin tutkit VirtualServiceä tarkemmin, poistetaan sovelluksen "vihreä versio" ja sitä vastaava liikenteen suuntasääntö suorittamalla seuraavat komennot:

$ 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

Peilaus: Virtuaalipalvelut käytännössä

shadowing ("suojaus") tai Peilaus ("peilaus") käytetään tapauksissa, joissa haluamme testata tuotannon muutosta vaikuttamatta loppukäyttäjiin: tätä varten kopioimme ("peilaa") pyynnöt toiseen tapaukseen, jossa halutut muutokset on tehty, ja katsomme seurauksia. Yksinkertaisesti sanottuna tämä on silloin, kun kollegasi valitsee kriittisimmän ongelman ja tekee vetopyynnön niin valtavan likapalan muodossa, että kukaan ei voi tarkistaa sitä.

Jos haluat testata tätä skenaariota toiminnassa, luodaan toinen SA-Logic-esiintymä, jossa on virheitä (buggy) suorittamalla seuraava komento:

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

Ja nyt suoritetaan komento varmistaaksemme, että kaikki esiintymät app=sa-logic Niissä on myös tarrat vastaavilla versioilla:

$ 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

Työkalut sa-logic kohdistetaan etiketeillä varustettuihin paloihin app=sa-logic, joten kaikki pyynnöt jaetaan kaikkien esiintymien kesken:

... mutta haluamme, että pyynnöt lähetetään v1-esiintymiin ja peilataan v2-esiintymiin:

Saavutamme tämän VirtualServicen avulla yhdessä DestinationRulen kanssa, jossa säännöt määrittävät VirtualServicen osajoukot ja reitit tiettyyn osajoukkoon.

Osajoukkojen määrittäminen kohdesäännöissä

Osajoukot (alajoukot) määritetään seuraavalla kokoonpanolla (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. Isäntä (host) määrittelee, että tämä sääntö koskee vain tapauksia, joissa reitti kulkee kohti palvelua sa-logic;
2. Otsikot (name) osajoukkoja käytetään reititettäessä osajoukkoinstanssiin;
3. Label (label) määrittää avain-arvo-parit, joita esiintymien on vastattava tullakseen osaksi osajoukkoa.

Käytä kokoonpanoa seuraavalla komennolla:

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

Nyt kun osajoukot on määritelty, voimme siirtyä eteenpäin ja määrittää VirtualServicen soveltamaan sääntöjä sa-logiikkapyyntöihin, jotta ne:

1. Reititetty osajoukkoon v1,
2. Peilattu osajoukkoon v2.

Seuraavan manifestin avulla voit saavuttaa suunnitelmasi (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

Tässä ei tarvita selityksiä, joten katsotaanpa sitä toiminnassa:

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

Lisätään kuorma kutsumalla seuraava komento:

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

Katsotaanpa tuloksia Grafanassa, jossa voit nähdä, että versio, jossa on bugeja (buggy) johtaa epäonnistumiseen noin 60 %:ssa pyynnöistä, mutta mikään näistä virheistä ei vaikuta loppukäyttäjiin, koska käynnissä oleva palvelu vastaa niihin.

Onnistuneet vastaukset sa-logic-palvelun eri versioista

Täällä näimme ensimmäisen kerran, kuinka VirtualServiceä sovelletaan palveluidemme lähettiläisiin: milloin sa-web-app tekee pyynnön sa-logic, se kulkee sivuvaunun Envoyn kautta, joka - VirtualServicen kautta - on määritetty reitittämään pyyntö v1-alijoukkoon ja peilaamaan pyyntö palvelun v2-alijoukkoon. sa-logic.

Tiedän, saatat jo ajatella, että virtuaalipalvelut ovat yksinkertaisia. Seuraavassa osiossa laajennamme sitä sanomalla, että ne ovat myös todella mahtavia.

Canary Rollouts

Canary Deployment on prosessi, jossa sovelluksen uusi versio julkaistaan ​​pienelle määrälle käyttäjiä. Sitä käytetään varmistamaan, että julkaisussa ei ole ongelmia ja vasta sen jälkeen, kun olet jo varma sen (julkaisun) laadusta, jakaa se muille käyttäjille.оsuurempi yleisö.

Jatkamme työskentelyä osajoukon kanssa esitelläksemme kanarialintujen käyttöönottoa buggy у sa-logic.

Älkäämme tuhlaako aikaa pikkuasioihin ja lähettäkäämme 20% käyttäjistä välittömästi bugi-versioon (tämä edustaa Canary-julkaisuamme) ja loput 80% normaaliin palveluun. Voit tehdä tämän käyttämällä seuraavaa 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 on paino (weight), joka määrittää vastaanottajalle tai vastaanottajan osajoukolle suunnattujen pyyntöjen prosenttiosuuden.

Päivitetään edellinen VirtualService-kokoonpano verkkotunnukselle sa-logic seuraavalla komennolla:

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

... ja näemme heti, että jotkin pyynnöt johtavat epäonnistumiseen:

$ 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 mahdollistaa Canaryn käyttöönoton: Tässä tapauksessa olemme rajanneet ongelmien mahdollisen vaikutuksen 20 prosenttiin käyttäjäkannasta. Ihana! Nyt kaikissa tapauksissa, joissa emme ole varmoja koodistamme (toisin sanoen - aina...), voimme käyttää peilaus- ja canary rolloutia.

Aikakatkaisut ja uudelleenyritykset

Mutta virheet eivät aina päädy koodiin. Luettelossa alkaen "8 väärinkäsitystä hajautetusta tietojenkäsittelystä"Ensinnäkin on virheellinen uskomus "verkko on luotettava". Todellisuudessa verkko ei luotettava, ja tästä syystä tarvitsemme aikakatkaisuja (aikakatkaisut) ja yrittää uudelleen (yrittää uudelleen).

Esittelyssä jatkamme saman ongelmaversion käyttöä sa-logic (buggy), ja simuloimme verkon epäluotettavuutta satunnaisilla vioilla.

Anna virheitä sisältävälle palvelullemme 1/3 todennäköisyydellä, että vastaaminen kestää liian kauan, 1/3 todennäköisyydellä päättyy sisäiseen palvelinvirheeseen ja 1/3 todennäköisyydellä sivun palauttaminen onnistuneesti.

Lieventääksemme tällaisten ongelmien vaikutusta ja parantaaksemme käyttäjien elämää, voimme:

1. lisää aikakatkaisu, jos palvelun vastaaminen kestää yli 8 sekuntia,
2. yritä uudelleen, jos pyyntö epäonnistuu.

Toteutuksessa käytämme seuraavaa resurssimääritelmää (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. Pyynnön aikakatkaisuksi on asetettu 8 sekuntia;
2. Pyyntöjä yritetään uudelleen 3 kertaa;
3. Ja jokainen yritys katsotaan epäonnistuneeksi, jos vasteaika ylittää 3 sekuntia.

Tämä on optimointi, koska käyttäjän ei tarvitse odottaa kahdeksaa sekuntia kauempaa ja teemme kolme uutta yritystä saada vastaus epäonnistuessa, mikä lisää onnistuneen vastauksen mahdollisuuksia.

Ota päivitetty kokoonpano käyttöön seuraavalla komennolla:

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

Ja tarkista Grafana-kaavioista, että onnistuneiden vastausten määrä on kasvanut edellä:

Onnistuneiden vastaustilastojen parannuksia aikakatkaisujen ja uudelleenyritysten lisäämisen jälkeen

Ennen kuin siirryt seuraavaan osaan (tai pikemminkin artikkelin seuraavaan osaan, koska tässä ei ole enää käytännön kokeita - noin käännös.), poista sa-logic-buggy ja VirtualService suorittamalla seuraavat komennot:

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

Katkaisija- ja laipiomallit

Puhumme kahdesta tärkeästä mikropalveluarkkitehtuurin mallista, joiden avulla voit saavuttaa itsensä palautumisen (itseparantava) palvelut.

katkaisija ("katkaisija") käytetään lopettamaan pyynnöt, jotka tulevat epäterveellisenä pidetyn palvelun ilmentymään ja palauttamaan se, kun taas asiakaspyynnöt uudelleenohjataan kyseisen palvelun terveisiin esiintymiin (mikä lisää onnistuneiden vastausten prosenttiosuutta). (Huom: Tarkempi kuvaus kuviosta löytyy esim. täällä.)

väliseinä ("osio") eristää palveluvirheet vaikuttamasta koko järjestelmään. Esimerkiksi palvelu B on rikki ja toinen palvelu (palvelun B asiakas) tekee pyynnön palvelulle B, jolloin se tyhjentää säievarastonsa eikä pysty palvelemaan muita pyyntöjä (vaikka ne eivät olisi palvelusta B). (Huom: Tarkempi kuvaus kuviosta löytyy esim. täällä.)

Jätän näiden mallien toteutustiedot pois, koska ne on helppo löytää virallinen dokumentaatio, ja haluan myös todella näyttää todennuksen ja valtuutuksen, joista keskustellaan artikkelin seuraavassa osassa.

PS kääntäjältä

Lue myös blogistamme:

• "Takaisin mikropalveluihin Istion kanssa": osa 1 (johdanto pääominaisuuksiin), osa 3 (todennus ja valtuutus);
• «Conduit - kevyt huoltoverkko Kubernetesille";
• «Mikä on palveluverkko ja miksi tarvitsen sitä [pilvisovellukselle, jossa on mikropalvelut]?'.

Lähde: will.com