Vi begynder en række indlæg, hvor vi vil demonstrere nogle af de mange muligheder ved Istio Service Mesh i kombination med Red Hat OpenShift og Kubernetes.
Del et, dagens:
- Vi forklarer konceptet med sidecar-containere i Kubernetes og formulerer temaet for denne serie af indlæg: «du behøver ikke at ændre noget i din kode».
- Lad os præsentere den grundlæggende ting ved Istio – routingreglerne. Alle andre muligheder ved Istio bygger på dem, da det netop er reglerne, der gør det muligt at styre trafikken til mikrotjenester ved hjælp af YAML-filer, der er eksterne i forhold til koden. Vi ser også på Canary Deployment skemaet. Nytårs bonus – 10 interaktive lektioner om Istio.
Del to, som snart kommer ud, vil fortælle dig:
- Hvordan Istio implementerer Pool Ejection i kombination med Circuit Breaker og demonstrerer, hvordan Istio kan fjerne en ikke fungerende eller dårligt fungerende pod fra load balancing skemaet.
- Vi vil også undersøge emnet Circuit Breaker fra det første indlæg med hensyn til, hvordan man kan anvende Istio her. Vi viser, hvordan man kan styre trafikken og håndtere netværksfejl uden nogen ændringer i servicekoden ved hjælp af YAML-konfigurationsfiler og terminalkommandoer.
Del tre:
- En fortælling om sporing og overvågning, der allerede er indbygget eller let kan tilføjes i Istio. Vi viser, hvordan man bruger værktøjer som Prometheus, Jaeger og Grafana i kombination med OpenShift-skalering for at styre mikrotjenestearkitekturen uden besvær.
- Vi går fra overvågning og fejlhåndtering til at indføre fejl i systemet med vilje. Med andre ord, vi lærer at udføre fejlindsprøjtning uden at ændre kildekoden, hvilket er meget vigtigt i forhold til testning – da der er risiko for at introducere yderligere fejl, hvis man ændrer selve koden.
Endelig, i det sidste indlæg om Istio Service Mesh:
- Vi bevæger os til Den Mørke Side. Mere præcist, vi vil lære at bruge Dark Launch-schemaet, hvor koden implementeres og testes direkte på produktionsdata, men ikke påvirker systemets drift. Her kommer Istios evne til at dele trafik godt med. Muligheden for at teste på rigtige produktionsdata uden at påvirke driften af produktsystemet er den mest overbevisende måde at verificere på.
- Med udgangspunkt i Dark Launch vil vi vise, hvordan man bruger Canary Deployment-modellen til at reducere risici og forenkle implementeringen af ny kode. Canary Deployment i sig selv er ikke en ny idé, men Istio gør det muligt at implementere denne tilgang blot ved hjælp af enkle YAML-filer.
- Afslutningsvis vil vi vise, hvordan man med Istio Egress kan give adgang til tjenester til dem, der befinder sig uden for dine klynger, for at udnytte Istios muligheder i arbejdet med internettet.
Så lad os komme i gang...
Istios overvågnings- og administrationsværktøjer – alt hvad der er nødvendigt for at koordinere mikrotjenester i servicenetværket .
Hvad er Istio servicenetværk
Servicenetværket tilbyder en gruppe tjenester funktioner som trafikovervågning, adgangskontrol, opdagelse, sikkerhed, fejltolerance og andre nyttige funktioner. Istio gør det muligt at gøre alt dette uden nogen ændringer i selve tjenesternes kode. Hvad er hemmeligheden bag magien? Istio tilføjer sin egen proxy i form af en sidecar-container til hver tjeneste, hvorefter al trafik til den pågældende tjeneste går gennem proxyen, som i henhold til de angivne politikker bestemmer, hvordan, hvornår og om denne trafik overhovedet skal nå tjenesten. Istio giver også mulighed for at implementere avancerede DevOps-teknikker som canary deployments, circuit breakers, fault injection og mange flere.
Hvordan Istio arbejder med containere og Kubernetes
Istio-servicenetværket er en sidecar-implementering af alt, hvad der kræves for at oprette og administrere mikrotjenester: overvågning, sporing, circuit breakers, routing, belastningsbalancering, fault injection, gentagelser, timeouts, spejling, adgangskontrol, hastighedsbegrænsning og meget mere. Og selvom der i dag findes mange biblioteker til at implementere disse funktioner direkte i koden, kan du med Istio få alt det samme uden at ændre noget i din kode.
I henhold til sidecar-modellen kører Istio i en Linux-container, der er placeret i samme -pod som den kontrollerede tjeneste og injicerer (inject) og udtrækker (extract) funktionalitet og information i henhold til den angivne konfiguration. Det skal understreges, at det er din egen konfiguration, og den lever uden for din kode. Derfor bliver koden meget enklere og kortere.
Det er også vigtigt, at den operationelle del af mikrotjenesterne ikke er knyttet til selve koden, hvilket betyder, at deres drift kan overdrages til it-specialister. Men hvorfor skal udvikleren så være ansvarlig for circuit breakers og fault injection? At reagere – ja, men at håndtere dem og skabe dem? Hvis man fjerner alt dette fra koden, kan programmører fokusere helt på den applikationsspecifikke funktionalitet. Koden vil også blive kortere og simplere.
Service mesh
Istio, der implementerer funktioner til at administrere mikrotjenester uden for deres kode – er netop konceptet service mesh. Med andre ord, det er en koordineret gruppe af en eller flere binære filer, der danner et netværk af netværksfunktioner.
Hvordan Istio arbejder med mikrotjenester
Sådan fungerer sidecar-containere i forbindelse med og set fra fugleperspektiv: du starter en instans af Minishift, opretter et projekt for Istio (lad os kalde det "istio-system"), installer og starter alle relaterede komponenter. Derefter, som du opretter projekter og pods, tilføjer du konfigurationsoplysninger til dine deployment, og dine pods begynder at bruge Istio. En forenklet diagram ser således ud:
Nu kan du ændre Istios indstillinger for eksempel for at organisere fault injection, understøttelse eller andre muligheder i Istio – og alt dette uden at berøre selve applikationskoden. Antag, at du vil omdirigere al webtrafik fra brugerne af din største kunde (Foo Corporation) til den nye version af sitet. For at gøre dette skal du blot oprette en Istio-routingregel, der skal finde @foocorporation.com i brugerens ID og udføre den relevante omdirigering. For alle andre brugere vil der ikke ændre sig noget. Og du kan samtidigt teste den nye version af sitet. Og bemærk, at dette slet ikke kræver involvering af udviklerne.
Og vil det koste meget?
Slet ikke. Istio fungerer ret hurtigt, det er skrevet i og skaber en meget lille overhead. Desuden kompenseres det mulige tab i online-ydeevne af produktivitetstilvæksten hos udviklerne. I det mindste i teorien: glem ikke, at udviklernes tid koster penge. Hvad angår udgifter til software, er Istio en open source-løsning, så det kan hentes og bruges gratis.
Lær selv
Red Hat Developer Experience Team har udviklet en dybdegående praktisk guide til Istio (på engelsk). Den fungerer på Linux, MacOS og Windows, og koden findes i versioner på Java og Node.js.
10 interaktive lektioner om Istio
Blok 1 — For begyndere
Introduktion til Istio
30 minutter
Vi bliver bekendt med Service Mesh, lærer at installere Istio i et Kubernetes-klynge på OpenShift.
Udrulning af mikrotjenester i Istio
30 minutter
Vi bruger Istio til at udrulle tre mikrotjenester med Spring Boot og Vert.x.
Blok 2 – Mellemniveau
Overvågning og sporing i Istio
60 minutter
Vi studerer de indbyggede overvågningsværktøjer i Istio, konfigurerbare metrics samt OpenTracing via Prometheus og Grafana.
Enkel routing i Istio
60 minutter
Vi lærer at styre routing i Istio med enkle regler.
Avancerede routingregler
60 minutter
Vi bliver bekendt med smart routing i Istio, adgangskontrol, load balancing og hastighedsbegrænsning.
Blok 3 – Erfarne brugere
Fejlindsprøjtning i Istio
60 minutter
Vi studerer scenarier til fejlbehandling i distribuerede applikationer, skaber HTTP-fejl og netværksforsinkelser, lærer at anvende chaos engineering til at genskabe miljøet.
Circuit Breaker i Istio
30 minutter
Vi installerer Siege til stresstest af hjemmesider og lærer at sikre backendens fejltolerance ved hjælp af retries, circuit breakers og pool-ejection.
Egress og Istio
10 minutter
Vi bruger Egress-ruter til at oprette regler for samspillet mellem interne tjenester og eksterne API'er og tjenester.
Istio og Kiali
15 minutter
Vi lærer at bruge Kiali til at få et overblik over service-mesh og undersøge forespørgsels- og datastrømme.
Mutual TLS i Istio
15 minutter
Vi opretter Istio Gateway og VirtualService, hvorefter vi går i dybden med mutual TLS (mTLS) og dets indstillinger.
Blok 3.1 — Dybdegående: Istio Service Mesh til mikrotjenester
Hvad bogen handler om:
- Hvad er en service mesh.
- Systemet Istio og dets rolle i mikrotjenestearkitekturen.
- Brug af Istio til at løse følgende opgaver:
- Fejltolerance;
- Routing;
- Chaos-testning;
- Sikkerhed;
- Indsamling af telemetri ved hjælp af sporing, metrics og Grafana.
Series of articles on service meshes and Istio
Prøv selv
This series of posts does not aim to provide a deep dive into the world of Istio. We simply want to introduce you to the concept itself and maybe inspire you to try Istio. You can do this completely for free, and Red Hat provides all the necessary tools to start exploring OpenShift, Kubernetes, Linux containers, and Istio, namely: , and other resources on our . Don't delay, start today!
Istio Routing Rules: directing service requests where needed
og are great at ensuring requests to are routed to the right pods. This is one of the goals of Kubernetes – routing and load balancing. What if you need more nuanced and sophisticated routing? For instance, to use two versions of a microservice simultaneously? How will Istio Route Rules help here?
Routing rules are the rules that determine the route selection. Regardless of the complexity level of the system, the general principle of how these rules work remains simple: requests are routed based on certain parameters and HTTP header values.
Let's look at some examples:
Kubernetes default: trivial '50-50'
In our example, we will show how to simultaneously use two versions of a microservice in OpenShift, which we will call v1 and v2. Each version runs in its own Kubernetes pod, and by default, there is evenly balanced round-robin routing in place. Each pod receives its share of requests based on the number of its microservice instances, in other words, replicas. Istio allows you to manually change this balance.
Let's say we deployed two versions of our recommendation service on OpenShift, recommendation-v1 and recommendation-v2.
In Fig. 1, you can see that when each service is represented by a single instance, requests alternate evenly between them: 1-2-1-2-… This is how Kubernetes routing works by default:
Weighted distribution between versions
På figur 2 vises, hvad der vil ske, hvis antallet af replikaer af tjenesten v2 øges fra én til to (dette gøres med kommandoen oc scale --replicas=2 deployment/recommendation-v2). Som vi kan se, bliver anmodningerne mellem v1 og v2 nu delt i forholdet "én til tre": 1-2-2-1-2-2-…:
Ignorer versionen med Istio
Istio gør det nemt at ændre fordelingen af anmodninger, som vi ønsker. For eksempel kan vi sende al trafik kun til recommendation-v1 ved hjælp af følgende yaml-fil fra Istio:
Her skal man være opmærksom på følgende: pod’erne vælges i henhold til etiketter. I vores eksempel bruges etiketten v1. Parameteren "weight: 100" betyder, at 100% af trafikken vil blive dirigeret til alle pod’erne i tjenesten, der har etiketten v1.
Direktiv fordeling mellem versioner (Canary Deployment)
Derudover, ved at bruge parameteren weight, kan vi dirigere trafik til begge pod’er, uanset antallet af mikrotjenesteinstanser, der kører i hver af dem. For eksempel her dirigerer vi 90% af trafikken til v1 og 10% til v2:
Separat routing for mobile brugere
Afslutningsvis vil vi vise, hvordan man tvinger trafik fra mobile brugere til tjenesten v2, mens alle andre sendes til v1. For dette formål analyserer vi værdien af user-agent i anmodningsheaderen ved hjælp af regulære udtryk:
Nu er det din tur
Eksemplet med regulære udtryk til analyse af headers skal motivere dig til at finde dine egne måder at anvende routingreglerne fra Istio. Især fordi mulighederne her er meget omfattende, da header-værdierne kan formes i applikationskoden.
Og husk, at Ops, ikke Dev
Alt, hvad vi har vist i ovenstående eksempler, gøres uden de mindste ændringer i kildekoden, bortset fra de tilfælde, hvor det er nødvendigt at danne særlige anmodningsheaders. Istio vil være nyttigt for udviklere, der for eksempel kan anvende det i testfase, såvel som for IT-systemdriftere, der vil have stor hjælp til produktion.
Så lad os gentage hovedpointen i denne serie indlæg: du skal ikke ændre noget i din kode. Der er ikke behov for at samle nye billeder eller starte nye containere. Alt dette implementeres uden for koden.
Sæt din fantasi i gang
Forestill dig de perspektiver, som analyse af overskrifter med regulære udtryk åbner. Vil du omdirigere din største kunde til en specialversion af dine ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Prøv selv
At læse om Istio, Kubernetes og OpenShift er én ting, men hvorfor ikke røre ved det hele med hænderne? Teamet har forberedt en detaljeret vejledning (på engelsk), der hjælper dig med hurtigt at mestre disse teknologier. Vejledningen er også 100% open source, så den er tilgængelig offentligt. Filen fungerer på macOS, Linux og Windows, og kildekoden findes i versioner på Java og node.js (snart vil der også være versioner på andre sprog). Bare åbn det relevante git-repositorium i din browser .
I det næste indlæg: vi løser problemer smukt
I dag har du set, hvad Istio routing-regler kan. Forestil dig nu det samme, men anvendt på fejlhåndtering. Det er netop, hvad vi vil tale om i det næste indlæg.
Kilde: habr.com
