Vi starter en serie med innlegg som viser noen av de mange funksjonene til Istio Service Mesh kombinert med Red Hat OpenShift og Kubernetes.
Del én, i dag:
- La oss forklare konseptet med Kubernetes sidevogncontainere og formulere ledemotivet til denne serien med innlegg: "du trenger ikke å endre noe i koden din".
- La oss introdusere det grunnleggende med Istio - rutingregler. Alle andre Istio-funksjoner er bygget på dem, siden det er reglene som lar deg dirigere trafikk til mikrotjenester ved å bruke YAML-filer utenfor tjenestekoden. Vi vurderer også utplasseringsordningen for Canary Deployment. Nyttårsbonus – 10 interaktive leksjoner på Istio
Del to, som kommer snart, vil fortelle deg:
- Hvordan Istio implementerer Pool Ejection i kombinasjon med Circuit Breaker og vil demonstrere hvordan Istio lar deg fjerne en død eller dårlig ytelse pod fra balanseringskretsen.
- Vi skal også se på Circuit Breaker-emnet fra det første innlegget for å se hvordan Istio kan brukes her. Vi vil vise deg hvordan du ruter trafikk og håndterer nettverksfeil ved å bruke YAML-konfigurasjonsfiler og terminalkommandoer uten de minste endringer i tjenestekoden.
Del tre:
- En historie om sporing og overvåking, som allerede er innebygd eller enkelt lagt til Istio. Vi viser deg hvordan du bruker verktøy som Prometheus, Jaeger og Grafana i kombinasjon med OpenShift-skalering for å enkelt administrere mikrotjenestearkitekturer.
- Vi går fra å overvåke og håndtere feil til å introdusere dem i systemet med vilje. Vi lærer med andre ord hvordan du kan gjøre feilinjeksjon uten å endre kildekoden, noe som er veldig viktig fra et testsynspunkt - siden hvis du endrer selve koden for dette, er det en risiko for å introdusere ytterligere feil.
Til slutt, i det siste innlegget på Istio Service Mesh:
- La oss gå til den mørke siden. Mer presist vil vi lære å bruke Dark Launch-skjemaet, når koden er distribuert og testet direkte på produksjonsdata, men ikke påvirker driften av systemet på noen måte. Det er her Istios evne til å dele trafikk kommer godt med. Og muligheten til å teste på live produksjonsdata uten å påvirke driften av kampsystemet på noen måte er den mest overbevisende metoden for verifisering.
- Med utgangspunkt i Dark Launch viser vi deg hvordan du bruker Canary Deployment-modellen for å redusere risiko og gjøre det enklere å få ny kode i produksjon. Canary Deployment i seg selv er langt fra nytt, men Istio lar deg implementere denne ordningen med bare enkle YAML-filer.
- Til slutt vil vi vise deg hvordan du bruker Istio Egress for å gi tilgang til tjenester til de som er utenfor dine klynger for å bruke mulighetene til Istio når du jobber med Internett.
Så, her går vi...
Istio overvåkings- og administrasjonsverktøy - alt du trenger for å orkestrere mikrotjenester i et servicenettverk .
Hva er Istio Service Mesh
Et servicenettverk implementerer funksjoner som trafikkovervåking, tilgangskontroll, oppdagelse, sikkerhet, feiltoleranse og andre nyttige ting for en gruppe tjenester. Istio lar deg gjøre alt dette uten de minste endringer i koden til selve tjenestene. Hva er hemmeligheten bak magien? Istio knytter sin egen proxy til hver tjeneste i form av en sidevogncontainer (sidevogn er en motorsykkelsidevogn), hvoretter all trafikk til denne tjenesten går gjennom proxyen, som, styrt av spesifiserte retningslinjer, bestemmer hvordan, når og om denne trafikken bør nå tjenesten i det hele tatt. Istio gjør det også mulig å implementere avanserte DevOps-teknikker som kanarie-utplasseringer, strømbrytere, feilinjeksjon og mange andre.
Hvordan Istio fungerer med containere og Kubernetes
Istio-tjenestenettverket er en sidevognimplementering av alt som kreves for å lage og administrere mikrotjenester: overvåking, sporing, strømbrytere, ruting, lastbalansering, feilinjeksjon, gjenforsøk, tidsavbrudd, speiling, tilgangskontroll, hastighetsbegrensning og mye mer. annet. Og selv om det i dag finnes massevis av biblioteker for å implementere disse funksjonene direkte i kode, kan du med Istio få alle de samme tingene uten å endre noe i koden din.
I følge sidevognsmodellen kjører Istio i en Linux-container, som er plassert i en -pod med en kontrollert tjeneste og injiserer og trekker ut funksjonalitet og informasjon i henhold til en gitt konfigurasjon. Vi understreker at dette er din egen konfigurasjon, og den lever utenfor koden din. Derfor blir koden mye enklere og kortere.
Det som også er viktig er at den operasjonelle komponenten til mikrotjenester viser seg å ikke være på noen måte forbundet med selve koden, noe som betyr at driften deres trygt kan overføres til IT-spesialister. Faktisk, hvorfor skal utvikleren være ansvarlig for effektbrytere og feilinjeksjon? Reagere, ja, men behandle dem og lage dem? Hvis du fjerner alt dette fra koden, vil programmerere kunne fokusere fullt ut på applikasjonsfunksjonalitet. Og selve koden vil bli kortere og enklere.
Tjenestenett
Istio, som implementerer funksjoner for å administrere mikrotjenester utenfor koden deres, er konseptet med et Service Mesh. Med andre ord er det en koordinert gruppe av en eller flere binærfiler som danner et nett av nettverksfunksjoner.
Hvordan Istio fungerer med mikrotjenester
Slik ser arbeidet med sidevognscontainere ut i forbindelse med и fugleperspektiv: start en forekomst av Minishift, lag et prosjekt for Istio (la oss kalle det "istio-system"), installer og kjør alle Istio-relaterte komponenter. Deretter, mens du oppretter prosjekter og pods, legger du til konfigurasjonsinformasjon til distribusjonene dine, og podene begynner å bruke Istio. Et forenklet diagram ser slik ut:
Nå kan du endre Istio-innstillingene for for eksempel å organisere feilinjeksjon, support eller andre Istio-funksjoner - og alt dette uten å berøre koden til selve applikasjonene. La oss si at du vil omdirigere all nettrafikk fra brukere av din største klient (Foo Corporation) til en ny versjon av nettstedet. For å gjøre dette, lag ganske enkelt en Istio-rutingsregel som vil se etter @foocorporation.com i bruker-IDen og omdirigere deretter. For alle andre brukere vil ingenting endre seg. I mellomtiden vil du rolig teste den nye versjonen av siden. Og merk at du ikke trenger å involvere utviklere i det hele tatt for dette.
Og må du betale dyrt for det?
Ikke i det hele tatt. Istio er ganske rask og er skrevet inn og skaper svært lite overhead. I tillegg blir det mulige tapet i online-produktivitet oppveid av en økning i utviklerproduktiviteten. I hvert fall i teorien: ikke glem at utviklernes tid er verdifull. Når det gjelder programvarekostnader, er Istio programvare med åpen kildekode, så du kan få og bruke den gratis.
Mestre det selv
Red Hat Developer Experience Team har utviklet en grundig hands-on av Istio (på engelsk). Den kjører på Linux, MacOS og Windows, og koden er tilgjengelig i Java og Node.js.
10 interaktive leksjoner på Istio
Blokk 1 - For nybegynnere
Introduksjon til Istio
30 minutter
La oss bli kjent med Service Mesh, lær hvordan du installerer Istio i en OpenShift Kubernetes-klynge.
Distribuerer mikrotjenester i Istio
30 minutter
Vi bruker Istio til å distribuere tre mikrotjenester med Spring Boot og Vert.x.
Blokk 2 – mellomnivå
Overvåking og sporing i Istio
60 minutter
Vi vil utforske Istios innebygde overvåkingsverktøy, tilpassede beregninger og OpenTracing via Prometheus og Grafana.
Enkel ruting i Istio
60 minutter
Lær hvordan du administrerer ruting i Istio ved hjelp av enkle regler.
Avanserte rutingsregler
60 minutter
La oss ta en titt på Istios smarte ruting, tilgangskontroll, lastbalansering og hastighetsbegrensning.
Blokk 3 – avansert bruker
Feilinjeksjon i Istio
60 minutter
Vi studerer scenarier for feilhåndtering i distribuerte applikasjoner, skaper HTTP-feil og nettverksforsinkelser, og lærer å bruke kaosteknikk for å gjenopprette miljøet.
Strømbryter i Istio
30 minutter
Vi installerer Siege for stressteststeder og lærer hvordan vi sikrer backend-feiltoleranse ved å bruke replays, kretsbryter og bassengutkast.
Egress og Istio
10 minutter
Vi bruker Egress-ruter for å lage regler for samhandling av interne tjenester med eksterne APIer og tjenester.
Istio og Kiali
15 minutter
Lær å bruke Kiali for å få en oversikt over tjenestenettverket og utforske forespørsels- og dataflyter.
Gjensidig TLS i Istio
15 minutter
Vi lager Istio Gateway og VirtualService, deretter studerer vi gjensidig TLS (mTLS) og dens innstillinger i detalj.
Blokk 3.1 - Deep Dive: Istio Service Mesh for Microservices
Hva handler boken om:
- Hva er et servicenettverk?
- Istio-systemet og dets rolle i mikrotjenestearkitektur.
- Bruke Istio til å løse følgende problemer:
- Feiltoleranse;
- Ruting;
- Kaos testing;
- sikkerhet;
- Telemetrisamling ved bruk av spor, metrikk og Grafana.
Serie med artikler om servicemasker og Istio
Prøv det selv
Denne serien med innlegg er ikke ment å gi et dypdykk inn i Istios verden. Vi vil bare introdusere deg for konseptet og kanskje inspirere deg til å prøve Istio selv. Det er helt gratis å gjøre, og Red Hat gir deg alle verktøyene du trenger for å komme i gang med OpenShift, Kubernetes, Linux-containere og Istio, inkludert: , og andre ressurser på vår . Ikke utsett, start i dag!
Istio-rutingsregler: dirigere tjenesteforespørsler dit de trenger å gå
и gjør en utmerket jobb med å adressere rutes til de nødvendige podene. Dette er en av grunnene til eksistensen av Kubernetes - ruting og lastbalansering. Men hva om du trenger mer subtil og sofistikert ruting? For eksempel å bruke to versjoner av en mikrotjeneste samtidig. Hvordan kan Istio-ruteregler hjelpe her?
Ruteregler er reglene som faktisk bestemmer valg av rute. Uavhengig av nivået av systemkompleksitet, forblir det generelle driftsprinsippet for disse reglene enkelt: forespørsler rutes basert på visse parametere og HTTP-headerverdier.
La oss se på eksempler:
Kubernetes standard: trivielt "50/50"
I vårt eksempel vil vi vise hvordan du samtidig bruker to versjoner av en mikrotjeneste i OpenShift, la oss kalle dem v1 og v2. Hver versjon kjører i sin egen Kubernetes-pod, og som standard kjører den jevnt balansert round robin-ruting. Hver pod mottar sin andel av forespørsler basert på antall mikrotjenesteforekomster, med andre ord replikaer. Istio lar deg endre denne saldoen manuelt.
La oss si at vi distribuerte to versjoner av vår anbefalingstjeneste på OpenShift, anbefaling-v1 og anbefaling-v2.
I fig. Figur 1 viser at når hver tjeneste er representert i én instans, veksler forespørsler jevnt mellom dem: 1-2-1-2-... Dette er hvordan Kubernetes-ruting fungerer som standard:
Vektet fordeling mellom versjoner
I fig. Figur 2 viser hva som skjer hvis du øker antallet v2-tjenestereplikaer fra én til to (dette gjøres med oc-skalaen —replicas=2 deployment/recommendation-v2-kommandoen). Som du kan se, er forespørsler mellom v1 og v2 nå delt inn i et en-til-tre-forhold: 1-2-2-1-2-2-...:
Ignorer versjon som bruker Istio
Istio gjør det enkelt å endre fordelingen av forespørsler på den måten vi trenger. Send for eksempel all trafikk kun til anbefaling-v1 ved å bruke følgende Istio yaml-fil:
Her må du være oppmerksom på dette: pods velges i henhold til etikettene. Eksempelet vårt bruker label v1. "Weight: 100"-parameteren betyr at 100 % av trafikken vil bli rutet til alle service-pods som har v1-etiketten.
Direktivdistribusjon mellom versjoner (Canary Deployment)
Deretter, ved å bruke vektparameteren, kan du dirigere trafikk til begge podene, og ignorere antallet mikrotjenesteforekomster som kjører i hver av dem. Her dirigerer vi for eksempel 90 % av trafikken til v1 og 10 % til v2:
Separat ruting for mobilbrukere
Avslutningsvis vil vi vise hvordan man tvinger mobilbrukertrafikk til å rutes til tjeneste v2, og alle andre til v1. For å gjøre dette bruker vi regulære uttrykk for å analysere brukeragentverdien i forespørselsoverskriften:
Nå er det din tur
Eksemplet med regulære uttrykk for å analysere overskrifter bør motivere deg til å finne din egen bruk av Istio-rutingsregler. Dessuten er mulighetene her ganske omfattende, siden overskriftsverdier kan dannes i applikasjonens kildekode.
Og husk at Ops, ikke Dev
Alt vi viste i eksemplene ovenfor er gjort uten de minste endringer i kildekoden, vel, bortsett fra de tilfellene hvor det er nødvendig å generere spesielle forespørselshoder. Istio vil være nyttig både for utviklere, som for eksempel vil kunne bruke det på teststadiet, og for spesialister på drift av IT-systemer, som det vil være til stor hjelp i produksjonen.
Så la oss gjenta ledemotivet til denne serien med innlegg: du trenger ikke endre noe i koden din. Det er ikke nødvendig å bygge nye bilder eller lansere nye beholdere. Alt dette er implementert utenfor koden.
Bruk fantasien din
Bare forestill deg mulighetene for overskriftsanalyse ved bruk av regulære uttrykk. Ønsker å omdirigere din største kunde til en spesialversjon av din ? Enkelt! Trenger du en egen versjon for Chrome-nettleseren? Ikke noe problem! Du kan rute trafikk i henhold til nesten alle kjennetegn.
Prøv det selv
Å lese om Istio, Kubernetes og OpenShift er én ting, men hvorfor ikke ta på alt selv? Team har utarbeidet en detaljert veiledning (på engelsk) som vil hjelpe deg å mestre disse teknologiene så raskt som mulig. Håndboken er også 100 % åpen kildekode, så den legges ut i det offentlige domene. Filen fungerer på macOS, Linux og Windows, og kildekoden er tilgjengelig i Java- og node.js-versjoner (versjoner på andre språk kommer snart). Bare åpne det tilsvarende git-depotet i nettleseren din .
I neste innlegg: vi løser problemer vakkert
I dag så du hva Istio-rutingsregler kan gjøre. Tenk deg nå det samme, men bare i forhold til feilhåndtering. Det er akkurat dette vi skal snakke om i neste innlegg.
Kilde: www.habr.com