Tagasi mikroteenuste juurde koos Istio. Osa 1

Märk. tõlge.: Teenusvõrgud on kindlasti muutumas vajalikuks lahenduseks tänapäevases infrastruktuuris, millel on mikroteenuste arhitektuuriga rakendused. Kuigi Istio võib paljudele DevOps-inseneridele tuttav olla, on see üsna uus toode, mis oma pakutavate funktsioonide osas võib nõuda märkimisväärset aega tutvumiseks. Saksa insener Rinor Maloku, kes vastutab suurklientide pilvandmetöötluse eest telekommunikatsiooniettevõttes Orange Networks, on kirjutanud suurepärase artiklite seeria, mis võimaldab piisavalt kiiresti ja sügavalt Istiosse süveneda. Ta alustab oma juttu sellest, mida Istio üldse oskab ja kuidas seda saab kiiresti oma silmaga näha.

Istio — Open Source projekt, mille on välja töötanud Google'i, IBM-i ja Lyfti meeskondade koostöös. See lahendab mikroteenustel põhinevates rakendustes esinevaid keerukusi, näiteks:

• Liiklustugevdus: ajakavad, uuesti proovimise mehhanismid, koormuse tasakaalustamine;
• Ohutus: lõppkasutaja autentimine ja autoriseerimine;
• Jälgimine: jälgimine, monitooring, logimine.

Needless to say, all these issues can be resolved at the application level, but doing so will turn your services into something more than 'micro'. All extra efforts to address these problems represent wasted resources that could otherwise be directly used for business value. Let’s consider an example:

Project Manager: How long does it take to add feedback functionality?
Developer: Two sprints.

PM: What?.. It’s just CRUD!
Dev: Implementing CRUD is the easy part of the task, but we also need to authenticate and authorize users and services. Given the unreliability of the network, we will need to implement retries as well as the circuit breaker pattern in the clients. Furthermore, to ensure that the entire system doesn't crash, we will require timeouts and bulkheads (for more on both mentioned patterns, see further in the article — editor's note), and to detect issues, we will need monitoring, tracing, […]

PM: Oh, then let’s just add this feature to the Product service.

Mõte on selge: ühe teenuse lisamiseks vajalik töö maht ja pingutused on tohutud. Selles artiklis vaatleme, kuidas Istio kõrvaldab kõik eelpool mainitud keerukused (mis ei ole suunatud äriloogikale) teenustest.

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

Istio mõte

Ilma Istio-ta teeb üks teenus otsepäringuid teisele, ja vea korral peab teenus ise selle käsitlema: korraldama uue katse, ette nägema ajapiiri, avama circuit breaker jne.

Võrguliiklus Kuberneteses

Istio pakub aga spetsialiseeritud lahendust, mis on täielikult teenustest eraldatud ja toimib sekkumise kaudu võrgusuhtluses. Ja seega rakendab see:

• Katastroofitaluvus: tuginedes vastuse staatusele, mõistab see, kas päringus tekkis tõrge, ja kordab seda.
• Kanari väljalasked.: suunab vaid kindla protsendi päringutest uuele teenuse versioonile.
• Jälgimine ja mõõdikud: kui kaua võttis teenusel vastamine aega?
• Jälgimine ja nähtavus: lisab spetsiifilisi päiseid iga päringu juurde ja jälgib neid klastris.
• Ohutus: ekstraktib JWT-märgis, autentib ja volitab kasutajaid.

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

Istio arhitektuur

Istio püüab kogu võrguliiklust ja rakendab sellele reeglite kogumi, sisestades igasse pod'i nutika proksi sidecar-konteinerina. Proksid, mis aktiveerivad kõik funktsioonid, moodustavad Andmeplaneet, ja need saavad dünaamiliselt seadistuda Kontrolli küngas.

Andmeplaneet

Pod'i sisestatud proksid võimaldavad Istio'l hõlpsasti saavutada vajalikku vastavust. Näiteks vaatame kordamise ja ringluse katkestamise funktsioone.

Kuidas on retries ja circuit breaking rakendatud Envoy's

Kokkuvõttes:

