Vi starter en række indlæg, der demonstrerer nogle af de mange funktioner i Istio Service Mesh i kombination med Red Hat OpenShift og Kubernetes.
Første del i dag:
- Lad os forklare konceptet med Kubernetes sidevognscontainere og formulere ledemotivet i denne serie af indlæg: "du behøver ikke at ændre noget i din kode".
- Lad os forestille os det grundlæggende ved Istio - routingregler. Alle andre funktioner i Istio er bygget på dem, da det er reglerne, der giver dig mulighed for at dirigere trafik til mikrotjenester ved hjælp af YAML-filer eksternt til tjenestekoden. Vi overvejer også Canary Deployment-implementeringsordningen. Nytårsbonus - 10 interaktive Istio-lektioner
Del to, der udkommer snart, vil fortælle dig:
- Hvordan Istio implementerer Pool Ejection i forbindelse med Circuit Breaker og demonstrerer, hvordan Istio giver dig mulighed for at fjerne en inaktiv eller dårligt ydende pod fra balanceskemaet.
- Vi vil også se på Circuit Breaker-emnet fra det første indlæg om, hvordan Istio kan bruges her. Vi vil vise, hvordan man dirigerer trafik og håndterer netværksfejl uden den mindste ændring i servicekoden ved hjælp af YAML-konfigurationsfiler og terminalkommandoer.
Del tre:
- En historie om sporing og overvågning, der allerede er indbygget eller nemt tilføjet til Istio. Vi viser dig, hvordan du bruger værktøjer som Prometheus, Jaeger og Grafana i forbindelse med OpenShift-skalering til ubesværet at administrere din mikroservicearkitektur.
- Vi går fra at overvåge og håndtere fejl til at introducere dem i systemet med vilje. Vi lærer med andre ord at lave fejlinjektion uden at ændre kildekoden, hvilket er meget vigtigt set i forhold til test – for ændrer man selve koden til dette, så er der risiko for at indføre yderligere fejl.
Til sidst, i det sidste indlæg på Istio Service Mesh:
- Lad os gå til den mørke side. Mere præcist vil vi lære at bruge Dark Launch-skemaet, når koden implementeres og testes direkte på produktionsdata, men ikke påvirker systemets drift på nogen måde. Det er her Istios evne til at opdele trafik kommer til nytte. Og evnen til at udføre test på live produktionsdata uden at påvirke driften af kampsystemet på nogen måde er den mest overbevisende måde at kontrollere.
- Med udgangspunkt i Dark Launch viser vi dig, hvordan du bruger Canary Deployment-modellen til at reducere risikoen og gøre det nemmere at implementere ny kode. Canary Deployment i sig selv er ikke nyt, men Istio giver dig mulighed for at implementere denne ordning med blot simple YAML-filer.
- Afslutningsvis vil vi vise, hvordan man bruger Istio Egress til at give adgang til tjenester til dem, der er uden for dine klynger, for at bruge Istios muligheder, når de arbejder med internettet.
Så afsted...
Istio overvågnings- og administrationsværktøjssæt - alt hvad du behøver for at koordinere mikrotjenester i et servicenet .
Hvad er Istio Service Mesh
Servicenetværket implementerer for en gruppe af tjenester funktioner som trafikovervågning, adgangskontrol, opdagelse, sikkerhed, fejltolerance og andre nyttige ting. Istio giver dig mulighed for at gøre alt dette uden den mindste ændring i koden for selve tjenesterne. Hvad er hemmeligheden bag magien? Istio knytter sin egen fuldmagt til hver service i form af en sidevognscontainer (sidevogn er en motorcykelsidevogn), hvorefter al trafik til denne service går gennem proxyen, som styret af de angivne politikker bestemmer hvordan, hvornår og om denne trafik bør overhovedet nå tjenesten. Istio giver dig også muligheden for at implementere avancerede DevOps-teknikker såsom kanarie-implementeringer, afbrydere, fejlinjektion og mere.
Sådan fungerer Istio med containere og Kubernetes
Istio-servicenetværket er en sidevognsimplementering af alt, hvad du behøver for at oprette og administrere mikrotjenester: overvågning, sporing, strømafbrydere, routing, belastningsbalancering, fejlinjektion, genforsøg, timeouts, spejling, adgangskontrol, hastighedsbegrænsning og mere. andet. Og selvom der er tonsvis af biblioteker i dag til at implementere disse funktioner direkte i kode, kan du med Istio få præcis det samme uden at ændre noget i din kode.
Ifølge sidevognsmodellen kører Istio i en Linux-container, som er placeret i en -pod med en kontrolleret service og implementerer (injicer) og udtrækker (udtræk) funktionalitet og information i henhold til den givne konfiguration. Vi understreger, at dette er din egen konfiguration, og den lever uden for din kode. Derfor bliver koden meget enklere og kortere.
Endnu vigtigere er den operationelle komponent af mikrotjenester på ingen måde forbundet med selve koden, hvilket betyder, at deres drift sikkert kan overføres til it-specialister. Ja, hvorfor skulle en udvikler være ansvarlig for strømafbrydere og fejlindsprøjtning? Reagere, ja, men bearbejde og skabe dem? Hvis du fjerner alt dette fra koden, kan programmører fuldt ud fokusere på applikationsfunktionalitet. Og selve koden bliver kortere og enklere.
Servicenet
Istio, som implementerer administrationsfunktionerne for mikrotjenester uden for deres kode - dette er konceptet for Service Mesh. Med andre ord er det en koordineret gruppe af en eller flere binære filer, der danner et gitter af netværksfunktioner.
Sådan fungerer Istio med mikrotjenester
Sådan fungerer sidevognscontainere i forbindelse med и fugleperspektiv: start en Minishift-instans, opret et Istio-projekt (lad os kalde det "istio-system"), installer og kør alle Istio-relaterede komponenter. Når du derefter opretter projekter og pods, tilføjer du konfigurationsoplysninger til dine implementeringer, og dine pods begynder at bruge Istio. Et forenklet diagram ser således ud:
Nu kan du ændre Istio-indstillinger til for eksempel at organisere fejlinjektion, support eller andre funktioner i Istio - og alt dette uden at røre ved koden for selve applikationerne. Lad os sige, at du vil omdirigere al webtrafik fra brugere af din største kunde (Foo Corporation) til en ny version af dit websted. Alt du skal gøre er at oprette en Istio-routingregel, der ser efter @foocorporation.com i bruger-id'et og omdirigerer i overensstemmelse hermed. For alle andre brugere vil intet ændre sig. I mellemtiden vil du stille og roligt teste den nye version af siden. Og bemærk, at for dette er det absolut ikke nødvendigt at involvere udviklere.
Og hvor meget skal du betale for det?
Slet ikke. Istio er ret hurtig, det er skrevet ind og skaber en meget lille overhead. Derudover opvejes et muligt tab i online-produktivitet af en stigning i udviklerproduktiviteten. I hvert fald i teorien: glem ikke, at udviklernes tid er værdifuld. Med hensyn til softwareomkostninger er Istio open source software, så det er gratis at få og bruge.
Mestrer det selv
Red Hat Developer Experience Team har udviklet en dybdegående hands-on af Istio (på engelsk). Den kører på Linux, MacOS og Windows, og koden kommer i Java og Node.js varianter.
10 interaktive Istio-lektioner
Blok 1 - For begyndere
Introduktion til Istio
30 minutter
Vi stifter bekendtskab med Service Mesh, lærer at installere Istio i Kubernetes OpenShift-klyngen.
Implementering af mikrotjenester i Istio
30 minutter
Vi bruger Istio til at implementere tre mikrotjenester med Spring Boot og Vert.x.
Blok 2 - mellemtrin
Overvågning og sporing i Istio
60 minutter
Udforsk Istios indbyggede overvågningsværktøjer, brugerdefinerede metrics og OpenTracing via Prometheus og Grafana.
Enkel routing i Istio
60 minutter
Lær, hvordan du styrer routing i Istio ved hjælp af enkle regler.
Avancerede routingregler
60 minutter
Vi stifter bekendtskab med smart routing i Istio, adgangskontrol, load balancing og rate limiting.
Blok 3 - Avanceret bruger
Fejlindsprøjtning i Istio
60 minutter
Vi studerer fejlhåndteringsscenarier i distribuerede applikationer, skaber HTTP-fejl og netværksforsinkelser og lærer, hvordan man anvender kaosteknik til at genoprette miljøet.
Strømafbryder i Istio
30 minutter
Vi installerer Siege til stressteststeder og lærer, hvordan man sikrer backend-fejltolerance ved hjælp af genforsøg, strømafbryder og pooludkast.
Egress og Istio
10 minutter
Vi bruger Egress-ruter til at skabe regler for interaktion mellem interne tjenester og eksterne API'er og tjenester.
Istio og Kiali
15 minutter
At lære at bruge Kiali til at få et stort billede af servicenetværket og studere strømmen af anmodninger og data.
Gensidig TLS i Istio
15 minutter
Vi opretter Istio Gateway og VirtualService og studerer derefter gensidig TLS (mTLS) og dens indstillinger i detaljer.
Boks 3.1 - Deep Dive: Istio Service Mesh for Microservices
Hvad handler bogen om:
- Hvad er et servicenet.
- Istio-systemet og dets rolle i mikroservicearkitektur.
- Brug af Istio til følgende opgaver:
- Fejltolerance;
- Routing;
- Kaos test;
- sikkerhed;
- Indsamling af telemetri ved hjælp af sporing, metrics og Grafana.
Serie af artikler om servicemasker og Istio
Prøv det selv
Denne serie af indlæg er ikke beregnet til at give et dybt dyk ind i Istios verden. Vi vil blot introducere dig til selve konceptet og måske inspirere dig til selv at prøve Istio. Det er helt gratis, og Red Hat giver alle de værktøjer, du skal bruge for at komme i gang med OpenShift, Kubernetes, Linux-containere og Istio, herunder: , og andre ressourcer på vores . Vent ikke, kom i gang i dag!
Istio Routing Regler: Diriger serviceanmodninger til det rigtige sted
и er fremragende til at håndtere dirigeret til de nødvendige pods. Dette er et af formålene med Kubernetes eksistens - routing og belastningsbalancering. Men hvad nu hvis du har brug for mere subtil og sofistikeret routing? For eksempel at bruge to versioner af en mikrotjeneste på samme tid. Hvordan kan Istio-rutereglerne hjælpe her?
Ruteregler er de regler, der i virkeligheden specificerer valget af rute. Uanset systemets kompleksitet forbliver det generelle princip bag disse regler enkelt: anmodninger dirigeres baseret på visse parametre og HTTP-headerværdier.
Lad os se på eksempler:
Kubernetes Standard: Trivielt "50/50"
I vores eksempel vil vi vise, hvordan man bruger to versioner af en mikrotjeneste i OpenShift på samme tid, lad os kalde dem v1 og v2. Hver version kører i sin egen Kubernetes-pod, og jævnt afbalanceret round robin-routing fungerer her som standard. Hver pod modtager sin andel af anmodninger i henhold til antallet af dens mikroservice-forekomster, med andre ord replikaer. Istio giver dig mulighed for at ændre denne balance manuelt.
Lad os sige, at vi implementerede to versioner af vores anbefalingstjeneste, anbefaling-v1 og anbefaling-v2, på OpenShift.
På fig. Figur 1 viser, at når hver tjeneste er repræsenteret i en enkelt instans, er anmodninger jævnt flettet mellem dem: 1-2-1-2-... Sådan fungerer Kubernetes-routing som standard:
Vægtet fordeling mellem versioner
På fig. Figur 2 viser, hvad der sker, hvis du øger antallet af v2-servicereplikaer fra én til to (dette gøres med kommandoen oc-skalaen --replicas=2 deployment/recommendation-v2). Som du kan se, er anmodninger mellem v1 og v2 nu opdelt i et en-til-tre forhold: 1-2-2-1-2-2-...:
Ignorer version med Istio
Istio gør det nemt at ændre fordelingen af anmodninger på den måde, vi har brug for. Send for eksempel kun al trafik til anbefaling-v1 med følgende Istio yaml-fil:
Her skal du være opmærksom på dette: bælg er udvalgt efter etiketter. I vores eksempel bruges etiketten v1. Parameteren "vægt: 100" betyder, at 100 % af trafikken vil blive dirigeret til alle pods af tjenesten, der har v1-etiketten.
Direktivfordeling mellem versioner (Canary Deployment)
Ved hjælp af vægtparameteren kan du desuden dirigere trafik til begge pods, idet du ignorerer antallet af mikroservice-forekomster, der kører i hver af dem. For eksempel dirigerer vi her direktiv 90 % af trafikken til v1 og 10 % til v2:
Separat mobilbrugerrouting
Afslutningsvis vil vi vise, hvordan man tvinger mobilbrugeres trafik til at blive dirigeret til v2-tjenesten, og alle andre brugere til v1. For at gøre dette bruger vi regulære udtryk til at analysere brugeragentværdien i anmodningsoverskriften:
Din tur
Regex-eksemplet til parsing af overskrifter burde motivere dig til at udforske dine egne måder at anvende Istios routingregler på. Desuden er mulighederne her meget omfattende, da headerværdierne kan dannes i applikationernes kildekode.
Og husk, at Ops, ikke Dev
Alt, hvad vi viste i eksemplerne ovenfor, udføres uden den mindste ændring i kildekoden, godt, bortset fra de tilfælde, hvor det er nødvendigt at danne specielle anmodningsoverskrifter. Istio vil være nyttig både for udviklere, som for eksempel vil kunne bruge det på teststadiet, og for it-systemoperatører, som det vil hjælpe i høj grad i produktionen.
Så lad os gentage grundtonen i denne serie af indlæg: du behøver ikke at ændre noget i din kode. Ingen grund til at bygge nye billeder eller køre nye containere. Alt dette er implementeret uden for koden.
tænde din fantasi
Forestil dig mulighederne for at analysere overskrifter med regulære udtryk. Vil du omdirigere din største kunde til en speciel version af din ? Let! Har du brug for en separat version til Chrome-browseren? Intet problem! Du kan dirigere trafik i overensstemmelse med næsten alle dens egenskaber.
Prøv det selv
At læse om Istio, Kubernetes og OpenShift er én ting, men hvorfor ikke røre det hele selv? Hold udarbejdet en detaljeret vejledning (på engelsk), der vil hjælpe dig med at mestre disse teknologier så hurtigt som muligt. Guiden er også 100% open source, så den er i det offentlige domæne. Filen fungerer på macOS, Linux og Windows, og kildekoden er tilgængelig i Java- og node.js-versioner (flere sprog kommer snart). Bare åbn det relevante git-lager i din browser .
I næste indlæg: Træn problemer smukt
I dag så du, hvad Istio routingregler kan gøre. Forestil dig nu alligevel, men kun i forhold til fejlhåndtering. Det er præcis, hvad vi vil dække i næste indlæg.
Kilde: www.habr.com