Vi startar en serie inlägg som visar upp några av de många funktionerna i Istio Service Mesh i kombination med Red Hat OpenShift och Kubernetes.
Del ett, idag:
- Låt oss förklara konceptet med Kubernetes sidovagnscontainrar och formulera ledmotivet i denna serie av inlägg: "du behöver inte ändra något i din kod".
- Låt oss introducera det grundläggande med Istio - routingregler. Alla andra Istio-funktioner är byggda på dem, eftersom det är reglerna som gör att du kan dirigera trafik till mikrotjänster med hjälp av YAML-filer utanför tjänstkoden. Vi överväger också implementeringsschemat för Canary Deployment. Nyårsbonus – 10 interaktiva lektioner på Istio
Del två, som kommer snart, kommer att berätta:
- Hur Istio implementerar Pool Ejection i kombination med Circuit Breaker och kommer att visa hur Istio låter dig ta bort en död eller dåligt presterande pod från balanseringskretsen.
- Vi kommer också att titta på Circuit Breaker-ämnet från det första inlägget för att se hur Istio kan användas här. Vi kommer att visa dig hur du dirigerar trafik och hanterar nätverksfel med hjälp av YAML-konfigurationsfiler och terminalkommandon utan de minsta ändringar i servicekoden.
Del tre:
- En berättelse om spårning och övervakning, som redan är inbyggda eller enkelt läggas till Istio. Vi visar dig hur du använder verktyg som Prometheus, Jaeger och Grafana i kombination med OpenShift-skalning för att enkelt hantera mikrotjänstarkitekturer.
- Vi går från att övervaka och hantera fel till att avsiktligt införa dem i systemet. Vi lär oss med andra ord hur man gör felinjektion utan att ändra källkoden, vilket är väldigt viktigt ur testsynpunkt – eftersom om man ändrar själva koden för detta så finns det risk för att ytterligare fel introduceras.
Slutligen, i det sista inlägget på Istio Service Mesh:
- Låt oss gå till den mörka sidan. Mer exakt kommer vi att lära oss att använda Dark Launch-schemat, när koden distribueras och testas direkt på produktionsdata, men inte påverkar systemets funktion på något sätt. Det är här Istios förmåga att dela trafik kommer väl till pass. Och möjligheten att testa på liveproduktionsdata utan att påverka stridssystemets funktion på något sätt är den mest övertygande metoden för verifiering.
- Med utgångspunkt i Dark Launch kommer vi att visa dig hur du använder Canary Deployment-modellen för att minska riskerna och göra det lättare att få ny kod i produktion. Canary Deployment i sig är långt ifrån nytt, men Istio låter dig implementera detta schema med bara enkla YAML-filer.
- Slutligen kommer vi att visa dig hur du använder Istio Egress för att ge tillgång till tjänster till de som befinner sig utanför dina kluster för att kunna använda Istios möjligheter när du arbetar med Internet.
Nu kör vi...
Istio övervaknings- och hanteringsverktyg - allt du behöver för att orkestrera mikrotjänster i ett servicenät .
Vad är Istio Service Mesh
Ett servicenät implementerar funktioner som trafikövervakning, åtkomstkontroll, upptäckt, säkerhet, feltolerans och andra användbara saker för en grupp tjänster. Istio låter dig göra allt detta utan de minsta ändringar i koden för själva tjänsterna. Vad är magins hemlighet? Istio kopplar sin egen proxy till varje tjänst i form av en sidvagnscontainer (sidovagn är en motorcykelsidovagn), varefter all trafik till denna tjänst går via proxyn, som, guidad av specificerade policyer, avgör hur, när och om denna trafik bör nå tjänsten överhuvudtaget. Istio gör det också möjligt att implementera avancerade DevOps-tekniker som kanariefågel-utbyggnader, strömbrytare, felinjektion och många andra.
Hur Istio fungerar med behållare och Kubernetes
Istio-servicenätet är en sidovagnsimplementering av allt som krävs för att skapa och hantera mikrotjänster: övervakning, spårning, strömbrytare, routing, lastbalansering, felinjektion, återförsök, timeouts, spegling, åtkomstkontroll, hastighetsbegränsning och mycket mer. annat. Och även om det idag finns massor av bibliotek för att implementera dessa funktioner direkt i kod, kan du med Istio få samma saker utan att ändra något i din kod.
Enligt sidovagnsmodellen kör Istio i en Linux-container, som ligger i en -pod med en kontrollerad tjänst och injicerar och extraherar funktionalitet och information enligt den givna konfigurationen. Vi betonar att detta är din egen konfiguration, och den lever utanför din kod. Därför blir koden mycket enklare och kortare.
Vad som också är viktigt är att den operativa komponenten i mikrotjänster inte visar sig vara på något sätt kopplad till själva koden, vilket innebär att deras drift säkert kan överföras till IT-specialister. Ja, varför ska utvecklaren vara ansvarig för strömbrytare och felinsprutning? Reagera, ja, men bearbeta dem och skapa dem? Om du tar bort allt detta från koden kommer programmerare att kunna fokusera fullt ut på applikationsfunktionalitet. Och själva koden blir kortare och enklare.
Servicenät
Istio, som implementerar funktioner för att hantera mikrotjänster utanför sin kod, är konceptet med ett Service Mesh. Med andra ord är det en koordinerad grupp av en eller flera binärer som bildar ett nät av nätverksfunktioner.
Hur Istio fungerar med mikrotjänster
Så här ser arbetet med sidovagnscontainrar ut i samband med и fågelperspektiv: starta en instans av Minishift, skapa ett projekt för Istio (låt oss kalla det "istio-system"), installera och kör alla Istio-relaterade komponenter. Sedan, när du skapar projekt och poddar, lägger du till konfigurationsinformation till dina distributioner, och dina poddar börjar använda Istio. Ett förenklat diagram ser ut så här:
Nu kan du ändra Istio-inställningar för att till exempel organisera felinjektion, support eller andra Istio-funktioner - och allt detta utan att röra koden för själva applikationerna. Låt oss säga att du vill omdirigera all webbtrafik från användare av din största klient (Foo Corporation) till en ny version av webbplatsen. För att göra detta, skapa helt enkelt en Istio-routningsregel som letar efter @foocorporation.com i användar-ID:t och omdirigerar därefter. För alla andra användare kommer ingenting att förändras. Under tiden kommer du i lugn och ro att testa den nya versionen av sajten. Och notera, du behöver inte involvera utvecklare alls för detta.
Och kommer du att få betala dyrt för det?
Inte alls. Istio är ganska snabb och skrivs in och skapar väldigt lite overhead. Dessutom kompenseras den möjliga förlusten av onlineproduktivitet av en ökning av utvecklarnas produktivitet. Åtminstone i teorin: glöm inte att utvecklarnas tid är värdefull. När det gäller mjukvarukostnader är Istio programvara med öppen källkod, så du kan få och använda den gratis.
Bemästra det själv
Red Hat Developer Experience Team har utvecklat en djupgående hands-on av Istio (på engelska). Den körs på Linux, MacOS och Windows, och koden är tillgänglig i Java och Node.js.
10 interaktiva lektioner på Istio
Block 1 - För nybörjare
Introduktion till Istio
30 minuter
Låt oss bekanta oss med Service Mesh, lära oss hur man installerar Istio i ett OpenShift Kubernetes-kluster.
Distribuera mikrotjänster i Istio
30 minuter
Vi använder Istio för att distribuera tre mikrotjänster med Spring Boot och Vert.x.
Block 2 – mellannivå
Övervakning och spårning i Istio
60 minuter
Vi kommer att utforska Istios inbyggda övervakningsverktyg, anpassade mätvärden och OpenTracing via Prometheus och Grafana.
Enkel routing i Istio
60 minuter
Lär dig hur du hanterar routing i Istio med enkla regler.
Avancerade ruttregler
60 minuter
Låt oss ta en titt på Istios smarta routing, passerkontroll, lastbalansering och hastighetsbegränsning.
Block 3 – avancerad användare
Felinsprutning i Istio
60 minuter
Vi studerar felhanteringsscenarier i distribuerade applikationer, skapar HTTP-fel och nätverksfördröjningar och lär oss att använda kaosteknik för att återställa miljön.
Strömbrytare i Istio
30 minuter
Vi installerar Siege för stresstestplatser och lär oss hur man säkerställer backend-feltolerans med hjälp av repriser, strömbrytare och poolutkastning.
Egress och Istio
10 minuter
Vi använder Egress-rutter för att skapa regler för interaktionen mellan interna tjänster och externa API:er och tjänster.
Istio och Kiali
15 minuter
Lär dig att använda Kiali för att få en överblick över tjänstens mesh och utforska förfrågnings- och dataflöden.
Ömsesidig TLS i Istio
15 minuter
Vi skapar Istio Gateway och VirtualService, sedan studerar vi ömsesidig TLS (mTLS) och dess inställningar i detalj.
Block 3.1 - Deep Dive: Istio Service Mesh för mikrotjänster
Vad handlar boken om:
- Vad är ett servicenät?
- Istio-systemet och dess roll i mikrotjänstarkitektur.
- Använda Istio för att lösa följande problem:
- Feltolerans;
- Routing;
- Kaostestning;
- säkerhet;
- Telemetriinsamling med hjälp av spår, mätvärden och Grafana.
Artikelserie om servicenät och Istio
Prova själv
Denna serie av inlägg är inte avsedd att ge en djupdykning i Istios värld. Vi vill bara introducera dig för konceptet och kanske inspirera dig att prova Istio själv. Det är helt gratis att göra, och Red Hat tillhandahåller alla verktyg du behöver för att komma igång med OpenShift, Kubernetes, Linux-behållare och Istio, inklusive: , och andra resurser på vår . Dröj inte, börja idag!
Istio-dirigeringsregler: dirigera serviceförfrågningar dit de behöver gå
и gör ett utmärkt jobb med att ta itu med dirigeras till de nödvändiga kapslarna. Detta är en av anledningarna till existensen av Kubernetes - routing och lastbalansering. Men vad händer om du behöver mer subtil och sofistikerad routing? Till exempel att samtidigt använda två versioner av en mikrotjänst. Hur kan Istio-ruttreglerna hjälpa här?
Rutningsregler är de regler som faktiskt bestämmer valet av väg. Oavsett nivån på systemets komplexitet förblir den allmänna driftsprincipen för dessa regler enkel: förfrågningar dirigeras baserat på vissa parametrar och HTTP-huvudvärden.
Låt oss titta på exempel:
Kubernetes standard: trivialt "50/50"
I vårt exempel kommer vi att visa hur man samtidigt använder två versioner av en mikrotjänst i OpenShift, låt oss kalla dem v1 och v2. Varje version körs i sin egen Kubernetes-pod, och som standard kör den jämnt balanserad round robin-routing. Varje pod får sin andel av förfrågningar baserat på antalet mikrotjänstinstanser, med andra ord repliker. Istio låter dig ändra detta saldo manuellt.
Låt oss säga att vi distribuerade två versioner av vår rekommendationstjänst på OpenShift, rekommendation-v1 och rekommendation-v2.
I fig. Figur 1 visar att när varje tjänst representeras i en instans, växlar förfrågningar jämnt mellan dem: 1-2-1-2-... Så här fungerar Kubernetes-routing som standard:
Viktad fördelning mellan versioner
I fig. Figur 2 visar vad som händer om du ökar antalet v2-tjänstreplikor från en till två (detta görs med kommandot oc-skalan —replicas=2 deployment/recommendation-v2). Som du kan se är förfrågningar mellan v1 och v2 nu uppdelade i ett ett-till-tre-förhållande: 1-2-2-1-2-2-...:
Ignorera version med Istio
Istio gör det enkelt att ändra fördelningen av förfrågningar på det sätt vi behöver. Skicka till exempel all trafik endast till rekommendation-v1 med följande Istio yaml-fil:
Här måste du vara uppmärksam på detta: pods väljs enligt etiketterna. Vårt exempel använder etikett v1. Parametern "weight: 100" betyder att 100 % av trafiken kommer att dirigeras till alla servicepods som har v1-etiketten.
Direktivdistribution mellan versioner (Canary Deployment)
Därefter, med hjälp av viktparametern, kan du dirigera trafik till båda poddarna och ignorera antalet mikrotjänstinstanser som körs i var och en av dem. Här riktar vi till exempel 90 % av trafiken till v1 och 10 % till v2:
Separat routing för mobilanvändare
Avslutningsvis kommer vi att visa hur man tvingar mobilanvändartrafik att dirigeras till tjänst v2 och alla andra till v1. För att göra detta använder vi reguljära uttryck för att analysera user-agent-värdet i förfrågningshuvudet:
Nu är det din tur
Exemplet med reguljära uttryck för att tolka rubriker bör motivera dig att hitta din egen användning av Istio routingregler. Dessutom är möjligheterna här ganska omfattande, eftersom rubrikvärden kan bildas i applikationens källkod.
Och kom ihåg att Ops, inte Dev
Allt som vi visade i exemplen ovan görs utan de minsta ändringar i källkoden, ja, förutom de fall då det är nödvändigt att generera speciella förfrågningshuvuden. Istio kommer att vara användbart både för utvecklare, som till exempel kommer att kunna använda det i teststadiet, och för specialister på drift av IT-system, för vilka det kommer att vara till stor hjälp i produktionen.
Så låt oss upprepa ledmotivet i denna serie av inlägg: du behöver inte ändra något i din kod. Det finns inget behov av att bygga nya bilder eller lansera nya behållare. Allt detta implementeras utanför koden.
Använd din fantasi
Föreställ dig bara möjligheterna med rubrikanalys med hjälp av reguljära uttryck. Vill du omdirigera din största kund till en specialversion av din ? Lätt! Behöver du en separat version för webbläsaren Chrome? Inga problem! Du kan dirigera trafik enligt nästan vilken egenskap som helst.
Prova själv
Att läsa om Istio, Kubernetes och OpenShift är en sak, men varför inte röra allt själv? Team har utarbetat en detaljerad guide (på engelska) som hjälper dig att bemästra dessa tekniker så snabbt som möjligt. Manualen är också 100% öppen källkod, så den är publicerad i det offentliga området. Filen fungerar på macOS, Linux och Windows, och källkoden är tillgänglig i Java- och node.js-versioner (versioner på andra språk kommer snart). Öppna bara motsvarande git-förråd i din webbläsare .
I nästa inlägg: vi löser problem vackert
Idag såg du vad Istio routingregler kan göra. Föreställ dig nu samma sak, men bara i förhållande till felhantering. Det är precis vad vi kommer att prata om i nästa inlägg.
Källa: will.com