1. Envoy (rääkides proksist, mis asub sidecar-konteineris, mis levib ja nagu eraldi toode — kt. tõlge) saadab päringu esimesele teenuse B eksemplarile ja ilmneb rike.
2. Envoy Sidecar püüab uuesti (retry). (1)
3. Viga saanud päring tagastatakse selle kutsunud proksile.
4. Nii avatakse Circuit Breaker ja kutsutakse üles järgmine teenus edasiste päringute jaoks. (2)

See tähendab, et teil ei pea olema vaja kasutada uut Retry teeki, ei pea looma oma rakendust Circuit Breaking ja Service Discovery programmeerimiskeeles X, Y või Z. Kõik see ja palju muud on Istios juba kasutamiseks valmis ning ei vaja mingeid muudatusi koodis.

Suurepärane! Nüüd võite soovida seigelda Istio'ga, kuid teil on ikka veel mõned kahtlused ja avatud küsimused. Kui see on universaalne lahendus igaks juhuks, tekib teil põhjendatud kahtlus: kõik sellised lahendused osutuvad tegelikult sobimatuks ükskõik millise olukorra jaoks.

Ja lõpuks küsite: „Kas see on kohandatav?”

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

Kontrolli küngas

See koosneb kolmest komponendist: Pilot, Mixer ja Citadel, — mis koos tõendavad Envoy'ide seadistamist liikluse suunamiseks, rakendavad poliitikaid ja koguvad telemeetriandmeid. Skeemiliselt näeb see välja nii:

Control Plane'i ja Data Plane'i interaktsioon

Envoy'id (st data plane) on konfigureeritud Kubernetes CRD (Custom Resource Definitions), mis on määratletud Istio poolt ja spetsiaalselt selleks eesmärgiks. See tähendab, et need esindavad Kuberneteses tuttava süntaksiga ressurssi. Pärast loomist need ressursid valitakse kontrollplaneedi poolt ja rakendatakse Envoy'dele.

Teenuste seosed Istio'ga

Oleme kirjeldanud Istio suhet teenustega, kuid mitte vastupidi: kuidas teenused Istio'le vaatavad?

Tegelikult teavad teenused Istio olemasolust sama hästi, kui kalad teavad vett, kui nad küsivad endalt: 'Mis see vesi üldse on?'.

Illustratsioon Victoria Dimitrakopoulos: — Kuidas sulle vesi maitseb? — Mis see vesi üldse on?

Seega saate võtta töötava klastriga ja pärast Istio komponentide juurutamist jätkavad teenused seal oma tööd ning pärast nende komponentide eemaldamist on kõik jälle korras. Loomulikult kaotate sellega aga Istio pakutavad võimalused.

Piisavalt teooriat — viidame selle teadmise praktikas ellu!

Istio praktikas

Istio vajab Kubernetes klastri, milles on vähemalt saadaval 4 vCPU ja 8 GB RAM. Klastri kiireks seadistamiseks ja artiklis toodud juhiste järgimiseks soovitan kasutada Google Cloud Platform'i, mis pakub uutele kasutajatele tasuta $300.

Pärast klastri loomist ja juurdepääsu seadistamist Kubernetes'ile käsurea tööriista kaudu saate installida Istio pakihalduri Helm abil.

Helmi installimine

Installige Helm klient oma arvutisse, nagu on kirjeldatud ametlikus dokumentatsioonis. Seda kasutame Istio installimise mallide genereerimiseks järgmiseks osaks.

Istio paigaldamine

Laadige Istio ressursid alla viimase väljaande (originaali autori link versioonile 1.0.5 on muudetud kehtivaks, s.t. 1.0.6 — toim. tõlk.), ekstraktige sisu ühte kausta, mida nimetame edaspidi [istio-resources].

Lihtsaks Istio ressursside tuvastamiseks looge K8s klastri nimespatsioon istio-system:

$ kubectl create namespace istio-system

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

$ 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 genereerib Istio võtmekomponendid faili istio.yaml. Oleme kohandanud vaikimisi templati enda tarbeks, määrates järgmised parameetrid:

