Semestern är över och vi är tillbaka med vårt andra inlägg i Istio Service Mesh-serien.
Dagens ämne är Circuit Breaker, som översatt till rysk elektroteknik betyder "strömbrytare", i vanligt språkbruk - "strömbrytare". Endast i Istio kopplar denna maskin inte bort en kortsluten eller överbelastad krets, utan defekta behållare.
Hur detta ska fungera idealiskt
När mikrotjänster hanteras av Kubernetes, till exempel inom OpenShift-plattformen, skalas de automatiskt upp och ner beroende på belastningen. Eftersom mikrotjänster körs i pods, kan det finnas flera instanser av en containeriserad mikrotjänst på en slutpunkt, och Kubernetes kommer att dirigera förfrågningar och belastningsbalans mellan dem. Och – helst – allt detta borde fungera perfekt.
Vi kommer ihåg att mikrotjänster är små och tillfälliga. Efemeralitet, som här betyder lättheten att dyka upp och försvinna, underskattas ofta. Födelsen och döden av en annan instans av en mikrotjänst i en pod är ganska förväntade saker, OpenShift och Kubernetes hanterar detta bra, och allt fungerar utmärkt - men igen i teorin.
Hur det verkligen fungerar
Föreställ dig nu att en specifik instans av en mikrotjänst, det vill säga en behållare, har blivit oanvändbar: antingen svarar den inte (fel 503), eller, vad som är mer obehaglig, så svarar den, men för långsamt. Med andra ord, det blir problematiskt eller svarar inte på förfrågningar, men det tas inte automatiskt bort från poolen. Vad ska man göra i det här fallet? Försök igen? Ska jag ta bort det från routingschemat? Och vad betyder "för långsam" - hur många är det i antal, och vem bestämmer dem? Kanske bara ge det en paus och försöka igen senare? Om så är fallet, hur långt senare?
Vad är Pool Ejection i Istio
Och här kommer Istio till undsättning med sina Circuit Breaker-skyddsmaskiner, som tillfälligt tar bort felaktiga containrar från routing- och lastbalanseringsresurspoolen, och implementerar Pool Ejection-proceduren.
Med hjälp av en strategi för detektering av extremvärden upptäcker Istio kurvor som är ur linje och tar bort dem från resurspoolen under en angiven tidsperiod, ett sömnfönster.
För att visa hur detta fungerar i Kubernetes på OpenShift-plattformen, låt oss börja med en skärmdump av normalt fungerande mikrotjänster från exemplet i förvaret . Här har vi två pods, v1 och v2, som var och en kör en container. När Istio routingregler inte används, använder Kubernetes som standard jämnt balanserad round-robin routing:
Förbereder sig för misslyckande
Innan du gör Pool Ejection måste du skapa en Istio routingregel. Låt oss säga att vi vill fördela förfrågningar mellan pods i förhållandet 50/50. Dessutom kommer vi att öka antalet v2-behållare från en till två, så här:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nu sätter vi en routingregel så att trafiken fördelas mellan poddarna i förhållandet 50/50.
Så här ser resultatet av denna regel ut:
Du kan hitta fel på att den här skärmen inte är 50/50, utan 14:9, men med tiden kommer situationen att förbättras.
Att göra ett fel
Låt oss nu inaktivera en av de två v2-behållarna så att vi har en frisk v1-behållare, en frisk v2-behållare och en felaktig v2-behållare:
Fixar felet
Så vi har en trasig container och det är dags för Pool Ejection. Med en mycket enkel konfiguration kommer vi att utesluta denna misslyckade behållare från alla routingscheman i 15 sekunder i hopp om att den ska återgå till ett hälsosamt tillstånd (antingen omstart eller återställ prestanda). Så här ser den här konfigurationen ut och resultatet av dess arbete:
Som du kan se används den misslyckade v2-behållaren inte längre för routingbegäranden eftersom den har tagits bort från poolen. Men efter 15 sekunder kommer den automatiskt tillbaka till poolen. Egentligen visade vi precis hur Pool Ejection fungerar.
Låt oss börja bygga arkitektur
Pool Ejection, kombinerat med Istios övervakningsmöjligheter, låter dig börja bygga ett ramverk för att automatiskt byta ut felaktiga behållare för att minska, om inte eliminera, stillestånd och fel.
NASA har ett högljutt motto - Misslyckande är inte ett alternativ, vars författare anses vara flygledaren . Det kan översättas till ryska som "Feil är inte ett alternativ", och meningen här är att allt kan fås att fungera om du har tillräckligt med vilja. Men i det verkliga livet inträffar misslyckanden inte bara, de är oundvikliga, överallt och i allt. Och hur ska man hantera dem när det gäller mikrotjänster? Enligt vår åsikt är det bättre att inte lita på viljestyrka, utan på behållarnas kapacitet, , Och .
Istio implementerar, som vi skrev ovan, konceptet med effektbrytare, vilket har visat sig väl i den fysiska världen. Och precis som en elektrisk strömbrytare stänger av en problemdel av en krets, öppnar Istios mjukvara Circuit Breaker kopplingen mellan en ström av förfrågningar och en problembehållare när något är fel med ändpunkten, till exempel när servern kraschade eller började sakta ner.
Dessutom, i det andra fallet finns det bara fler problem, eftersom bromsarna i en container inte bara orsakar en kaskad av förseningar i de tjänster som kommer åt den och som ett resultat minskar systemets prestanda som helhet, utan också genererar upprepade förfrågningar till en redan långsamt fungerande tjänst, vilket bara förvärrar situationen .
Circuit Breaker i teorin
Circuit Breaker är en proxy som styr flödet av förfrågningar till en slutpunkt. När denna punkt slutar fungera eller, beroende på de angivna inställningarna, börjar sakta ner bryter proxyn anslutningen till behållaren. Trafiken omdirigeras sedan till andra containrar, helt enkelt på grund av lastbalansering. Anslutningen förblir öppen under ett givet vilofönster, säg två minuter, och anses sedan vara halvöppen. Ett försök att skicka nästa begäran avgör anslutningens ytterligare tillstånd. Om allt är OK med tjänsten återgår anslutningen till fungerande skick och stängs igen. Om det fortfarande är något fel med tjänsten kopplas anslutningen bort och vilofönstret återaktiveras. Så här ser ett förenklat kretsbrytartillståndsdiagram ut:
Det är viktigt att notera här att allt detta sker på nivån av, så att säga, systemarkitektur. Så någon gång måste du lära dina applikationer att fungera med Circuit Breaker, som att tillhandahålla ett standardvärde som svar eller, om möjligt, ignorera existensen av tjänsten. Ett skottmönster används för detta, men det ligger utanför ramen för denna artikel.
Strömbrytare i praktiken
Till exempel kommer vi att köra två versioner av vår rekommendationsmikrotjänst på OpenShift. Version 1 kommer att fungera bra, men i v2 kommer vi att bygga in en fördröjning för att simulera nedgångar på servern. För att se resultaten, använd verktyget :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Allt verkar fungera, men till vilken kostnad? Vid första anblicken har vi 100 % tillgänglighet, men ta en närmare titt - den maximala transaktionslängden är så mycket som 12 sekunder. Detta är helt klart en flaskhals och måste utökas.
För att göra detta kommer vi att använda Istio för att eliminera anrop till långsamma containrar. Så här ser motsvarande konfiguration ut med Circuit Breaker:
Den sista raden med parametern httpMaxRequestsPerConnection signalerar att anslutningen med ska kopplas bort när man försöker skapa en annan - en andra - anslutning utöver den befintliga. Eftersom vår container simulerar en långsam tjänst kommer sådana situationer att uppstå med jämna mellanrum, och då kommer Istio att returnera ett 503-fel, men detta är vad belägringen kommer att visa:
OK, vi har Circuit Breaker, vad händer härnäst?
Så vi implementerade automatisk avstängning utan att röra källkoden för själva tjänsterna alls. Med hjälp av Circuit Breaker och Pool Ejection proceduren som beskrivs ovan kan vi ta bort bromsbehållare från resurspoolen tills de återgår till det normala, och kontrollera deras status vid en specificerad frekvens - i vårt exempel är detta två minuter (sleepWindow parameter).
Observera att en applikations förmåga att svara på ett 503-fel fortfarande är inställd på källkodsnivå. Det finns många strategier för att använda Circuit Breaker, beroende på situationen.
I nästa inlägg: Vi kommer att prata om spårning och övervakning som redan är inbyggd eller lätt att lägga till i Istio, samt hur man avsiktligt introducerar fel i systemet.
Källa: will.com