Tagasi mikroteenustele koos Istio. Osa 1

Märkus tõlke kohta.: Service mesh on kindlasti muutunud olulise lahenduseks kaasaegses infrastruktuuris mikroteenuste arhitektuuriga rakenduste jaoks. Kuigi Istio on paljudele DevOps-inseneridele tuttav, on see üsna uus toode, mis, olles oma pakkumiste osas keeruline, võib vajada märkimisväärset aega tutvumiseks. Saksamaa insener Rinor Maloku, kes vastutab suuremate klientide pilvandmetöötluse eest telekommunikatsiooniettevõttes Orange Networks, on kirjutanud suurepärase artiklite tsükli, mis võimaldab kiiresti ja süvitsi süveneda Istiosse. Ta alustab oma juttu sellest, mida Istio üldse suudab ja kuidas seda saab kiiresti oma silmadega vaadata.

Istio — Avatud koodiga projekt, mille on välja töötanud Google'i, IBM-i ja Lyft'i meeskondade koostöös. See lahendab keerukusi, mis ilmnevad mikroteenustel põhinevates rakendustes, näiteks:

• Liikluse haldamine: ajaülesandeid, kordusi, koormuse tasakaalustamist;
• Turvalisus: lõppkasutaja autentimine ja autoriseerimine;
• Jälgitavus: jälgimine, monitooring, logimine.

Kõiki neid saab lahendada rakenduse tasandil, kuid pärast seda lakkavad teie teenused olemast "mikro". Kõik täiendavad pingutused nende probleemide lahendamiseks on ettevõtte jaoks lisakulud, mida oleks saanud kasutada otse äri väärtuste nimel. Vaatame näidet:

Projektijuht: Kui kaua võtab aega tagasiside võimaluse lisamine?
Arendaja: Kaks sprindi.

PJ: Mis?.. See on ju vaid CRUD!
A: CRUD'i tegemine on lihtne osa ülesandest, kuid meil on veel vaja autentida ja autoriseerida kasutajaid ja teenuseid. Kuna võrk ei ole usaldusväärne, on vaja rakendada kordusfunktsioone, samuti circuit breaker muster klientides. Samuti on vajalik, et kogu süsteem ei kukuks kokku, seetõttu on vajalikud ajaülesanded ja bulkheads (rohkem mõlema mainitud mustri kohta vt artikli lõpus - tõlkemärkus), ja probleemide tuvastamiseks on vajalikud monitooring, jälgimine, […]

PJ: Oh, lisame siis lihtsalt selle funktsiooni teenusesse Product.

Arvan, et idee on selge: sammude ja pingutuste hulk, mis on vajalik ühe teenuse lisamiseks, on tohutu. Selles artiklis vaatleme, kuidas Istio kõrvaldab kõik eespool mainitud keerukused (mis ei kuulu äri loogikasse) teenustes.

Märkus: Artikkel eeldab, et teil on praktilised teadmised Kubernetesest. Vastava juhul soovitan lugeda minu sissejuhatust Kubernetesesse ja alles seejärel jätkata selle materjali lugemist.

Istio idee

Kuberneteses ilma Istio-ta teeb üks teenus otse päringud teise teenuse juurde ning tõrke korral peab teenus ise selle käsitlema: esitama uue katse, pidama silmas ajapiirangut, avama circuit breaker ja nii edasi.

Võrgu liiklus Kuberneteses

Istio pakub spetsialiseeritud lahendust, mis on täielikult teenustest eraldatud ja toimib sekkumise kaudu võrgu suhtlusse. Seega teostab see:

• Talitluskatkestustunne: tuginedes vastuse olekukoode, mõistab see, kas päringus toimus tõrge ja sooritab selle uuesti.
• Kanarisüsteemide juurutamine: suunab ainult kindla protsendi päringutest uue teenuse versiooni.
• Jälgimine ja metoodika: kui kaua kulus teenusel vastamiseks?
• Jälitus ja nähtavus: lisab igale päringule spetsiaalsed päised ja jälgib neid klastris.
• Turvalisus: ekstraheerib JWT-tokeni, autentib ja volitab kasutajaid.

