"Fara är mitt mellannamn," brukade Austin Powers, en internationell man av mystik, säga. Men det som hålls högt av superagenter och underrättelsetjänster lämpar sig inte alls för datatjänster, där tristess är mycket bättre än fara.
Och Istio, tillsammans med OpenShift och Kubernetes, gör implementeringen av mikrotjänster verkligt tråkig och förutsägbar – och det är bra. Vi kommer att prata om detta och mycket mer i det fjärde och sista inlägget i Istio-serien.
När tristess är rätt
I vårt fall uppstår tristess först i slutfasen, när allt som återstår är att sitta och titta på processen. Men för detta måste du konfigurera allt först, och många intressanta saker väntar dig här.
När du distribuerar en ny version av din programvara är det värt att överväga alla alternativ för att minimera riskerna. Att köra parallellt är ett mycket kraftfullt och beprövat sätt att testa, och Istio låter dig använda en "hemlig tjänst" (en dold version av din mikrotjänst) för att göra detta utan att störa produktionssystemet. Det finns till och med en speciell term för detta - "Dark Launch", som i sin tur aktiveras av en funktion med ett lika spionnamn "trafikspegling".
Observera att den första meningen i föregående stycke använder termen "deploy" snarare än "release". Du borde verkligen kunna distribuera – och naturligtvis använda – din mikrotjänst så ofta du vill. Denna tjänst måste kunna ta emot och bearbeta trafik, producera resultat och även skriva till loggar och övervaka. Men samtidigt behöver den här tjänsten i sig inte nödvändigtvis släppas i produktion. Att distribuera och släppa programvara är inte alltid samma sak. Du kan distribuera när du vill, men släpp bara när du är redo.
Att organisera tristess är intressant
Ta en titt på följande Istio-routingregel, som dirigerar alla HTTP-förfrågningar till mikrotjänstrekommendationen v1 (alla exempel hämtade från ), samtidigt som de speglar dem till rekommendationen v2 mikrotjänst:
Var uppmärksam på etiketten mirror: längst ner på skärmen - det är denna som ställer in trafikspegling. Ja, så enkelt är det!
Resultatet av denna regel blir att ditt produktionssystem (v1) kommer att fortsätta att behandla inkommande förfrågningar, men själva förfrågningarna kommer att speglas asynkront till v2, det vill säga deras fullständiga dubbletter kommer att gå dit. På så sätt kan du testa v2 i verkliga förhållanden - på verklig data och trafik - utan att på något sätt störa driften av produktionssystemet. Gör detta det tråkigt att organisera tester? Ja definitivt. Men det är gjort på ett intressant sätt.
Låt oss lägga till dramatik
Observera att det i v2-koden är nödvändigt att ta hänsyn till situationer där inkommande förfrågningar kan leda till dataändringar. Själva förfrågningarna speglas enkelt och transparent, men valet av bearbetningsmetod i testet är upp till dig – och detta är lite oroande.
Låt oss upprepa en viktig punkt
Hemlig lansering med trafikspegling (Dark Launch/Request Mirroring) kan utföras utan att koden påverkas på något sätt.
Något att tänka på
Vad händer om platsen där förfrågningar speglas skickar några av dem inte till v1, utan till v2? Till exempel en procent av alla förfrågningar eller endast förfrågningar från en viss grupp användare. Och sedan, redan när du tittar på hur v2 fungerar, överför du gradvis alla förfrågningar till den nya versionen. Eller vice versa, returnera allt till v1 om något går fel med v2. Jag tror att det heter Canary Deployment. , och om det var av ryskt ursprung skulle det förmodligen innehålla en hänvisning till ), och nu ska vi titta på detta mer i detalj.
Canary Deployment i Istio: förenkling av driftsättningen
Försiktigt och gradvis
Kärnan i implementeringsmodellen för Canary Deployment är extremt enkel: när du lanserar en ny version av din programvara (i vårt fall en mikrotjänst) ger du först åtkomst till den till en liten grupp användare. Om allt går bra ökar du långsamt den här gruppen tills den nya versionen börjar fungera, eller - om den inte gör det - så småningom migrera alla användare till den. Genom att eftertänksamt och gradvis introducera en ny version och byta användare till den på ett kontrollerat sätt kan du minska riskerna och maximera feedbacken.
Naturligtvis förenklar Istio Canary Deployment genom att erbjuda flera bra alternativ för intelligent förfrågningsdirigering. Och ja, allt detta kan göras utan att röra din källkod på något sätt.
Filtrera webbläsaren
Ett av de enklaste ruttkriterierna är webbläsarbaserad omdirigering. Låt oss säga att du bara vill att förfrågningar från Safari-webbläsare ska gå till v2. Så här går det till:
Låt oss tillämpa denna routingregel och sedan använda kommandot curl Vi kommer att simulera verkliga förfrågningar till mikrotjänsten i en loop. Som du kan se på skärmdumpen går de alla till v1:
Var är trafiken på v2? Eftersom i vårt exempel alla förfrågningar bara kom från vår egen kommandorad, existerar den helt enkelt inte. Men var uppmärksam på de nedersta linjerna på skärmen ovan: detta är en reaktion på det faktum att vi körde en begäran från webbläsaren Safari, som i sin tur producerade detta:
Obegränsad kraft
Vi har redan skrivit att reguljära uttryck ger mycket kraftfulla funktioner för att dirigera förfrågningar. Ta en titt på följande exempel (vi tror att du kommer att förstå vad det gör):
Vid det här laget har du förmodligen en uppfattning om vad reguljära uttryck kan göra.
Agera smart
Smart routing, i synnerhet bearbetning av pakethuvuden med reguljära uttryck, låter dig styra trafiken som du vill. Och detta förenklar implementeringen av ny kod avsevärt - det är enkelt, det kräver inte att koden själv ändras, och vid behov kan allt snabbt returneras som det var.
Intresserad?
Är du sugen på att experimentera med Istio, Kubernetes och OpenShift på din dator? Team förberett en utmärkt om detta ämne och gjorde alla medföljande filer offentligt tillgängliga. Så fortsätt och förneka dig själv ingenting.
Istio Egress: gå ut genom souvenirbutiken
Genom att använda Istio tillsammans med Red Hat OpenShift och Kubernetes kan du göra ditt liv med mikrotjänster mycket enklare. Istios servicenät är gömt inuti Kubernetes pods, och din kod körs (för det mesta) isolerat. Prestanda, enkel förändring, spårning, etc. – allt detta är lätt att använda tack vare användningen av sidovagnscontainrar. Men vad händer om din mikrotjänst behöver kommunicera med andra tjänster som finns utanför ditt OpenShift-Kubernetes-system?
Det är här Istio Egress kommer till undsättning. I ett nötskal låter det dig helt enkelt komma åt resurser (läs: "tjänster") som inte är en del av ditt system av Kubernetes-poddar. Om du inte utför ytterligare konfiguration, dirigeras trafik i Istio Egress-miljön endast inom ett kluster av pods och mellan sådana kluster baserat på interna IP-tabeller. Och sådan puppning fungerar utmärkt så länge du inte behöver tillgång till tjänster utifrån.
Med Egress kan du kringgå ovanstående IP-tabeller, antingen baserat på Egress-regler eller på en rad IP-adresser.
Låt oss säga att vi har ett Java-program som gör en GET-förfrågan till httpbin.org/headers.
(httpbin.org är bara en praktisk resurs för att testa utgående serviceförfrågningar.)
Om du skriver in på kommandoraden curl http://httpbin.org/headers, kommer vi att se följande:
Eller så kan du öppna samma adress i webbläsaren:
Som du kan se returnerar tjänsten som finns där helt enkelt rubrikerna som skickas till den.
Vi byter ut import direkt
Låt oss nu ta Java-koden för denna tjänst, externt till vårt system, och köra den på egen hand, där, minns, Istio är installerat. (Du kan göra detta själv genom att kontakta .) Efter att ha byggt rätt bild och lanserat den på OpenShift-plattformen kommer vi att anropa denna tjänst med kommandot curl egresshttpbin-istioegress.$(minishift ip).nip.io, varefter vi kommer att se detta på skärmen:
Oj, vad hände? Allt bara fungerade. Vad betyder inte hittad? Vi gjorde det bara för honom curl.
Utöka IP-tabeller till hela Internet
Istio bör klandras (eller tackas) för detta. När allt kommer omkring är Istio bara sidovagnscontainrar som ansvarar för detektering och dirigering (och mycket annat som vi pratade om tidigare). Av denna anledning vet IP-tabeller bara vad som finns i ditt klustersystem. Och httpbin.org ligger utanför och därför otillgängligt. Och det är här Istio Egress kommer till undsättning – utan den minsta förändring av din källkod.
Egress-regeln nedan tvingar Istio att söka (om nödvändigt, sedan på hela Internet) efter den nödvändiga tjänsten, i det här fallet httpbin.org. Som du kan se från den här filen (egress_httpbin.yml), är funktionaliteten här ganska enkel:
Allt som återstår är att tillämpa denna regel:
istioctl create -f egress_httpbin.yml -n istioegress
Du kan se utgående regler med kommandot istioctl get egressrules:
Och slutligen kör vi kommandot igen curl – och vi ser att allt fungerar:
Vi tänker öppet
Som du kan se låter Istio dig organisera interaktion med omvärlden. Med andra ord kan du fortfarande skapa OpenShift-tjänster och hantera dem genom Kubernetes, och behålla allt i pods som skalas upp och ner efter behov. Och samtidigt kan du säkert få tillgång till tjänster utanför din miljö. Och ja, vi upprepar ännu en gång att allt detta kan göras utan att röra din kod på något sätt.
Detta var det sista inlägget i serien på Istio. Håll utkik - det är mycket intressant som väntar!
Källa: will.com