• global.mtls.enabled seatud väärtuseks false (st mTLS autentimine on keelatud — vt selgitust.), et lihtsustada meie tutvumise protsessi;
• tracing.enabled lubab päringute jälgimise Jaegeri abil;
• kiali.enabled paigaldab Kiali klastrisse teenuste ja liikluse visualiseerimiseks;
• grafana.enabled paigaldab Grafana kogutud metrikate visualiseerimiseks.

Kohandatud ressursid kehtib meeskonna poolt:

$ kubectl apply -f istio.yaml

Istio paigaldamine klastrisse on lõpetatud! Oodake, kuni kõik pod'id nimede ruumis istio-system on seisundis Running või Täidetud, käivitades alloleva käsu:

$ kubectl get pods -n istio-system

Nüüd oleme valmis liikuma järgmisse sektsiooni, kus tõstame ja käivitame rakenduse.

Sentiment Analysis rakenduse arhitektuur

Kasutame Sentiment Analysis mikroteenuste rakenduse näidet, mis on juba mainitud Kubernetesesse tutvustavas artiklis.See on piisavalt keeruline, et näidata Istio võimekust praktikas.

Rakendus koosneb neljast mikroteenusest:

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

Selles skeemis näeme peale teenuste ka Ingress Controller'it, mis Kubernetes'is suunab sissetulevad päringud vastavatele teenustele. Istios kasutatakse sarnast kontsepti Ingress Gateway raames, mille kohta järgneb täiendav teave.

Rakenduse käivitamine Istio proksi kaudu

Edasi liikuda, nagu artiklis mainitud, kloonige repository enda jaoks istio-mastery. See sisaldab rakendust ja mánifeste Kubernetes'i ja Istio jaoks.

Sidecar'ide sisestamine

Sisestamine võib toimuda automaatselt või käsi. Automaatseks sidecar-konteinerite sisestamiseks tuleb nimede ruumile seada silt istio-injection=enabled, mis toimub järgmise käsu abil:

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

Nüüd saab iga pod, mis tõstetakse üles vaikimisi nimede ruumis (default) oma sidecar-konteineri. Selle kinnitamiseks, deploy'ime testrakenduse, liikudes repository juurkausta [istio-mastery] ja käivitades 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 käivitamisel kontrollime, et pod'ides oleks kaks konteinerit (teenus ja selle sidecar), kasutades käsku kubectl get pods ja veendudes, et veeru READY all on väärtus 2/2, mis näitab, et mõlemad konteinerid on käivitunud:

$ 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 tundub see järgmiselt:

Envoy proks üksikutes pod'ides

Kuna rakendus on nüüd käivitatud ja töötab, peame lubama sissetuleval liiklusel rakendusse jõuda.

Ingress Gateway

Parim praktika selle saavutamiseks (lubada liiklus klastrisse) — kasutades Ingress Gateway Istios, mis asub klastripiiril ja võimaldab sissetulevale liiklusele võimaldada selliseid Istio funktsioone nagu marsruutimine, koormuse tasakaalustamine, turvalisus ja jälgimine.

Ingress Gateway komponent ja teenus, mis edastab selle väljas poole, paigaldati klastrisse Istio installatsiooni käigus. Et leida teenuse välist IP-aadressi, täitke:

$ 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 pöördume rakenduse poole selle IP-aadressi kaudu ja hiljem (ma viitan sellele kui EXTERNAL-IP), seega mugavuse huvides salvestame väärtuse muutujasse:

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

Kui proovite selle IP-aadressi kaudu brauserisse siseneda, saate vea Service Unavailable, kuna vaikimisi Istio blokeerib kogu siseneva liikluse, kuni ei ole määratud Gateway.

Gateway ressurss

Gateway on CRD (Custom Resource Definition) Kuberneteses, mis määratakse pärast Istio installimist klastrisse ja aktiveerib võimaluse määrata sadamad, protokoll ja hostid, mille jaoks soovime lubada sisenevat liiklust.