Need on vaid mõned võimalused (tõeliselt ainult mõned!), et teid huvitada. Nüüd sukeldume tehnilistesse detailidesse!

Istio arhitektuur

Istio haarab kogu võrgu liikluse ja rakendab sellele reeglite kogumi, sisestades igasse pod’i nutika proxy sidecar konteinerina. Proxyd, mis aktiveerivad kõik võimalused, moodustavad Andmeplaan, ja need saavad dünaamiliselt seadistuda Kontrollplaan.

Andmeplaan

Podidesse sisestatud proxyd võimaldavad Istio-l hõlpsasti saavutada meie nõuetele vastavust. Näiteks kontrollime korduskatsete ja circuit breaker'i funktsioone.

Kuidas on Envoy’s rakendatud korduskatseid ja circuit breaking’ut

Kokkuvõtteks:

1. Envoy (rääkides proxy-st, mis asub sidecar konteineris, mis levib ka nagu erinev toode — toimetaja märkus) saadetakse päring esimese teenuse B eksemplari juurde ja toimub tõrge.
2. Envoy Sidecar teeb uue katse (retry). (1)
3. Tõrkepäring naaseb selle esitanud proxy-le.
4. Nii avatakse Circuit Breaker ja toimub järgmise teenuse väljakutse järgnevate päringute jaoks. (2)

See, et tähendab, et teil ei pea olema teist Retry teeki, ei pea oma Circuit Breaking ja Service Discovery rakendust programmeerimiskeeles X, Y või Z tegema. Kõik see ja palju muud on saadaval Istios, ilma et oleks vaja muudatusi koodis.

Suurepärane! Nüüd võite soovida Istio seiklustele asuda, kuid teil on endiselt kahtlusi ja lahtisi küsimusi. Kui tegu on universaalse lahendusega igaks juhuks, tekib teil loogiline kahtlus: kõik sellised lahendused osutuvad tegelikult sobimatuks ükski olukord.

Ja lõpuks küsitakse: „Kas see on seadistatav?”

Nüüd olete valmis mereseikluseks — ja tutvume Control Plane'iga.

Kontrollplaan

See koosneb kolmest komponendist: Pilot, Mixer ja Citadel, — kes koos seavad Envoy'id marsruudi haldamiseks, rakendavad poliitikaid ja koguvad telemeetrilisi andmeid. Skeemiliselt näeb see kõik välja nii:

Control Plane'i ja Data Plane'i vaheline koostöö

Envoy'id (st data plane) on konfigureeritud Kubernetes CRD (Custom Resource Definitions), mis on määratletud Istios ja selleks otstarbeks loodud. See tähendab, et need esitatakse Kuberneteses teise ressursina tuttava süntaksiga. Pärast loomist tuvastatakse see ressurss control plane'i poolt ja rakendatakse Envoy'le.

Teenuste suhe Istiosse

Oleme kirjeldanud Istio suhet teenustega, kuid mitte vastupidi: kuidas teenused Istio suhtuvad?

Ausalt öeldes teavad teenused Istio olemasolust sama palju, kui kalad veest, kui nad küsivad endilt: „Mis asi on vesi?”

Illustreerimine Victoria Dimitrakopoulos: — Kuidas sulle vesi maitseb? — Mis asi on vesi?

Nii et saate võtta töötava klastri ja pärast Istio komponentide kasutuselevõttu jätkavad selles asuvad teenused töötamist, ja pärast nende komponentide eemaldamist on kõik jälle korras. Loomulikult kaotate nende eemaldamise korral Istio pakutavad võimalused.

Piisavalt teooriat — viigem see teadmine praktikasse!

Istio praktikas

Istio nõuab Kubernetes klastri, kus on vähemalt 4 vCPU ja 8 GB RAM-i. Kiireks klastri ülesseadmaks ja artiklis toodud juhiste järgimiseks soovitan kasutada Google Cloud Platformi, mis pakub uutele kasutajatele tasuta 300 dollarit.

