Vi inleder en serie inlägg där vi kommer att demonstrera några av de många funktionerna i Istio Service Mesh i kombination med Red Hat OpenShift och Kubernetes.
Del ett, idag:
- Vi förklarar konceptet med sidecar-containrar i Kubernetes och formulerar temat för denna serie inlägg: «du behöver inte ändra något i din kod».
- Låt oss presentera den grundläggande funktionen i Istio – routingregler. Dessa utgör basen för alla andra funktioner i Istio, eftersom det är reglerna som gör det möjligt att dirigera trafik till mikroservicer med hjälp av externa YAML-filer. Vi kommer också att titta på implementeringen av Canary Deployment. Nyårsbonus: 10 interaktiva lektioner om Istio.
Del två, som snart kommer att publiceras, kommer att berätta för dig:
- Hur Istio implementerar Pool Ejection i kombination med Circuit Breaker och demonstrerar hur Istio tillåter oss att ta bort en icke-fungerande eller dåligt fungerande pod från lastbalanseringen.
- Vi kommer också att titta på Circuit Breaker-temat från första inlägget för att se hur Istio kan användas här. Vi kommer att visa hur man dirigerar trafik och hanterar nätverksfel utan att göra några förändringar i tjänsternas kod, med hjälp av YAML-konfigurationsfiler och terminalkommandon.
Del tre:
- Berättelsen om spårning och övervakning som redan är inbyggda eller enkelt kan läggas till i Istio. Vi kommer att visa hur man använder verktyg som Prometheus, Jaeger och Grafana i kombination med OpenShifts skalbarhet för att effektivt hantera en mikroservicearkitektur.
- Vi går från övervakning och felhantering till att medvetet introducera fel i systemet. Med andra ord, vi lär oss att göra fault injection utan att ändra koden, vilket är mycket viktigt ur ett testperspektiv – eftersom riskerna för att införa ytterligare fel ökar om vi ändrar koden.
Till slut, i det avslutande inlägget om Istio Service Mesh:
- Vi går över till den Mörka Sidan. Närmare bestämt kommer vi att lära oss att använda Dark Launch-konceptet, där koden deployeras och testas direkt på produktionsdata utan att påverka systemets funktion. Här blir Istios trafikdelningsförmåga mycket användbar. Att kunna testa på levande produktionsdata utan att påverka det aktiva systemet är det mest övertygande sättet att verifiera.
- Med utgångspunkt från Dark Launch visar vi hur man använder modellen Canary Deployment för att minska riskerna och förenkla införandet av ny kod. Själva Canary Deployment är ingen nyhet, men Istio möjliggör denna metod med hjälp av enkla YAML-filer.
- Till sist visar vi hur man med Istio Egress ger åtkomst till tjänster för dem som befinner sig utanför dina kluster, för att utnyttja Istios möjligheter vid arbete med internet.
Så, låt oss börja…
Istios övervaknings- och hanteringsverktyg – allt som behövs för att samordna mikrotjänster i en tjänstenätverk. .
Vad är Istio tjänstenätverk?
Tjänstenätverket implementerar funktioner som övervakning av trafik, åtkomstkontroll, upptäckte, säkerhet, felresistens och andra användbara saker för en grupp av tjänster. Istio gör allt detta utan minsta ändring i själva tjänsternas kod. Vad är hemligheten? Istio kopplar varje tjänst med sin egen proxy i form av en sidecar-container, och därefter går all trafik till denna tjänst genom proxyn, som baserat på angivna policyer avgör hur, när och om trafiken ska nå tjänsten. Istio ger också möjligheter att implementera avancerade DevOps-tekniker, såsom canary deployments, circuit breakers, felinjektion och många fler.
Hur fungerar Istio med containrar och Kubernetes?
Istios tjänstenätverk är en sidecar-implementering av allt som behövs för att skapa och hantera mikrotjänster: övervakning, spårning, circuit breakers, routing, lastbalansering, felinjektion, omförsök, tidsgränser, spegling, åtkomstkontroll, hastighetsbegränsning och mycket mer. Och även om det idag finns många bibliotek för att implementera dessa funktioner direkt i koden, kan du med Istio få allt detta utan att ändra din kod.
Enligt sidecar-modellen körs Istio i en Linux-container som finns i samma -pod som den kontrollerade tjänsten och injicerar (inject) och extraherar (extract) funktionalitet och information enligt angiven konfiguration. Vi betonar att det ä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 av mikrotjänster inte är kopplad till själva koden, vilket innebär att deras drift kan överlämnas till IT-specialister. Faktiskt, varför ska utvecklaren ansvara för circuit breakers och fault injection? Att reagera – ja, men att hantera och skapa dem? Om allt detta tas bort från koden kan programmerarna helt fokusera på applikationsfunktionalitet. Dessutom blir själva koden kortare och enklare.
Tjänstenätverk
Istio, som implementerar funktioner för att hantera mikrotjänster utanför deras kod – det är konceptet för tjänstenätverk, Service Mesh. Med andra ord är det en koordinerad grupp av en eller flera binärfiler som bildar ett nätverksfunktionernas nätverk.
Hur Istio fungerar med mikrotjänster
Så här ser arbetet med sidecar-containrar ut i samverkan med och från fågelperspektiv: du startar en instans av Minishift, skapar ett projekt för Istio (låt oss kalla det "istio-system"), installerar och startar alla relaterade komponenter till Istio. Sedan, i takt med att du skapar projekt och pods, lägger du till konfigurationsinformation i dina deploymentar, och dina pods börjar använda Istio. Förenklat ser diagrammet ut så här:
Nu kan du ändra inställningarna i Istio för att, till exempel, organisera fault injection, stödja eller andra funktioner i Istio – och allt detta utan att röra koden i själva applikationerna. Anta att du vill omdirigera all webbtrafik från användarna av din största kund (Foo Corporation) till den nya versionen av webbplatsen. För detta räcker det med att skapa en Istio-routingregel som söker efter @foocorporation.com i användaridentifieraren och utför den motsvarande omdirigeringen. För alla andra användare förändras ingenting. Under tiden kan du lugnt testa den nya versionen av webbplatsen. Och märk, för detta behöver du inte involvera utvecklarna.
Och kommer det att kosta mycket?
Inte alls. Istio fungerar ganska snabbt, det är skrivet på och skapar en mycket liten overhead. Dessutom kompenseras den potentiella förlusten i onlineprestanda med en ökning av utvecklarnas produktivitet. Åtminstone i teorin: kom ihåg att utvecklarnas tid är dyr. När det gäller kostnader för programvara är Istio en mjukvara med öppen källkod, så den kan fås och användas gratis.
Lär dig själv
Red Hat Developer Experience Team har utvecklat en djupgående praktisk om Istio (på engelska). Den fungerar på Linux, MacOS och Windows, och koden finns i versioner för Java och Node.js.
10 interaktiva lektioner om Istio
Block 1 – För Nybörjare
Introduktion till Istio
30 minuter
Låt oss bekanta oss med Service Mesh, lär oss att installera Istio i Kubernetes-klustret OpenShift.
Distribuering av 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 – Medelnivå
Övervakning och spårning i Istio
60 minuter
Vi studerar de inbyggda övervakningsverktygen i Istio, anpassningsbara metrik, samt OpenTracing via Prometheus och Grafana.
Enkel routning i Istio
60 minuter
Vi lär oss att hantera routning i Istio med hjälp av enkla regler.
Avancerade regler för routning
60 minuter
Vi bekantar oss med smart routning i Istio, åtkomsthantering, lastbalansering och hastighetsbegränsning.
Block 3 – Expertanvändare
Felinjektion i Istio
60 minuter
Vi studerar felhanteringsscenarier i distribuerade applikationer, skapar HTTP-fel och nätverksförseningar, och lär oss att tillämpa kaosteori för att återhämta miljön.
Circuit Breaker i Istio
30 minuter
Vi installerar Siege för stresstestning av webbplatser och lär oss att säkerställa backendens motståndskraft med hjälp av upprepningar, circuit breaker och poolutsläpp.
Egress och Istio
10 minuter
Vi använder Egress-rutter för att skapa regler för hur interna tjänster interagerar med externa API:er och tjänster.
Istio och Kiali
15 minuter
Vi lär oss att använda Kiali för att få en helhetsbild av tjänstemodellen samt att undersöka flöden av förfrågningar och data.
Mutual TLS i Istio
15 minuter
Vi skapar Istio Gateway och VirtualService, och undersöker sedan noggrant mutual TLS (mTLS) och dess konfigurationer.
Block 3.1 – Djupdykning: Istio Service Mesh för mikrotjänster
Vad handlar boken om:
- Vad är en service mesh.
- Systemet Istio och dess roll i mikrotjänstarkitektur.
- Användning av Istio för att lösa följande uppgifter:
- Felsäkerhet;
- Routning;
- Kaostestning;
- Säkerhet;
- Insamling av telemetri med hjälp av spårning, metrik och Grafana.
Serie av artiklar om tjänstenätverk och Istio
Prova själv
Denna serie inlägg syftar inte till att ge en djupgående förståelse för Istio. Vi vill bara introducera dig till själva konceptet och kanske inspirera dig att själv prova Istio. Det kan göras helt gratis, och Red Hat tillhandahåller alla nödvändiga verktyg för att börja bemästra OpenShift, Kubernetes, Linux-containrar och Istio, nämligen: , och andra resurser på vår . Vänta inte, börja redan idag!
Routingregler för Istio: vi dirigerar tjänstförfrågningar dit de behövs
och hanterar utmärkt att dirigera förfrågningar till och dirigeras till rätt poddar. Detta är en av huvudmålen med Kubernetes – routing och lastbalansering. Men vad händer om du behöver mer finjusterad och sofistikerad routing? Till exempel, för att samtidigt använda två versioner av en mikrotjänst. Hur kan Istios routingregler hjälpa här?
Routingregler är de regler som fastställer valet av rutt. Oavsett systemets komplexitetsnivå förblir den övergripande principen för dessa regler enkel: förfrågningar dirigeras baserat på specifika parametrar och värden i HTTP-huvuden.
Låt oss titta på exempel:
Kubernetes standard: trivial "50-50"
I vårt exempel visar vi hur man anonymt använder två versioner av en mikrotjänst i OpenShift, som vi kallar v1 och v2. Varje version körs i sin egen Kubernetes-podd, och som standard används en jämnt balanserad rond robin-routing. Varje pod får sin andel av förfrågningarna baserat på antalet instanser av sin mikrotjänst, med andra ord, repliker. Istio tillåter dock att manuellt ändra denna balans.
Antag att vi har distribuerat två versioner av vår rekommendationstjänst på OpenShift, recommendation-v1 och recommendation-v2.
I figur 1 kan vi se att när varje tjänst representeras av ett enda exempel, så alternerar förfrågningarna jämnt mellan dem: 1-2-1-2-… Detta är hur Kubernetes-routing fungerar som standard:
Viktat fördelning mellan versionerna
I bild 2 visas vad som händer om antalet repliker av tjänsten v2 ökas från en till två (detta görs med kommandot oc scale —replicas=2 deployment/recommendation-v2). Som vi ser delas förfrågningar mellan v1 och v2 nu i förhållande "ett till tre": 1-2-2-1-2-2-…:
Ignorera versionen med Istio
Istio gör det enkelt att ändra fördelningen av förfrågningar på det sätt vi önskar. Till exempel för att skicka all trafik enbart till recommendation-v1 med följande yaml-fil i Istio:
Här måste vi lägga märke till följande: poddar väljs enligt etiketter. I vårt exempel används etiketten v1. Parametern "weight: 100" innebär att 100 % av trafiken kommer att dirigeras till alla poddar av tjänsten som har etiketten v1.
Direktiv fördelning mellan versioner (Canary Deployment)
Vidare kan vi använda parameter weight för att styra trafiken till båda poddarna, oavsett antalet instanser av mikrotjänster som körs i var och en av dem. Här dirigerar vi till exempel 90 % av trafiken till v1 och 10 % till v2:
Separat dirigering av mobilanvändare
Avslutningsvis visar vi hur man tvingar att dirigera trafik från mobilanvändare till tjänst v2, medan alla andra går till v1. För detta analyserar vi med hjälp av reguljära uttryck värdet av user-agent i förfrågans header:
Nu är det din tur
Exemplet med reguljära uttryck för analys av headers bör motivera dig att söka efter egna alternativ för tillämpning av Istios riktlinjer för dirigering. Än mer eftersom möjligheterna är ganska omfattande, för hela header-värden kan formas i applikationens källkod.
Och kom ihåg, det handlar om Ops, inte Dev
Allt vi har visat i de ovanstående exemplen kan göras utan minsta ändringar i källkoden, förutom i de fall där särskilda headers måste skapas. Istio kommer att vara till nytta för både utvecklare som till exempel kan använda det under testningen, samt IT-driftspecialister som mycket kommer att dra nytta av det i produktionen.
Så vi upprepar huvudmotivet i denna serie av inlägg: du behöver inte ändra något i din kod. Du behöver inte bygga nya bilder eller starta nya containrar. Allt detta implementeras utanför koden.
Släpp lös din fantasi
Tänk dig vilket potential analysen av rubriker med hjälp av reguljära uttryck kan öppna. Vill du omdirigera din största kund till en specialversion av din ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Prova själv
Att läsa om Istio, Kubernetes och OpenShift är en sak, men varför inte prova alla själv? Teamet har förberett en detaljerad guide (på engelska) som hjälper dig att snabbt få en djup förståelse för dessa teknologier. Guiden är också 100% open source, så den är tillgänglig för allmänheten. Filen fungerar på macOS, Linux och Windows, och källkoden finns i versioner för Java och node.js (snart kommer det versioner för andra språk). Öppna bara den aktuella git-repositoriet i din webbläsare .
I nästa inlägg: Vi löser problem på ett snyggt sätt
Idag har du sett vad Istios routingregler kan åstadkomma. Tänk nu dig samma sak, men applicerat på felhantering. Det är just det vi kommer att berätta om i nästa inlägg.
Källa: habr.com
