{"id":54987,"date":"2020-01-09T00:00:00","date_gmt":"2020-01-08T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery"},"modified":"2020-02-18T14:03:03","modified_gmt":"2020-02-18T11:03:03","slug":"istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","title":{"rendered":"Istio Circuit Breaker: schakel defecte containers uit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De feestdagen zijn voorbij en we zijn terug met onze tweede post in de serie over Istio Service Mesh.<\/p>\n

\"Istio
\n
\nHet onderwerp van vandaag is Circuit Breaker, wat in het Nederlands \u2018automatische onderbreker\u2019 betekent, in de volksmond ook wel \u2018beveiligingsautomaat\u2019. Alleen in Istio schakelt deze onderbreker geen kortsluiting of overbelaste schakelingen uit, maar defecte containers.
\n<\/a><\/noindex><\/p>\n

Hoe dit idealiter zou moeten werken<\/h3>\n

\nWanneer microservices worden beheerd door Kubernetes, bijvoorbeeld binnen het OpenShift-platform, schalen ze automatisch op en neer afhankelijk van de belasting. Aangezien microservices in pods draaien, kunnen er op \u00e9\u00e9n eindpunt meerdere exemplaren van een containerized microservice zijn, en Kubernetes zal de aanvragen routeren en lasten balanceren tussen hen. En \u2013 idealiter \u2013 zou dit alles perfect moeten functioneren.<\/p>\n

We herinneren ons dat microservices klein en efemeer zijn. Deze efemere aard, die hier betekent dat ze gemakkelijk ontstaan en verdwijnen, wordt vaak onderschat. De geboorte en dood van elk exemplaar van een microservice in een pod zijn heel normale gebeurtenissen. OpenShift en Kubernetes gaan hier goed mee om, en alles werkt fantastisch \u2013 maar weer, dat is in theorie.<\/p>\n

Hoe het echt werkt<\/h3>\n

\nStel je nu voor dat een specifiek exemplaar van een microservice, dat wil zeggen een container, defect is geraakt: het reageert ofwel niet (fout 503), ofwel \u2013 wat erger is \u2013 reageert het, maar te traag. Met andere woorden, het werkt moeizaam of reageert niet op aanvragen, maar wordt niet automatisch uit de pool verwijderd. Wat moet je in dit geval doen? De poging herhalen? Het uit het routeringsschema verwijderen? En wat betekent \u2018te traag\u2019 \u2013 hoeveel is dat in cijfers, en wie bepaalt die? Misschien gewoon een pauze geven en later opnieuw proberen? En zo ja, hoe veel later?<\/p>\n

Wat is Pool Ejection in Istio<\/h3>\n

\nEn hier komt Istio te hulp met zijn Circuit Breaker-automatische systemen, die defecte containers tijdelijk uit de pool van routerings- en belastingseffectieve bronnen verwijderen door de Pool Ejection-procedure uit te voeren.<\/p>\n

Met behulp van een outlier detection-strategie detecteert Istio afwijkende pods die uit de lijn vallen, en verwijdert ze voor een bepaalde tijd uit de bronpool, die het \u2018slaapvenster\u2019 (sleep window) wordt genoemd. <\/p>\n

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 Red Hat Developer Demos<\/a><\/noindex>. Hier hebben we twee pods, v1 en v2, elk met \u00e9\u00e9n draaiende container. Wanneer er geen Istio-routeringsregels worden gebruikt, past Kubernetes standaard een gelijkmatig gebalanceerde cyclische routering toe:<\/p>\n

\"Istio<\/p>\n

Voorbereiden op de storing<\/h3>\n

\nVoordat we Pool Ejection uitvoeren, moeten we een Istio-routeringsregel cre\u00ebren. Stel dat we verzoeken 50\/50 willen verdelen tussen de pods. Daarnaast zullen we het aantal containers van v2 verhogen van \u00e9\u00e9n naar twee, zo:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nNu stellen we de routeringsregel in zodat het verkeer 50\/50 tussen de pods wordt verdeeld.<\/p>\n
\"Istio
\nEn zo ziet het resultaat van deze regel eruit:<\/p>\n
\"Istio
\nMen kan aanmerken dat op deze screenshot niet 50\/50, maar 14:9 is, maar na verloop van tijd zal de situatie verbeteren.<\/p>\n
Een storing cre\u00ebren<\/h3>\n
\nLaten we nu een van de twee containers van v2 uit schakelen, zodat we \u00e9\u00e9n werkende container v1, \u00e9\u00e9n werkende container v2 en \u00e9\u00e9n defecte container v2 hebben: <\/p>\n
\"Istio<\/p>\n
De storing herstellen<\/h3>\n
\nDus, we hebben een defecte container, en het is tijd voor Pool Ejection. Met een zeer eenvoudige configuratie zullen we deze defecte container 15 seconden uitsluiten van alle routeringsschema's in de verwachting dat deze vanzelf weer in een goede staat terugkeert (of opnieuw opstart of zijn prestaties herstelt). Zo ziet deze configuratie eruit en de resultaten ervan:<\/p>\n
\"Istio
\n\"Istio
\nZoals te zien is, wordt de defecte container v2 niet meer gebruikt voor het routeren van verzoeken, omdat hij uit de pool is gehaald. Maar na 15 seconden zal hij automatisch terugkeren naar de pool. Eigenlijk hebben we zojuist laten zien hoe Pool Ejection werkt.<\/p>\n
We beginnen met het bouwen van de architectuur<\/h3>\n
\nPool Ejection in combinatie met de monitoringmogelijkheden van Istio stelt ons in staat om een kader te cre\u00ebren voor het automatisch vervangen van defecte containers, om stilstand en storingen te verminderen of zelfs volledig te elimineren.
\n\u2003
\nNASA heeft \u00e9\u00e9n luidsprekende leus \u2013 Failure Is Not an Option, waarvan wordt gezegd dat deze afkomstig is van de vluchtleider Gene Kranz<\/a><\/noindex>. In het Nederlands zou je dit kunnen vertalen als \"Mislukken is geen optie\", en de betekenis hier is dat alles kan werken als je maar voldoende wil hebt. Echter, in het echte leven gebeuren storingen niet zomaar, ze zijn onvermijdelijk, overal en altijd. Hoe gaan we om met deze storingen in het geval van microservices? Naar onze mening is het beter om niet op wilskracht te vertrouwen, maar op de mogelijkheden van containers. Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, en Istio<\/a><\/noindex>.<\/p>\n
Istio, zoals we hierboven al hebben aangegeven, implementeert een goed bewezen concept uit de fysieke wereld: automatische zekeringen. Net zoals een elektrische zekering een probleemgedeelte van de circuit uitschakelt, verbreekt de software Circuit Breaker in Istio de link tussen de stroom van verzoeken en de probleemcontainer wanneer er iets mis is met de eindbestemming, bijvoorbeeld wanneer de server is gecrasht of traag is geworden.<\/p>\n
Bovendien zijn er in het tweede geval nog meer problemen, omdat de vertragingen van \u00e9\u00e9n container niet alleen een cascade van vertragingen veroorzaken in de bijbehorende services en daardoor de algehele systeemprestaties verlagen, maar ook leiden tot herhaaldelijke verzoeken aan de al trage service, wat de situatie alleen maar verergert.<\/p>\n
Circuit Breaker in theorie<\/h3>\n
\nCircuit Breaker is een proxy die de stroom van verzoeken naar een eindbestemming controleert. Wanneer deze bestemming niet meer werkt of - afhankelijk van de ingestelde configuraties - begint te vertragen, verbreekt de proxy de verbinding met de container. Daarna wordt het verkeer omgeleid naar andere containers, gewoonweg voor belastingverdeling. De verbinding blijft open (open) gedurende een vooraf ingestelde slaapperiode, laten we zeggen twee minuten, en wordt daarna als half-open (half-open) beschouwd. Een poging om het volgende verzoek te verzenden, bepaalt de verdere status van de verbinding. Als alles in orde is met de service, wordt de verbinding hersteld en weer gesloten (closed). Als er echter nog steeds iets mis is met de service, wordt de verbinding opnieuw verbroken en wordt de slaapperiode opnieuw geactiveerd. Zo ziet een vereenvoudigd diagram van de statusovergangen van de Circuit Breaker eruit:<\/p>\n
\"Istio
\nHet is belangrijk op te merken dat dit allemaal plaatsvindt op wat we noemen het niveau van de systeemarchitectuur. Daarom moet je op een gegeven moment je applicaties leren werken met Circuit Breaker, bijvoorbeeld door een standaardwaarde terug te geven of, indien mogelijk, het bestaan van de service te negeren. Hiervoor gebruiken we het bulkhead-patroon, maar dit valt buiten de reikwijdte van dit artikel.<\/p>\n
Circuit Breaker in de praktijk<\/h3>\n
\nAls voorbeeld zullen we twee versies van onze aanbevelingsmicroservice op OpenShift draaien. Versie 1 zal normaal functioneren, terwijl we in v2 een vertraging toevoegen om serververtraging te simuleren. Voor het bekijken van de resultaten gebruiken we een tool. siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nAlles lijkt te werken, maar tegen welke prijs? Op het eerste gezicht hebben we 100% beschikbaarheid, maar let goed op \u2013 de maximale duur van de transactie bedraagt maar liefst 12 seconden. Dit is duidelijk een knelpunt dat we moeten verhelpen.<\/p>\n
Om dit te doen, sluiten we met behulp van Istio de aanvragen naar trage containers uit. Zo ziet de bijbehorende configuratie eruit met Circuit Breaker:<\/p>\n
\"Istio
\nDe laatste regel met de parameter httpMaxRequestsPerConnection geeft aan dat de verbinding moet worden verbroken bij de poging om een tweede verbinding te maken naast de al bestaande. Aangezien onze container een traag service simuleert, zullen dergelijke situaties zich periodiek voordoen, en dan zal Istio een 503-fout teruggeven, terwijl Siege het volgende toont:<\/p>\n
\"Istio<\/p>\n
Ok\u00e9, we hebben Circuit Breaker, wat nu?<\/h3>\n
\nDus we hebben automatische uitschakeling ge\u00efmplementeerd, zonder de broncode van de services zelf aan te raken. Door gebruik te maken van Circuit Breaker en de hierboven beschreven procedure voor Pool Ejection, kunnen we de trage containers uit de pool van resources verwijderen totdat ze weer normaal functioneren, en hun status op vooraf bepaalde tijdstippen controleren \u2013 in ons voorbeeld is dit om de twee minuten (parameter sleepWindow).<\/p>\n
Let op dat het vermogen van de applicatie om te reageren op een 503-fout nog steeds op het niveau van de broncode is ingesteld. Er zijn verschillende strategie\u00ebn voor het omgaan met Circuit Breaker, afhankelijk van de situatie.<\/p>\n
In de volgende post:<\/b> zullen we het hebben over tracing en monitoring, die al zijn ingebouwd of gemakkelijk aan Istio kunnen worden toegevoegd, evenals hoe je opzettelijk fouten in het systeem kunt introduceren.
\n
Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u0438 \u0437\u0430\u0432\u0435\u0440\u0448\u0438\u043b\u0438\u0441\u044c, \u0438 \u043c\u044b \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u0430\u0448\u0438\u043c \u0432\u0442\u043e\u0440\u044b\u043c \u043f\u043e\u0441\u0442\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0438\u0438 \u043f\u043e Istio Service Mesh. \u0421\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u044f\u044f \u0442\u0435\u043c\u0430 \u2013 Circuit Breaker, \u0447\u0442\u043e \u0432 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0435 \u043d\u0430 \u0440\u0443\u0441\u0441\u043a\u0438\u0439 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u0437\u043d\u0430\u0447\u0430\u0435\u0442 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0432\u044b\u043a\u043b\u044e\u0447\u0430\u0442\u0435\u043b\u044c\u00bb, \u0432 \u043f\u0440\u043e\u0441\u0442\u043e\u0440\u0435\u0447\u0438\u0438 \u2013 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442 \u0437\u0430\u0449\u0438\u0442\u044b\u00bb. \u0422\u043e\u043b\u044c\u043a\u043e \u0432 Istio \u044d\u0442\u043e\u0442 \u0430\u0432\u0442\u043e\u043c\u0430\u0442 \u043e\u0442\u043a\u043b\u044e\u0447\u0430\u0435\u0442 \u043d\u0435 \u043a\u043e\u0440\u043e\u0442\u043d\u0443\u0432\u0448\u0443\u044e \u0438\u043b\u0438 \u043f\u0435\u0440\u0435\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u0443\u044e \u0446\u0435\u043f\u044c, \u0430 \u043d\u0435\u0438\u0441\u043f\u0440\u0430\u0432\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b. \u041a\u0430\u043a \u044d\u0442\u043e \u0434\u043e\u043b\u0436\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0432 \u0438\u0434\u0435\u0430\u043b\u0435 \u041a\u043e\u0433\u0434\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-54987","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Istio Circuit Breaker: defectieve containers uitschakelen | ProHoster","description":"De feestdagen zijn voorbij en we zijn terug met onze tweede post in de serie over Istio Service Mesh.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Istio Circuit Breaker: \u043e\u0442\u043a\u043b\u044e\u0447\u0430\u0435\u043c \u043d\u0435\u0438\u0441\u043f\u0440\u0430\u0432\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b | ProHoster","og:description":"\u041f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u0438 \u0437\u0430\u0432\u0435\u0440\u0448\u0438\u043b\u0438\u0441\u044c, \u0438 \u043c\u044b \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u0430\u0448\u0438\u043c \u0432\u0442\u043e\u0440\u044b\u043c \u043f\u043e\u0441\u0442\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0438\u0438 \u043f\u043e Istio Service Mesh.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-08T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:03+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"54987","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 13:26:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:54:34","updated":"2026-01-24 13:26:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/54987","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}