Klastri loomise ja Kubernetes'i konsooli utiliidi kaudu juurdepääsu seadistamise järel saab Istio installida paketihalduri Helm kaudu.

Helmi installimine

Installige Helm klient oma arvutisse, nagu on kirjeldatud ametlikust dokumentatsioonist. Seda kasutame Istio installimiseks mustrite genereerimiseks järgmises jaotises.

Istio installimine

Laadige Istio ressursid alla viimastest väljalaskeversioonidest (originaalne autori link versioonile 1.0.5 on muudetud kehtivale, st 1.0.6 — tõlkija märkus), ekstraheerige sisu ühte kataloogi, mida edaspidi nimetame [istio-resources].

Ressursside lihtsaks tuvastamiseks looge K8s klastri nimevälja istio-system:

$ kubectl create namespace istio-system

Lõpetage installimine, liikudes katalooge [istio-resources] ja täites käsu:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

See käsk väljastab Istio põhikomponendid faili istio.yaml. Oleme muutnud standardset шаблона enda jaoks, määrates järgmised parameetrid:

• global.mtls.enabled seatud false (st mTLS autentimine on keelatud — tõlkija märkus), et lihtsustada meie tutvumist;
• tracing.enabled lülitab sisse päringute jälgimise Jaegeri abil;
• kiali.enabled paigaldab Kiali klastrisse teenuste ja liikluse visualiseerimiseks;
• grafana.enabled paigaldab Grafana kogutud mõõdikute visualiseerimiseks.

Kandke genereeritud ressursid käsu abil:

$ kubectl apply -f istio.yaml

Istio installimine klastrisse on lõpetatud! Oodake, kuni kõik pod’id nimeväljas istio-system on olekus Käimas või Completed, täites allolevat käsku:

$ kubectl get pods -n istio-system

Nüüd oleme valmis jätkama järgmises jaotises, kus tõstame ja käivitame rakenduse.

Sentiment Analysis rakenduse arhitektuur

Kasutaime Sentiment Analysis mikroteenuste rakenduse näidet, mida on kasutatud juba mainitud Kubernetes’i sissejuhatuses.See on piisavalt keeruline, et demonstreerida Istio võimalusi praktikas.

Rakendus koosneb neljast mikroteenusest:

1. Teenuseid SA-Frontend, mis teenindab rakenduse frontend'i Reactjs'is;
2. Teenuseid SA-WebApp, mis teenindab Sentiment Analysis päringuid;
3. Teenuseid SA-Logic, mis viib läbi iseseisva sentiment-analüüsi;;
4. Teenuseid SA-Feedback, mis saab kasutajatelt tagasisidet analüüsi täpsuse kohta.

Sellel skeemil näeme lisaks teenustele ka Ingress Controllerit, mis Kuberneteses suunab sissetulevad päringud vastavatele teenustele. Istios kasutatakse sarnast kontseptsiooni Ingress Gateway raames, mille üksikasjad järgivad.

Rakenduse käivitamine Istio proksi kaudu

Edasi liikudes, artiklis mainitud toimingute jaoks kloonige oma reposiit. istio-mastery. See sisaldab rakendust ja manifestide faile Kubernetes ja Istio jaoks.

Sidecaride sisestamine

