"Fare er mit mellemnavn," plejede Austin Powers, en international mystikmand, at sige. Men det, som superagenter og efterretningstjenester holder højt, egner sig slet ikke til computertjenester, hvor kedsomhed er meget bedre end fare.
Og Istio gør sammen med OpenShift og Kubernetes implementering af mikrotjenester virkelig kedelig og forudsigelig - og det er fantastisk. Vi vil tale om dette og meget mere i det fjerde og sidste indlæg i Istio-serien.
Når kedsomheden er rigtig
I vores tilfælde opstår kedsomhed kun i slutfasen, hvor der kun er tilbage at sidde og se processen. Men for dette skal du konfigurere alt først, og en masse interessante ting venter dig her.
Når du implementerer en ny version af din software, er det værd at overveje alle muligheder for at minimere risici. At køre parallelt er en meget kraftfuld og gennemprøvet måde at teste på, og Istio giver dig mulighed for at bruge en "hemmelig tjeneste" (en skjult version af din mikrotjeneste) til at gøre dette uden at forstyrre produktionssystemet. Der er endda en særlig betegnelse for dette - "Dark Launch", som igen aktiveres af en funktion med et lige så spionnavn "trafikspejling".
Bemærk venligst, at den første sætning i det foregående afsnit bruger udtrykket "deploy" i stedet for "release". Du burde virkelig være i stand til at implementere - og selvfølgelig bruge - din mikroservice så ofte du vil. Denne service skal kunne modtage og behandle trafik, producere resultater og også skrive til logfiler og overvåge. Men samtidig skal denne service i sig selv ikke nødvendigvis frigives i produktion. Implementering og frigivelse af software er ikke altid det samme. Du kan implementere, når du vil, men frigiv kun, når du er klar.
At organisere kedsomhed er interessant
Tag et kig på følgende Istio-routing-regel, som dirigerer alle HTTP-anmodninger til microservice-anbefalingen v1 (alle eksempler taget fra ), mens de samtidig spejler dem til anbefaling v2 mikroservice:
Vær opmærksom på etiketten mirror: nederst på skærmen - det er denne, der sætter trafikspejling. Ja, så enkelt er det!
Resultatet af denne regel vil være, at dit produktionssystem (v1) vil fortsætte med at behandle indgående anmodninger, men selve anmodningerne vil blive asynkront spejlet til v2, det vil sige, at deres komplette dubletter vil gå dertil. På denne måde kan du teste v2 under virkelige forhold - på reelle data og trafik - uden at forstyrre driften af produktionssystemet på nogen måde. Gør det kedeligt at organisere test? Ja helt sikkert. Men det er gjort på en interessant måde.
Lad os tilføje drama
Bemærk venligst, at det i v2-koden er nødvendigt at sørge for situationer, hvor indgående anmodninger kan føre til dataændringer. Selve anmodningerne spejles let og gennemsigtigt, men valget af behandlingsmetode i testen er op til dig – og det er lidt bekymrende.
Lad os gentage et vigtigt punkt
Hemmelig lancering med trafikspejling (Dark Launch/Request Mirroring) kan udføres uden at påvirke koden på nogen måde.
Stof til eftertanke
Hvad hvis det sted, hvor anmodninger spejles, sender nogle af dem ikke til v1, men til v2? For eksempel én procent af alle anmodninger eller kun anmodninger fra en bestemt gruppe af brugere. Og når du allerede ser på, hvordan v2 fungerer, skal du gradvist overføre alle anmodninger til den nye version. Eller omvendt, returner alt til v1, hvis noget går galt med v2. Jeg tror, det hedder Canary Deployment. , og hvis det var af russisk oprindelse, ville det sandsynligvis indeholde en henvisning til ), og nu vil vi se nærmere på dette.
Canary Deployment i Istio: forenkling af idriftsættelse
Forsigtigt og gradvist
Essensen af Canary Deployment-implementeringsmodellen er ekstremt enkel: Når du starter en ny version af din software (i vores tilfælde en mikrotjeneste), giver du først adgang til den til en lille gruppe brugere. Hvis alt går godt, øger du langsomt denne gruppe, indtil den nye version begynder at virke, eller - hvis den ikke gør det - til sidst migrerer alle brugere til den. Ved omhyggeligt og gradvist at introducere en ny version og skifte brugere til den på en kontrolleret måde, kan du reducere risici og maksimere feedback.
Selvfølgelig forenkler Istio Canary Deployment ved at tilbyde flere gode muligheder for intelligent anmodningsruting. Og ja, alt dette kan gøres uden at røre din kildekode på nogen måde.
Filtrering af browseren
Et af de enkleste routingkriterier er browserbaseret omdirigering. Lad os sige, at du kun vil have anmodninger fra Safari-browsere om at gå til v2. Sådan gøres det:
Lad os anvende denne routingregel og derefter bruge kommandoen curl Vi vil simulere reelle anmodninger til mikrotjenesten i en løkke. Som du kan se på skærmbilledet, går de alle til v1:
Hvor er trafikken på v2? Da alle anmodninger i vores eksempel kun kom fra vores egen kommandolinje, eksisterer den simpelthen ikke. Men vær opmærksom på de nederste linjer på skærmen ovenfor: dette er en reaktion på det faktum, at vi udførte en anmodning fra Safari-browseren, som igen producerede dette:
Ubegrænset kraft
Vi har allerede skrevet, at regulære udtryk giver meget kraftfulde muligheder for at dirigere anmodninger. Tag et kig på følgende eksempel (vi tror, du vil forstå, hvad det gør):
Nu har du sikkert en idé om, hvad regulære udtryk kan.
Opfør smart
Smart routing, især behandling af pakkeheadere ved hjælp af regulære udtryk, giver dig mulighed for at styre trafikken, som du vil. Og dette forenkler implementeringen af ny kode i høj grad - det er enkelt, det kræver ikke at ændre selve koden, og om nødvendigt kan alt hurtigt returneres, som det var.
Interesseret?
Er du ivrig efter at eksperimentere med Istio, Kubernetes og OpenShift på din computer? Hold forberedt en fremragende om dette emne og gjorde alle de medfølgende filer offentligt tilgængelige. Så gå videre og fornægt dig selv ikke noget.
Istio Egress: Udgang gennem souvenirbutikken
Ved at bruge Istio sammen med Red Hat OpenShift og Kubernetes kan du gøre dit liv med mikrotjenester meget nemmere. Istios service mesh er skjult inde i Kubernetes pods, og din kode kører (for det meste) isoleret. Ydeevne, let at skifte, sporing osv. – alt dette er nemt at bruge takket være brugen af sidevognscontainere. Men hvad nu hvis din mikrotjeneste skal kommunikere med andre tjenester, der er placeret uden for dit OpenShift-Kubernetes-system?
Det er her Istio Egress kommer til undsætning. I en nøddeskal giver det dig simpelthen adgang til ressourcer (læs: "tjenester"), der ikke er en del af dit system af Kubernetes-pods. Hvis du ikke udfører yderligere konfiguration, rutes trafik i Istio Egress-miljøet kun inden for en klynge af pods og mellem sådanne klynger baseret på interne IP-tabeller. Og sådan forpupning fungerer fantastisk, så længe du ikke har brug for adgang til tjenester udefra.
Egress giver dig mulighed for at omgå ovenstående IP-tabeller, enten baseret på Egress-regler eller på en række IP-adresser.
Lad os sige, at vi har et Java-program, der sender en GET-anmodning til httpbin.org/headers.
(httpbin.org er blot en praktisk ressource til at teste udgående serviceanmodninger).
Hvis du indtaster på kommandolinjen curl http://httpbin.org/headers, vil vi se følgende:
Eller du kan åbne den samme adresse i browseren:
Som du kan se, returnerer tjenesten, der er placeret der, blot de overskrifter, der er sendt til den.
Vi udskifter importen direkte
Lad os nu tage Java-koden til denne tjeneste, eksternt i forhold til vores system, og køre den på egen hånd, hvor Istio er installeret. (Du kan selv gøre dette ved at kontakte .) Efter at have bygget det passende billede og lanceret det på OpenShift-platformen, kalder vi denne tjeneste med kommandoen curl egresshttpbin-istioegress.$(minishift ip).nip.io, hvorefter vi vil se dette på skærmen:
Ups, hvad skete der? Alt fungerede bare. Hvad betyder Ikke fundet? Vi gjorde det bare for ham curl.
Udvidelse af IP-tabeller til hele internettet
Istio skal bebrejdes (eller takkes) for dette. Når alt kommer til alt, er Istio bare sidevognscontainere, der er ansvarlige for detektion og routing (og en masse andre ting, som vi talte om tidligere). Af denne grund ved IP-tabeller kun, hvad der er inde i dit klyngesystem. Og httpbin.org er placeret udenfor og derfor utilgængeligt. Og det er her Istio Egress kommer til undsætning – uden den mindste ændring af din kildekode.
Egress-reglen nedenfor tvinger Istio til at søge (om nødvendigt, så på hele internettet) efter den påkrævede tjeneste, i dette tilfælde httpbin.org. Som du kan se fra denne fil (egress_httpbin.yml), er funktionaliteten her ganske enkel:
Tilbage er blot at anvende denne regel:
istioctl create -f egress_httpbin.yml -n istioegress
Du kan se udgående regler med kommandoen istioctl get egressrules:
Og til sidst kører vi kommandoen igen krølle – og vi ser, at alt fungerer:
Vi tænker åbent
Som du kan se, giver Istio dig mulighed for at organisere interaktion med omverdenen. Med andre ord kan du stadig oprette OpenShift-tjenester og administrere dem gennem Kubernetes, og holde alt i pods, der skaleres op og ned efter behov. Og samtidig kan du sikkert få adgang til tjenester uden for dit miljø. Og ja, vi gentager endnu en gang, at alt dette kan gøres uden at røre din kode på nogen måde.
Dette var det sidste indlæg i serien på Istio. Følg med - der er mange interessante ting forude!
Kilde: www.habr.com