Meie puhul soovime lubada HTTP-liiklust 80. sadamasse kõigi hostide jaoks. Ülesanne viiakse ellu järgmise määratlemisega (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:
- "*"

See konfiguratsioon ei vaja selgitusi, välja arvatud selektori kohta. istio: ingressgateway. Selle selektori abil saame juhendada, millisele Ingress Gateway'le konfiguratsioon rakendatakse. Meie juhul on see Istios vaikimisi installitud Ingress Gateway'i kontroller.

Konfiguratsioon rakendatakse järgmise käsu abil:

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

Nüüd lubab värav juurdepääsu pordile 80, kuid ei tea, kuhu suunata päringud. Selleks on vaja Virtual Services.

VirtualService ressurss

VirtualService juhendab Ingress Gateway'd, kuidas suunata päringuid, mis on lubatud klastris.

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

Marsruudid, mida tuleb seadistada VirtualServices

Vaatame päringuid, mis peaksid minema SA-Frontend'ile:

• Täpne sobivus tee järgi / peab saatma SA-Frontend'ile, et saada index.html;
• Tee eelneva prefiksiga /static/* peavad minema SA-Frontend'i staatiliste failide saamiseks, mida kasutatakse esiküljel, nagu CSS ja JavaScript;
• Teed, mis vastavad regulaaravaldistele '^.*\.(ico|png|jpg)$', peavad minema SA-Frontend'i, kuna need on lehelt kuvatavad pildid.

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

tüüp: VirtualService
meta:
  nimi: sa-external-services
spec:
  hostid:
  - "*"
  väravad:
  - http-gateway                      # 1
  http:
  - vasta:
    - uri:
        täpselt: /
    - uri:
        täpselt: /callback
    - uri:
        eelline: /static
    - uri:
        regex: '^.*.(ico|png|jpg)

Olulised punktid:



 	
 See VirtualService kehtib päringutele, mis tulevad http-gateway;


 	
 V destination määratleb teenuse, kuhu päringud saadetakse.




Märkus: Ülaltoodud konfiguratsioon on salvestatud faili sa-virtualservice-external.yaml, mis sisaldab ka seadistusi SA-WebApp ja SA-Feedback suunamiseks, kuid on siin artiklis lühendatud kokkuvõtte huvides.

Rakendame VirtualService'i käsu:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services loodud
Märkus: Kui rakendame Istio ressursid, loob Kubernetes API Server sündmuse, mille saab Istio Control Plane, ja alles seejärel rakendatakse uus konfiguratsioon iga podi Envoy vahetusse. Ja Ingress Gateway kontroller esindab veel ühte Envoy'd, mis on konfigureeritud Control Plane'is. Kogu see skeem näeb välja selline:

 Istio-IngressGateway konfiguratsioon päringute suunamiseks
Sentiment Analysis rakendus on saadaval aadressil http://{EXTERNAL-IP}/. Ärge muretsege, kui saate staatuse Not Found: kasutamiseks võib olla vajalik veidi rohkem aega, et seadistuse jõustumine toimuks ja Envoy vahemälu uuendataks.
Enne jätkamist töötage rakendusega, et genereerida liiklust (see on vajalik järgmiste toimingute selguse tagamiseks — toimetuse märkus).
Kiali: jälgimine
Kiali administratiivliidesele jõudmiseks täitke 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/, logige sisse admin/admin. Siit leiate palju kasulikke võimalusi, näiteks Istio komponentide seadistuse kontrollimiseks, teenuste visualiseerimiseks kogutud teabe alusel, vastamiseks küsimustele "Kes kellega suhtleb?", "Millise teenuse versiooniga tekivad probleemid?" jne. Uurige Kiali võimalusi enne edasiviimist — suunduge metrikate visualiseerimise juurde Grafana.
Grafana: metrikate visualiseerimine
Istios kogutud metrikad jõuavad Prometheusesse ja visualiseeritakse Grafanas. Juurdepääsemiseks Grafana administratiivliidesele täitke 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
Kliki vasakult ülanurgast menüüd Avaleht ja vali Istio teenuse armatuurlaud vasakus ülanurgas, alusta teenusest sa-web-app, et vaadata kogutud mõõdikuid:
Siin ootab meid tühi ja täiesti igav esitlus — juhend kunagi midagi sellist ei kiidaks. Loome nüüd kerge 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 ning lisaks neile on meil fantastilised Prometheuse tööriistad jälgimiseks ja Grafana mõõdiku visualiseerimiseks, mis aitavad meil jälgida teenuste toimivust, terviseseisundit, parandusi/degradatsiooni ajas.
Lõpuks vaatame teenuste päringute jälgimist.
Jaeger : jälgimine
Jälgimine on vajalik, sest mida rohkem meil on teenuseid, seda keerulisem on põhjuse leidmine. Vaatame lihtsat juhtumit allolevast pildist:

 Tüüpiline näide juhuslikust ebaõnnestunud päringust
Päring tuleb, kukub — mis on põhjus? Esimene teenus? Või teine? Mõningad erandid on mõlemas — vaatame igaühe logisid. Kui tihti olete end sellise tegevuse juures tabanud? Meie töö sarnaneb rohkem tarkvara detektiivide omaga kui arendajatega…
See on laialdaselt levinud probleem mikroteenustes ning lahendatakse jagatud süsteemide jälgimisega, kus teenused edastavad üksteisele unikaalse päise, mille järel see teave suunatakse jälgimisse süsteemi, kus see seostatakse päringu andmetega. Siin on illustreeriv joonis:

 Päringu identifitseerimiseks kasutatakse TraceId
Istios kasutatakse Jaeger Tracerit, mis rakendab tootjast sõltumatut raamistikku OpenTracing API. Juhtige kasutajaliidese juurde järgnevate käsureade abil:
$ 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 teenus ei ole avanevas menüüs näha — pange lehelt tegevust või genereerige tegevus ja värskendage liidest. Pärast seda vajutage nuppu Find Traces, mis näitab uusimaid jälgi — valige ükskõik milline — kuvatakse kõigi jälgede üksikasjalik teave:
See jälgib:
 
 Päring jõuab istio-ingressgateway (see on esimene suhtlemine ühe teenusega ja päringu jaoks genereeritakse jälgimise ID), pärast mida suunab värav päringu teenusesse sa-web-app.
 
 Teenuses sa-web-app haarab päringu Envoy sidecar, luuakse span-is «laps» (seetõttu näeme seda jälgimises) ja suunatakse konteinernisse sa-web-app. (Span — loogiline tööhõive Jaegeris, mis sisaldab nime, operatsiooni algusaja ja kestuse. Span'id võivad olla sisemised ja järjestatud. Suunatud aktsükliline graaf span'idest moodustab jälgimise. — tõlkija märkus)
 
 Siin töödeldakse päringut meetodi abil sentimentAnalysis. Need jäljed on juba genereeritud rakenduse poolt, st nende jaoks olid vajalikud muudatused koodis.
 
 Sellest hetkest alates algatatakse POST-päring sa-logic. Jälgimise ID peab olema edastatud sa-web-app.
 
 …
Märkus: 4. sammul peab rakendus nägema Istio genereeritud päiseid ja edastama need edasistes päringutes, nagu on näidatud alloleval pildil:

 (A) Päiste edastamise eest vastutab Istio; (B) Päiste eest vastutavad teenused
Istio täidab põhifunktsiooni, genereerides sisenevate päringute päiseid, luues igas sidecar-is uusi spanne ja suunates neid edasi. Kuid ilma päidikutega töötamiseta teenustes, kaob päringu jälgimise täiuslik tee.
On oluline arvesse võtta (edasi suunata) järgmisi päiseid:
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 rakendamise lihtsustamiseks on juba olemas mitmeid teeke — näiteks teenuses sa-web-app edastab klient RestTemplate need päidikud, kui lihtsalt lisada teegid Jaeger ja OpenTracing oma sõltuvustesse.
Pange tähele, et rakendus Sentiment Analysis demonstreerib teostusi Flaski, Springi ja ASP.NET Core'i peal.
Nüüd, kui on selge, mida me „karbist“ (või peaaegu „karbist“) saame, vaatame lähemalt täpsustatavat marsruutimist, võrgu liikluse haldamist, turvalisust jne!
Märk. tõlge.: selle kohta loe järgmises osas Istio materjalidest, mille on koostanud Rinor Maloku, mille tõlked järgnevad meie blogis varsti. KUUDA (14. märts): Teine osa oletame avaldatud.
P.S. tõlkija märkused
Lugege ka meie blogist:
 
 „Tagasi mikroteenuste juurde koos Istio’ga“: osa 2 (suunamine, liikluse haldamine), osa 3 (autentimine ja autoriseerimine);
 
 «Conduit — kerge teenuste võrk Kuberneteselt»;
 
 «Mis on service mesh ja miks see on vajalik [kogukonna rakendusele, mis põhineb mikroteenustel]?»;
 
 «Illustreeritud juhend Kubernetes'e võrgu seadistamise kohta. Osad 1 ja 2»;
 
 «Kuidas see sidecar-konteiner siia [Kubernetesesse] sattus?».
Allikas: habr.com
marsruut:
 - sihtkoht:
 host: sa-frontend             # 2
 port:
 number: 80
 Olulised punktid:
 
 See VirtualService kehtib päringutele, mis tulevad http-gateway;
 
 V destination määratleb teenuse, kuhu päringud saadetakse.
Märkus: Ülaltoodud konfiguratsioon on salvestatud faili sa-virtualservice-external.yaml, mis sisaldab ka marsruutimise seadeid SA-WebApp ja SA-Feedback jaoks, kuid on artiklis lühidalt esitatud.
Rakendame VirtualService, öeldes:
Märkus: Kui rakendame Istio ressursse, loob Kubernetes API Server sündmuse, mille saab Istio Control Plane, ja alles siis rakendatakse uus konfigureerimine iga podi Envoy-proksiserveritesse. Ingress Gateway kontroller esindab veel ühte Envoy’d, mis on konfigureeritud Control Plane’is. Kõik see näeb skeemis välja nii:

 Istio-IngressGateway konfiguratsioon päringute suunamiseks
Sentiment Analysis rakendus on saadaval aadressil http://{EXTERNAL-IP}/. Ärge muretsege, kui saate staatuse Not Found: kasutamiseks võib olla vajalik veidi rohkem aega, et seadistuse jõustumine toimuks ja Envoy vahemälu uuendataks.
Enne jätkamist töötage rakendusega, et genereerida liiklust (see on vajalik järgmiste toimingute selguse tagamiseks — toimetuse märkus).
Kiali: jälgimine
Kiali administratiivliidesele jõudmiseks täitke järgmine käsk:
… ja avage http://localhost:20001/, logige sisse admin/admin. Siit leiate palju kasulikke võimalusi, näiteks Istio komponentide seadistuse kontrollimiseks, teenuste visualiseerimiseks kogutud teabe alusel, vastamiseks küsimustele "Kes kellega suhtleb?", "Millise teenuse versiooniga tekivad probleemid?" jne. Uurige Kiali võimalusi enne edasiviimist — suunduge metrikate visualiseerimise juurde Grafana.
Grafana: metrikate visualiseerimine
Istios kogutud metrikad jõuavad Prometheusesse ja visualiseeritakse Grafanas. Juurdepääsemiseks Grafana administratiivliidesele täitke allolev käsk, seejärel avage http://localhost:3000/:
Kliki vasakult ülanurgast menüüd Avaleht ja vali Istio teenuse armatuurlaud vasakus ülanurgas, alusta teenusest sa-web-app, et vaadata kogutud mõõdikuid:
Siin ootab meid tühi ja täiesti igav esitlus — juhend kunagi midagi sellist ei kiidaks. Loome nüüd kerge koormuse järgmise käsuga:
Nüüd on meil palju ilusamad graafikud ning lisaks neile on meil fantastilised Prometheuse tööriistad jälgimiseks ja Grafana mõõdiku visualiseerimiseks, mis aitavad meil jälgida teenuste toimivust, terviseseisundit, parandusi/degradatsiooni ajas.
Lõpuks vaatame teenuste päringute jälgimist.
Jaeger : jälgimine
Jälgimine on vajalik, sest mida rohkem meil on teenuseid, seda keerulisem on põhjuse leidmine. Vaatame lihtsat juhtumit allolevast pildist:

 Tüüpiline näide juhuslikust ebaõnnestunud päringust
Päring tuleb, kukub — mis on põhjus? Esimene teenus? Või teine? Mõningad erandid on mõlemas — vaatame igaühe logisid. Kui tihti olete end sellise tegevuse juures tabanud? Meie töö sarnaneb rohkem tarkvara detektiivide omaga kui arendajatega…
See on laialdaselt levinud probleem mikroteenustes ning lahendatakse jagatud süsteemide jälgimisega, kus teenused edastavad üksteisele unikaalse päise, mille järel see teave suunatakse jälgimisse süsteemi, kus see seostatakse päringu andmetega. Siin on illustreeriv joonis:

 Päringu identifitseerimiseks kasutatakse TraceId
Istios kasutatakse Jaeger Tracerit, mis rakendab tootjast sõltumatut raamistikku OpenTracing API. Juhtige kasutajaliidese juurde järgnevate käsureade abil:
Nüüd minge aadressile http://localhost:16686/ ja valige teenus sa-web-app. Kui teenus ei ole avanevas menüüs näha — pange lehelt tegevust või genereerige tegevus ja värskendage liidest. Pärast seda vajutage nuppu Find Traces, mis näitab uusimaid jälgi — valige ükskõik milline — kuvatakse kõigi jälgede üksikasjalik teave:
See jälgib:
 
 Päring jõuab istio-ingressgateway (see on esimene suhtlemine ühe teenusega ja päringu jaoks genereeritakse jälgimise ID), pärast mida suunab värav päringu teenusesse sa-web-app.
 
 Teenuses sa-web-app päring haaratakse kinni Envoy sidecar’i poolt, luuakse span’is "laste" (seetõttu näeme seda jälgimistes) ja suunatakse konteinerisse sa-web-app. (Span — loogiline tööosa Jaeger'is, millel on nimi, töö algusaeg ja kestus. Span’id võivad olla sisemised ja järjestatud. Suunatud tsükliline graaf span’idest moodustab jälje. — tõlkija märkus.
 
 Siin töödeldakse päringut meetodi abil sentimentAnalysis. Need jäljed on juba genereeritud rakenduse poolt, st nende jaoks olid vajalikud muudatused koodis.
 
 Sellest hetkest alates algatatakse POST-päring sa-logic. Jälgimise ID peab olema edastatud sa-web-app.
 
 …
Märkus: 4. sammul peab rakendus nägema Istio genereeritud päiseid ja edastama need edasistes päringutes, nagu on näidatud alloleval pildil:

 (A) Päiste edastamise eest vastutab Istio; (B) Päiste eest vastutavad teenused
Istio teeb põhitegevuse, kuna genereerib sisenevate päringute jaoks päiseid, loob igas sidecar’is uusi span’e ja edastab need edasi. Siiski, kui teenustes ei tehta päistega tööd, siis on päringu jälgimise täispikkus kadunud.
On oluline arvesse võtta (edasi suunata) järgmisi päiseid:
See ei ole keeruline ülesanne, kuid rakendamise lihtsustamiseks on juba olemas mitmeid teeke — näiteks teenuses sa-web-app edastab klient RestTemplate need päidikud, kui lihtsalt lisada teegid Jaeger ja OpenTracing oma sõltuvustesse.
Pange tähele, et rakendus Sentiment Analysis demonstreerib teostusi Flaski, Springi ja ASP.NET Core'i peal.
Nüüd, kui on selge, mida me „karbist“ (või peaaegu „karbist“) saame, vaatame lähemalt täpsustatavat marsruutimist, võrgu liikluse haldamist, turvalisust jne!
Märk. tõlge.: selle kohta loe järgmises osas Istio materjalidest, mille on koostanud Rinor Maloku, mille tõlked järgnevad meie blogis varsti. KUUDA (14. märts): Teine osa oletame avaldatud.
P.S. tõlkija märkused
Lugege ka meie blogist:
 

• „Tagasi mikroteenuste juurde koos Istio’ga“: osa 2 (suunamine, liikluse haldamine), osa 3 (autentimine ja autoriseerimine);
• «Conduit — kerge teenuste võrk Kuberneteselt»;
• «Mis on service mesh ja miks see on vajalik [kogukonna rakendusele, mis põhineb mikroteenustel]?»;
• «Illustreeritud juhend Kubernetes'e võrgu seadistamise kohta. Osad 1 ja 2»;
• «Kuidas see sidecar-konteiner siia [Kubernetesesse] sattus?».

Allikas: habr.com