Sisestamine võib toimuda automaatne või käsitsi. Automaatseks sidecar-mahutite lisamiseks tuleb määrata nimede ruumile silt istio-injection=enabled, mis toimub järgmise käsu abil:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Nüüd igas pod'is, mis käivitatakse vaikimisi nimede ruumis (Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist:) saab oma sidecar-mahuti. Selle kinnitamiseks paigaldame testrakenduse, minnes reposi juurkausta [istio-mastery] ja täidame järgmise käsu:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Teenuste juurutamisel kontrollime, et pod'id on kahe konteineriga (isegi teenuse ja selle sidecar'iga), täites käsu kubectl get pods ja veendumiseks, et 'READY' veerus näitab väärtust , mis tähistab, et mõlemad konteinerid on käivitatud: 2/2$ kubectl get pods NAME READY STATUS RESTARTS AGE sa-feedback-55f5dc4d9c-c9wfv 2/2 Running 0 12m sa-frontend-558f8986-hhkj9 2/2 Running 0 12m sa-logic-568498cb4d-2sjwj 2/2 Running 0 12m sa-logic-568498cb4d-p4f8c 2/2 Running 0 12m sa-web-app-599cf47c7c-s7cvd 2/2 Running 0 12m

Visuaalselt näeb see välja järgmiselt:

Envoy proksi ühes pod'is

Nüüd, kui rakendus on üles seatud ja töötab, peame lubama sissetuleva liikluse jõudmist rakendusse.

Ingress Gateway

Parim praktika selle saavutamiseks (lubada liiklus klustrites) on läbi

Istios, mis asub klustre piiril ja võimaldab sissetulevale liiklusele lubada selliseid Istio funktsioone nagu suunamine, koormuse tasakaalustamine, turvalisus ja jälgimine. Parim praktika selle saavutamiseks (lubada liiklus klustrites) on läbi Ingress Gateway komponent ja teenus, mis suunab selle väljapoole, paigaldati klastrisse Istio installimise käigus. Välimise teenuse IP-aadressi teada saamiseks täitke:

Ingress Gateway komponent ja teenus, mis suunab selle väljapoole, paigaldati klastrisse Istio installimise ajal. Välist teenuse IP-aadressi leidmiseks tehke järgmist:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Me kasutame seda IP-aadressi rakenduse jaoks edasi (ma viitan sellele kui EXTERNAL-IP), seega salvestame selle mugavuse huvides muutujasse:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Kui proovite hetkel sellele IP-le brauseris minna, siis saate teenuse kättesaamatusest teatava vea, kuna vaikimisi blokib Istio kogu siseneva liikluse, kuni Gateway on määratletud.

Gateway ressurs

Gateway on CRD (Custom Resource Definition) Kuberneteses, mis määratletakse pärast Istio paigaldamist klastrisse ja aktiveerib võimaluse määrata pordid, protokoll ja hostid, millele soovime siseneva liikluse lubada.

Meie juhtumil soovime lubada HTTP-liiklust 80. pordil kõigi hostide jaoks. Ülesanne rakendatakse järgmise määratlemise kaudu (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

Selline konfiguratsioon ei vaja selgitusi, välja arvatud selektor istio: ingressgateway. Selle selektori kaudu saame määrata, millisele Ingress Gateway'le rakendada konfiguratsiooni. Meie juhtumil on see Ingress Gateway'i kontroller, mis oli vaikimisi paigaldatud Istiosse.

Konfiguratsioon rakendatakse järgmist käsku kutsudes:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Nüüd lubab gateway juurdepääsu 80. pordile, kuid ei tea, kuhu päringuid suunata. Selleks on vajalikud Virtuaalsed teenused.

VirtualService ressurs

VirtualService määrab, kuidas Ingress Gateway suunab lubatud päringud klastris.

Meie rakendusele suunatud päringud, mis tulevad http-gateway kaudu, peavad minema teenustesse sa-frontend, sa-web-app ja sa-feedback:

Marsruudid, mida tuleb VirtualServices'iga seadistada

Vaadakem päringuid, mis peavad olema suunatud SA-Frontendile:

• Täpne vastavus teele / peab olema suunatud SA-Frontendile index.html-i saamiseks;
• Teed, millel on prefiks /static/* peavad olema suunatud SA-Frontendile staatiliste failide, nagu CSS ja JavaScript, saamiseks;
• Teed, mis vastavad regulaaravaldusele '^.*.(ico|png|jpg)$', peavad olema suunatud SA-Frontendile, kuna need on lehelt kuvatavad pildid.

Rakendamine saavutatakse järgmise konfiguratsiooni kaudu (sa-virtualservice-external.yaml):

tüüp: VirtualService
metaandmed:
  nimi: sa-external-services
spetsifikatsioon:
  peremehed:
  - "*"
  väravad:
  - http-gateway                      # 1
  http:
  - vastav:
    - uri:
        täpselt: \/
    - uri:
        täpselt: \/callback
    - uri:
        prefiks: \/static
    - uri:
        regex: '^.*.(ico|png|jpg)

Olulised punktid:



 	
 See VirtualService käsitleb päringuid, mis saabuvad kaudu http-gateway;


 	
 Uues sihtkoht määratakse teenus, kuhu saadetakse päringud.




Märkus: Ülaltoodud konfiguratsioon salvestatakse faili sa-virtualservice-external.yaml, mis sisaldab ka seadistusi SA-WebApp ja SA-Feedbacki marsruutimise jaoks, kuid on siinses artiklis lühendatud selguse huvides.

Kasutame VirtualService'i kutset:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services loodud
Märkus: Kui rakendame Istio ressursse, loob Kubernetes API Server sündmuse, mille saab Istio kontrolli tasand, ja alles pärast seda rakendatakse uus konfiguratsioon iga poodi Envoy'i vahetusse. Ja Ingress Gateway kontroller esindab järgmist Envoy'd, mis on konfigureeritud kontrolli tasandil. Kõik see näeb välja järgmine:

 Istio-IngressGateway konfiguratsioon päringute marsruutimiseks
Sentiment Analysis rakendus on kättesaadav aadressil http://{EXTERNAL-IP}/. Ärge muretsege, kui saate staatuse Not Found: mõnikord kulub külgetõmmete kehtestamiseks ja Envoy'i vahemälu värskendamiseks veidi rohkem aega.
Enne edasi liikumist töötage rakendusega natuke, et genereerida liiklust (selle olemasolu on vajalik edasiste tegevuste selguse huvides — toimetaja märkus).
Kiali: nähtavus
Juurdepääsuks Kiali halduskeskkonnale käivitage järgmine käsk:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… ja avage http://localhost:20001/, sisse logides kasutajanimega admin/admin. Siit leiate hulgaliselt kasulikke funktsioone, näiteks Istio komponentide konfiguratsiooni kontrollimise, teenuste visualiseerimise võrgu päringute katkestatud teabe põhjal, vastates küsimustele „Kes kellega räägib?”, „Millise teenuse versiooniga esinevad tõrked?” ja nii edasi. Üldiselt uurige Kiali võimalusi, enne kui liigute edasi — metrikate visualiseerimise juurde Grafanas.
Grafana: metrikate visualiseerimine
Istios kogutud meetrikad saadetakse Prometheusele ja visualiseeritakse Grafana abil. Juurdepääsuks Grafana halduskeskkonnale käivitage allolev käsk, seejärel avage http://localhost:3000/:
$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000
Klõpsake menüüd Home vasakul üleval ja valige Istio Service Dashboard vasakus ülanurgas, alustades teenusest sa-web-app, et vaadata kogutud meetrikaid:
Siin ootab meid tühi ja täiesti igav esitus — juhend kunagi ei aktsepteeri sellist. Loome väikese koormuse järgmise käsuga:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Nüüd on meil palju ilusamad graafikud ja lisaks neile - suurepärased tööriistad Prometheus jälgimiseks ja Grafana mõõdikute visualiseerimiseks, mis aitavad meil mõista teenuste tulemuslikkust, terviseseisundit, parandusi/degradaatsiooni aja jooksul.
Lõpuks vaatame teenuste päringute jälgimist.
Jaeger: jälgimine
Jälgimine on vajalik, kuna mida rohkem meil on teenuseid, seda keerulisem on leida vea põhjust. Vaadakem lihtsat juhtumit alltoodud pildilt:

 Tüüpiline näide juhuslikust ebaõnnestunud päringust
Päring tuleb, kukub kokku - mis on siis põhjus? Esimene teenus? Või teine? Mõlemas on erandid - vaatame igaühe logisid. Kui sageli olete end sellise tegevuse pealt tabanud? Meie töö sarnaneb rohkem tarkvaradelefonistide tööle kui arendajate omale...
See on laialdaselt levinud probleem mikroteenustes ja see lahendatakse levitatud süsteemide jälgimisega, kus teenused edastavad üksteisele ainulaadse pealkirja, mida seejärel suunatakse jälgimissüsteemi, kus see seostatakse päringute andmetega. Siin on illustratsioon:

 Päringu identifitseerimiseks kasutatakse TraceId
Istios kasutatakse Jaeger Traceri, mis rakendab tarnijast sõltumatut OpenTracing API raamistikku. Juhtimiseks jaotuse kasutajaliidesele pääsemiseks tehke järgmine käsk:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Nüüd minge aadressile http://localhost:16686/ ja valige teenus sa-web-app. Kui teenust ei kuvata rippmenüüs - genereerige tegevust leheküljel ja värskendage liidest. Pärast seda klõpsake nuppu Find Traces, mis näitab viimaseid jälgimisi - valige ükskõik milline - näha saab detailset teavet kõigi jälgimiste kohta:
See jälgimine näitab:
 
 Päring tuleb istio-ingressgateway (see on esimene kokkupuude ühe teenusega ja päringu jaoks genereeritakse Trace ID), pärast mida suunab värav päringu teenusesse sa-web-app.
 
 Teenuses sa-web-app haarab päringu Envoy sidecar, luuakse "laps" spanis (seetõttu näeme seda jälgimistes) ja suunatakse konteinerisse sa-web-app. (Span — loogiline tööüksus Jaeger'is, millel on nimi, töö alguse aeg ja selle kestus. Span'id võivad olla sissetoodud ja järjestatud. Suunatud tsükliline graaf span'idest moodustab trace. — märg. tõlk.)
 
 Siin töödeldakse taotlust meetodi abil sentimentAnalysis. Need jäljed on juba genereeritud rakenduse poolt, st nende jaoks olid vajalikud muudatused koodis.
 
 Sellest hetkest algatatakse POST-päring sa-logic. Trace ID peab olema edastatud sa-web-app.
 
 …
Märkus: 4. sammul peab rakendus nägema Istio genereeritud päiseid ja edastama need järgmistele päringutele, nagu on näidatud alloleval pildil:

 (A) Peaeesed edastab Istio; (B) Päidete eest vastutavad teenused
Istio teeb peamise töö, kuna genereerib päidete sissetulevate päringute jaoks, loob igas sidecare'is uusi span'e ja edastab need. Kuid ilma teenustes päidete käsitlemiseta kaob päringu jälgimise täies ulatuses.
Oluline on arvestada (edastada) järgmisi päidete:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
See ei ole keeruline ülesanne, kuid selle teostamise lihtsustamiseks on juba olemas rohkelt teeke — näiteks, rakenduses sa-web-app edastab klient RestTemplate need päid, kui lisada lihtsalt teegid Jaeger ja OpenTracing oma sõltuvustesse.
Pange tähele, et rakendus Sentiment Analysis demonstreerib teostusi Flaskis, Springis ja ASP.NET Core'is.
Nüüd, kui on selge, mida me saame otse välja pakutuna (või peaaegu "otse välja pakutuna"), vaatame tähelepanelikult küsimusi, mis puudutavad peenhäälestatud marsruutimist, võrgu liikluse haldamist, turvalisust jne!
Märkus tõlke kohta.: seda loe järgmise osa materjalidest Istio kohta, autor Rinor Maloku, mille tõlked järgnevad meie blogis varsti. UPDATE (14. märts): Teine osa on juba avaldatud.
P.S. tõlkijalt
Lugege ka meie blogist:
 
 "Tagasi mikroteenustele koos Istio": osa 2 (marsruutimine, liikluse haldamine), osa 3 (autentimine ja autoriseerimine);
 
 «Conduit — kerge service mesh Kubernetes'ile»;
 
 «Mis on service mesh ja miks on see mulle vajalik [pilveäppi mikroteenuste jaoks]?»;
 
 «Illustreeritud juhend võrgu seadistamise kohta Kuberneteses. Osad 1 ja 2»;
 
 «Kuidas see sidecar-konteiner siia sattus [Kuberneteses]?».
Allikas: habr.com
marsruut:
 - sihtkoht:
 host: sa-frontend             # 2
 port:
 number: 80
 Olulised punktid:
 
 See VirtualService käsitleb päringuid, mis saabuvad kaudu http-gateway;
 
 Uues sihtkoht määratakse teenus, kuhu saadetakse päringud.
Märkus: Ülaltoodud konfiguratsioon salvestatakse faili sa-virtualservice-external.yaml, mis sisaldab ka seadistusi SA-WebApp ja SA-Feedback marsruutimiseks, kuid on artiklis kokkuvõetud lühiduse huvides.
Rakendame VirtualService kutsumisega:
Märkus: Kui me rakendame Istio ressursse, loob Kubernetes API Server sündmuse, mille saab Istio Control Plane, ja alles seejärel rakendatakse uus konfiguratsioon iga podi Envoy-proksiserveritesse. Ja Ingress Gateway kontroller esindab järgmist Envoy’d, mis on konfigureeritud Control Plane'is. Kõik see näeb skeemil välja nii:

 Istio-IngressGateway konfiguratsioon päringute marsruutimiseks
Sentiment Analysis rakendus on kättesaadav aadressil http://{EXTERNAL-IP}/. Ärge muretsege, kui saate staatuse Not Found: mõnikord kulub külgetõmmete kehtestamiseks ja Envoy'i vahemälu värskendamiseks veidi rohkem aega.
Enne edasi liikumist töötage rakendusega natuke, et genereerida liiklust (selle olemasolu on vajalik edasiste tegevuste selguse huvides — toimetaja märkus).
Kiali: nähtavus
Juurdepääsuks Kiali halduskeskkonnale käivitage järgmine käsk:
… ja avage http://localhost:20001/, sisse logides kasutajanimega admin/admin. Siit leiate hulgaliselt kasulikke funktsioone, näiteks Istio komponentide konfiguratsiooni kontrollimise, teenuste visualiseerimise võrgu päringute katkestatud teabe põhjal, vastates küsimustele „Kes kellega räägib?”, „Millise teenuse versiooniga esinevad tõrked?” ja nii edasi. Üldiselt uurige Kiali võimalusi, enne kui liigute edasi — metrikate visualiseerimise juurde Grafanas.
Grafana: metrikate visualiseerimine
Istios kogutud meetrikad saadetakse Prometheusele ja visualiseeritakse Grafana abil. Juurdepääsuks Grafana halduskeskkonnale käivitage allolev käsk, seejärel avage http://localhost:3000/:
Klõpsake menüüd Home vasakul üleval ja valige Istio Service Dashboard vasakus ülanurgas, alustades teenusest sa-web-app, et vaadata kogutud meetrikaid:
Siin ootab meid tühi ja täiesti igav esitus — juhend kunagi ei aktsepteeri sellist. Loome väikese koormuse järgmise käsuga:
Nüüd on meil palju ilusamad graafikud ja lisaks neile - suurepärased tööriistad Prometheus jälgimiseks ja Grafana mõõdikute visualiseerimiseks, mis aitavad meil mõista teenuste tulemuslikkust, terviseseisundit, parandusi/degradaatsiooni aja jooksul.
Lõpuks vaatame teenuste päringute jälgimist.
Jaeger: jälgimine
Jälgimine on vajalik, kuna mida rohkem meil on teenuseid, seda keerulisem on leida vea põhjust. Vaadakem lihtsat juhtumit alltoodud pildilt:

 Tüüpiline näide juhuslikust ebaõnnestunud päringust
Päring tuleb, kukub kokku - mis on siis põhjus? Esimene teenus? Või teine? Mõlemas on erandid - vaatame igaühe logisid. Kui sageli olete end sellise tegevuse pealt tabanud? Meie töö sarnaneb rohkem tarkvaradelefonistide tööle kui arendajate omale...
See on laialdaselt levinud probleem mikroteenustes ja see lahendatakse levitatud süsteemide jälgimisega, kus teenused edastavad üksteisele ainulaadse pealkirja, mida seejärel suunatakse jälgimissüsteemi, kus see seostatakse päringute andmetega. Siin on illustratsioon:

 Päringu identifitseerimiseks kasutatakse TraceId
Istios kasutatakse Jaeger Traceri, mis rakendab tarnijast sõltumatut OpenTracing API raamistikku. Juhtimiseks jaotuse kasutajaliidesele pääsemiseks tehke järgmine käsk:
Nüüd minge aadressile http://localhost:16686/ ja valige teenus sa-web-app. Kui teenust ei kuvata rippmenüüs - genereerige tegevust leheküljel ja värskendage liidest. Pärast seda klõpsake nuppu Find Traces, mis näitab viimaseid jälgimisi - valige ükskõik milline - näha saab detailset teavet kõigi jälgimiste kohta:
See jälgimine näitab:
 
 Päring tuleb istio-ingressgateway (see on esimene kokkupuude ühe teenusega ja päringu jaoks genereeritakse Trace ID), pärast mida suunab värav päringu teenusesse sa-web-app.
 
 Teenuses sa-web-app päringut püüab kinni Envoy sidecar, luuakse «lapse» span (seetõttu me näeme seda jälgedes) ja suunatakse konteinerisse sa-web-app. (Span — loogiline tööüksus Jaegeris, millel on nimi, operatsiooni alguse aeg ja selle kestus. Span'id võivad olla pesakonnaks ja järjestatud. Suunatud mitte-tsükliline graaf span'idest moodustab jälje. — seisukoht tõlkijale)
 
 Siin töödeldakse taotlust meetodi abil sentimentAnalysis. Need jäljed on juba genereeritud rakenduse poolt, st nende jaoks olid vajalikud muudatused koodis.
 
 Sellest hetkest algatatakse POST-päring sa-logic. Trace ID peab olema edastatud sa-web-app.
 
 …
Märkus: 4. sammul peab rakendus nägema Istio genereeritud päiseid ja edastama need järgmistele päringutele, nagu on näidatud alloleval pildil:

 (A) Peaeesed edastab Istio; (B) Päidete eest vastutavad teenused
Istio teeb põhiosa tööst, kuna see genereerib sissetulevate päringute jaoks päiseid, loob uusi span'e igas sidecar'is ja edastab need edasi. Siiski, kui teenustes peadega ei töötata, siis päringu jälgimise täispikkus kaob.
Oluline on arvestada (edastada) järgmisi päidete:
See ei ole keeruline ülesanne, kuid selle teostamise lihtsustamiseks on juba olemas rohkelt teeke — näiteks, rakenduses sa-web-app edastab klient RestTemplate need päid, kui lisada lihtsalt teegid Jaeger ja OpenTracing oma sõltuvustesse.
Pange tähele, et rakendus Sentiment Analysis demonstreerib teostusi Flaskis, Springis ja ASP.NET Core'is.
Nüüd, kui on selge, mida me saame otse välja pakutuna (või peaaegu "otse välja pakutuna"), vaatame tähelepanelikult küsimusi, mis puudutavad peenhäälestatud marsruutimist, võrgu liikluse haldamist, turvalisust jne!
Märkus tõlke kohta.: seda loe järgmise osa materjalidest Istio kohta, autor Rinor Maloku, mille tõlked järgnevad meie blogis varsti. UPDATE (14. märts): Teine osa on juba avaldatud.
P.S. tõlkijalt
Lugege ka meie blogist:
 

• "Tagasi mikroteenustele koos Istio": osa 2 (marsruutimine, liikluse haldamine), osa 3 (autentimine ja autoriseerimine);
• «Conduit — kerge service mesh Kubernetes'ile»;
• «Mis on service mesh ja miks on see mulle vajalik [pilveäppi mikroteenuste jaoks]?»;
• «Illustreeritud juhend võrgu seadistamise kohta Kuberneteses. Osad 1 ja 2»;
• «Kuidas see sidecar-konteiner siia sattus [Kuberneteses]?».

Allikas: habr.com