De feestdagen zijn voorbij en we zijn terug met onze tweede post in de Istio Service Mesh-serie.
Het onderwerp van vandaag is Stroomonderbreker, wat vertaald in het Russisch elektrotechniek “stroomonderbreker” betekent, in het gewone taalgebruik “stroomonderbreker”. Alleen in Istio ontkoppelt deze machine geen kortgesloten of overbelast circuit, maar defecte containers.
Hoe dit idealiter zou moeten werken
Wanneer microservices door Kubernetes worden beheerd, bijvoorbeeld binnen het OpenShift-platform, schalen ze automatisch op en af, afhankelijk van de belasting. Omdat microservices in pods worden uitgevoerd, kunnen er meerdere exemplaren van een gecontaineriseerde microservice op één eindpunt zijn, en Kubernetes zal aanvragen routeren en de belasting daartussen verdelen. En – idealiter – zou dit alles perfect moeten werken.
We herinneren ons dat microservices klein en kortstondig zijn. Vergankelijkheid, wat hier het gemak van verschijnen en verdwijnen betekent, wordt vaak onderschat. De geboorte en dood van een ander exemplaar van een microservice in een pod zijn nogal verwachte dingen, OpenShift en Kubernetes gaan hier goed mee om, en alles werkt prima - maar nogmaals in theorie.
Hoe het echt werkt
Stel je nu voor dat een specifiek exemplaar van een microservice, dat wil zeggen een container, onbruikbaar is geworden: het reageert niet (fout 503), of, wat onaangenamer is, het reageert, maar te langzaam. Met andere woorden, het wordt glitchy of reageert niet op verzoeken, maar het wordt niet automatisch uit de pool verwijderd. Wat moet er in dit geval gebeuren? Opnieuw proberen? Moet ik het uit het routeringsschema verwijderen? En wat betekent ‘te langzaam’ – hoeveel zijn het in cijfers, en wie bepaalt ze? Misschien even een pauze inlassen en het later nog eens proberen? Zo ja, hoeveel later?
Wat is zwembaduitwerping in Istio
En hier komt Istio te hulp met zijn Circuit Breaker-beveiligingsmachines, die defecte containers tijdelijk verwijderen uit de routing- en load-balancing-resourcepool, waarbij de Pool Ejection-procedure wordt geïmplementeerd.
Met behulp van een uitbijterdetectiestrategie detecteert Istio curve-pods die buiten de lijn vallen en verwijdert deze gedurende een bepaalde tijd uit de resourcepool, een zogenaamde slaapperiode.
Om te laten zien hoe dit werkt in Kubernetes op het OpenShift-platform, beginnen we met een screenshot van normaal werkende microservices uit het voorbeeld in de repository . Hier hebben we twee pods, v1 en v2, die elk één container draaien. Wanneer Istio-routeringsregels niet worden gebruikt, gebruikt Kubernetes standaard een gelijkmatig gebalanceerde round-robin-routering:
Voorbereiden op een crash
Voordat u Pool Ejection uitvoert, moet u een Istio-routeringsregel maken. Stel dat we verzoeken tussen pods willen verdelen in een verhouding van 50/50. Daarnaast zullen we het aantal v2-containers verhogen van één naar twee, zoals dit:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nu hebben we een routeringsregel ingesteld, zodat het verkeer in een 50/50-verhouding tussen de pods wordt verdeeld.
Zo ziet het resultaat van deze regel eruit:
Je kunt fouten vinden in het feit dat dit scherm niet 50/50 is, maar 14:9, maar na verloop van tijd zal de situatie verbeteren.
Een storing maken
Laten we nu een van de twee v2-containers uitschakelen, zodat we één gezonde v1-container, één gezonde v2-container en één defecte v2-container hebben:
Het probleem oplossen
We hebben dus een defecte container en het is tijd voor Pool Ejection. Met behulp van een zeer eenvoudige configuratie zullen we deze mislukte container gedurende 15 seconden uitsluiten van alle routeringsschema's, in de hoop dat deze terugkeert naar een gezonde staat (opnieuw opstarten of de prestaties herstellen). Dit is hoe deze configuratie eruit ziet en de resultaten van zijn werk:
Zoals u kunt zien, wordt de mislukte v2-container niet langer gebruikt voor het routeren van aanvragen, omdat deze uit de pool is verwijderd. Maar na 15 seconden keert hij automatisch terug naar het zwembad. Eigenlijk hebben we zojuist laten zien hoe Pool Ejection werkt.
Laten we beginnen met het bouwen van architectuur
Pool Ejection, gecombineerd met de monitoringmogelijkheden van Istio, stelt u in staat een raamwerk te bouwen voor het automatisch vervangen van defecte containers om downtime en storingen te verminderen of zelfs te elimineren.
NASA heeft één luid motto: Falen is geen optie, waarvan de auteur wordt beschouwd als de vluchtdirecteur . Het kan in het Russisch worden vertaald als ‘Falen is geen optie’, en de betekenis hier is dat alles kan werken als je maar genoeg wil hebt. In het echte leven gebeuren mislukkingen echter niet zomaar, ze zijn onvermijdelijk, overal en in alles. En hoe hiermee om te gaan in het geval van microservices? Naar onze mening is het beter om niet op wilskracht te vertrouwen, maar op de mogelijkheden van containers, , En .
Istio implementeert, zoals we hierboven schreven, het concept van stroomonderbrekers, dat zichzelf goed heeft bewezen in de fysieke wereld. En net zoals een elektrische stroomonderbreker een probleemgedeelte van een circuit uitschakelt, opent Istio's software Circuit Breaker de verbinding tussen een stroom verzoeken en een probleemcontainer wanneer er iets mis is met het eindpunt, bijvoorbeeld wanneer de server crasht of begint te werken. vertragen.
Bovendien zijn er in het tweede geval alleen maar meer problemen, omdat de remmen van één container niet alleen een opeenvolging van vertragingen veroorzaken bij de diensten die er toegang toe hebben en als gevolg daarvan de prestaties van het systeem als geheel verminderen, maar ook herhaalde verzoeken aan een toch al trage dienst, wat de situatie alleen maar verergert.
Stroomonderbreker in theorie
Circuit Breaker is een proxy die de stroom van verzoeken naar een eindpunt regelt. Wanneer dit punt niet meer werkt of, afhankelijk van de opgegeven instellingen, begint te vertragen, verbreekt de proxy de verbinding met de container. Het verkeer wordt vervolgens omgeleid naar andere containers, eenvoudigweg vanwege load-balancing. De verbinding blijft gedurende een bepaald slaapvenster open, bijvoorbeeld twee minuten, en wordt vervolgens als halfopen beschouwd. Een poging om het volgende verzoek te verzenden bepaalt de verdere status van de verbinding. Als alles in orde is met de service, keert de verbinding terug naar de werkende staat en wordt opnieuw gesloten. Als er nog steeds iets mis is met de service, wordt de verbinding verbroken en wordt het slaapvenster opnieuw ingeschakeld. Hier ziet u hoe een vereenvoudigd statusdiagram van een stroomonderbreker eruit ziet:
Het is belangrijk op te merken dat dit allemaal gebeurt op het niveau van, om zo te zeggen, de systeemarchitectuur. Op een gegeven moment zul je dus je applicaties moeten leren werken met Circuit Breaker, bijvoorbeeld door als reactie een standaardwaarde op te geven of, indien mogelijk, het bestaan van de dienst te negeren. Hiervoor wordt een schotpatroon gebruikt, maar dit valt buiten het bestek van dit artikel.
Stroomonderbreker in de praktijk
We zullen bijvoorbeeld twee versies van onze aanbevelingsmicroservice uitvoeren op OpenShift. Versie 1 zal prima werken, maar in v2 zullen we een vertraging inbouwen om vertragingen op de server te simuleren. Gebruik de tool om de resultaten te bekijken :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Alles lijkt te werken, maar tegen welke prijs? Op het eerste gezicht hebben we 100% beschikbaarheid, maar als je beter kijkt: de maximale transactieduur bedraagt maar liefst 12 seconden. Dit is duidelijk een knelpunt en moet worden uitgebreid.
Om dit te doen, zullen we Istio gebruiken om oproepen naar langzame containers te elimineren. Dit is hoe de bijbehorende configuratie eruit ziet met behulp van Circuit Breaker:
De laatste regel met de parameter httpMaxRequestsPerConnection geeft aan dat de verbinding moet worden verbroken wanneer wordt geprobeerd een andere - een tweede - verbinding te maken naast de bestaande. Omdat onze container een trage service simuleert, zullen dergelijke situaties zich periodiek voordoen, en dan zal Istio een 503-fout retourneren, maar dit is wat de belegering zal laten zien:
Oké, we hebben een stroomonderbreker, wat nu?
Daarom hebben we automatische uitschakeling geïmplementeerd zonder de broncode van de services zelf aan te raken. Met behulp van de hierboven beschreven Circuit Breaker en de Pool Ejection-procedure kunnen we remcontainers uit de resourcepool verwijderen totdat ze weer normaal zijn, en hun status met een opgegeven frequentie controleren - in ons voorbeeld is dit twee minuten (sleepWindow-parameter).
Houd er rekening mee dat de mogelijkheid van een applicatie om te reageren op een 503-fout nog steeds wordt ingesteld op broncodeniveau. Er zijn veel strategieën voor het gebruik van stroomonderbrekers, afhankelijk van de situatie.
In het volgende bericht: We bespreken de tracering en monitoring die al in Istio is ingebouwd of eenvoudig kan worden toegevoegd, en hoe u opzettelijk fouten in het systeem kunt introduceren.
Bron: www.habr.com