{"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\/da\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","title":{"rendered":"Istio Circuit Breaker: Deaktiver defekte containere","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Helligdage er forbi, og vi er tilbage med vores andet indl\u00e6g i serien om Istio Service Mesh.<\/p>\n

\"Istio
\n
\nDagens emne er Circuit Breaker, som p\u00e5 dansk betyder 'automatisk afbryder' \u2013 ogs\u00e5 kaldet 'beskyttelsesautomat'. I Istio fungerer denne automat ved ikke at afbryde en kortslutning eller overbelastning, men ved at deaktivere defekte containere.
\n<\/a><\/noindex><\/p>\n

Hvordan det b\u00f8r fungere i teorien<\/h3>\n

\nN\u00e5r mikrotjenester styres af Kubernetes, som for eksempel inden for OpenShift-platformen, skaleres de automatisk op og ned afh\u00e6ngigt af belastningen. Da mikrotjenesterne k\u00f8rer i pod'er, kan der v\u00e6re flere instanser af en containeriseret mikrotjeneste p\u00e5 en enkelt end-point, og Kubernetes vil dirigere anmodninger og fordele belastningen imellem dem. Og \u2013 ideelt set \u2013 b\u00f8r alt dette fungere glimrende.<\/p>\n

Vi husker, at mikrotjenester er sm\u00e5 og kortvarige. Den kortvarighed, der her menes, henviser til den enkle opst\u00e5en og forsvinden, og den undervurderes ofte. F\u00f8dslen og d\u00f8den af en given instans af mikrotjenesten i en pod er noget, man kan forvente; OpenShift og Kubernetes h\u00e5ndterer dette godt, og alt fungerer godt \u2013 men igen, det er i teorien.<\/p>\n

Hvordan det fungerer i praksis<\/h3>\n

\nForestil dig nu, at en bestemt instans af mikrotjenesten \u2013 alts\u00e5 en container \u2013 er blevet defekt: enten svarer den ikke (fejl 503), eller \u2013 hvad der er mere ubehageligt \u2013 reagerer den, men for langsomt. Med andre ord, den kan have problemer eller svarer ikke p\u00e5 anmodninger, men den fjernes automatisk ikke fra puljen. Hvad skal man g\u00f8re i dette tilf\u00e6lde? Gentage fors\u00f8get? Fjerne den fra routing-skemaet? Og hvad betyder 'for langsomt' \u2013 hvor mange sekunder er det, og hvem bestemmer det? M\u00e5ske bare give den en pause og pr\u00f8ve igen senere? Hvis ja, hvor l\u00e6nge senere?<\/p>\n

Hvad er Pool Ejection i Istio<\/h3>\n

\nOg her kommer Istio til unds\u00e6tning med sine beskyttelsesautomater Circuit Breaker, som midlertidigt fjerner defekte containere fra routing- og belastningsbalanceringsressourcer, hvilket implementerer Pool Ejection-proceduren.<\/p>\n

Ved at bruge strategien for afvigelsesdetektering (outlier detection) registrerer Istio de sk\u00e6ve pod'er, der skiller sig ud fra det generelle billede, og fjerner dem fra ressourcerne i en given periode, der kaldes 's\u00f8vnvinduet' (sleep window). <\/p>\n

For at vise, hvordan dette fungerer i Kubernetes p\u00e5 OpenShift-platformen, lad os starte med et screenshot af de velfungerende mikroservices fra eksemplet i repositoryet Red Hat Developer Demos<\/a><\/noindex>. Her har vi to pods, v1 og v2, hvor hver k\u00f8rer en enkelt container. N\u00e5r Istio-routingregler ikke bruges, anvender Kubernetes som standard j\u00e6vnt balanceret cyklisk routing:<\/p>\n

\"Istio<\/p>\n

Forbereder os p\u00e5 fejl<\/h3>\n

\nF\u00f8r vi udf\u00f8rer Pool Ejection, skal der oprettes en Istio-routingregel. Lad os sige, at vi \u00f8nsker at fordele anmodningerne mellem pods i forholdet 50\/50. Desuden vil vi \u00f8ge antallet af v2-containere fra \u00e9n til to, s\u00e5dan her:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nNu opretter vi en routingregel, s\u00e5 trafikken fordeles mellem pods i forholdet 50\/50.<\/p>\n
\"Istio
\nHer er, hvordan resultatet af denne regel ser ud:<\/p>\n
\"Istio
\nMan kan p\u00e5pege, at dette screenshot ikke viser 50\/50, men 14:9, men situationen vil rette sig over tid.<\/p>\n
For\u00e5rsager fejl<\/h3>\n
\nLad os nu tage en af de to v2-containere ud af drift, s\u00e5 vi har \u00e9n fungerende v1-container, \u00e9n fungerende v2-container og \u00e9n defekt v2-container: <\/p>\n
\"Istio<\/p>\n
Retter fejlen<\/h3>\n
\nS\u00e5 vi har en defekt container, og det er tid til Pool Ejection. Med en meget enkel konfiguration vil vi udelade denne defekte container fra enhver routing i 15 sekunder i forventning om, at den selv vil vende tilbage til en fungerende tilstand (enten ved at genstarte eller genoprette ydeevnen). Her er, hvordan denne konfiguration ser ud, samt resultaterne af dens anvendelse:<\/p>\n
\"Istio
\n\"Istio
\nSom det ses, bliver den defekte v2-container ikke l\u00e6ngere brugt til routing af anmodninger, da den er blevet fjernet fra puljen. Men efter 15 sekunder vil den automatisk komme tilbage til puljen. Faktisk har vi netop vist, hvordan Pool Ejection fungerer.<\/p>\n
Vi begynder at opbygge arkitekturen<\/h3>\n
\nPool Ejection kombineret med Istios overv\u00e5gningskapaciteter g\u00f8r det muligt at begynde at etablere en ramme for automatisk udskiftning af defekte containere, for at reducere nedetid og fejl.
\n\u2003
\nNASA har et ber\u00f8mt slogan \u2013 Failure Is Not an Option, som tilskrives flight director Gene Kranz<\/a><\/noindex>. P\u00e5 dansk kan det overs\u00e6ttes som \u00abNederlag er ikke en mulighed\u00bb, og meningen heri er, at alt kan f\u00e5s til at fungere, hvis man har tilstr\u00e6kkelig vilje. Men i det virkelige liv sker der ikke blot fejl; de er uundg\u00e5elige, overalt og i alt. Hvordan skal man s\u00e5 h\u00e5ndtere dem i tilf\u00e6lde af mikrotjenester? Efter vores opfattelse er det bedre at stole p\u00e5 containeres muligheder i stedet for viljestyrke. Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, og Istio<\/a><\/noindex>.<\/p>\n
Istio, som vi allerede har n\u00e6vnt, implementerer et koncept for automatiske afbrydere, der har vist sig effektivt i den fysiske verden. Ligesom en elektrisk afbryder afbryder den problematiske del af kredsl\u00f8bet, afbryder software Circuit Breaker i Istio forbindelsen mellem anmodningsstr\u00f8mmen og den problematiske container, n\u00e5r der er noget galt med slutpunktet, for eksempel n\u00e5r serveren er nede eller begynder at h\u00e6nge.<\/p>\n
Og i det andet tilf\u00e6lde er der endnu flere problemer, da en forsinkelse i \u00e9n container ikke kun medf\u00f8rer en kaskade af forsinkelser i de tjenester, der henvender sig til den, og derved s\u00e6nker systemets samlede ydeevne, men ogs\u00e5 medf\u00f8rer gentagne anmodninger til den allerede langsomt funktionerende tjeneste, hvilket kun forv\u00e6rre situationen.<\/p>\n
Circuit Breaker i teorien<\/h3>\n
\nCircuit Breaker er en proxy, der kontrollerer anmodningsstr\u00f8mmen til slutpunktet. N\u00e5r dette punkt holder op med at fungere, eller \u2013 afh\u00e6ngigt af de indstillede parametre \u2013 begynder at h\u00e6nge, afbryder proxyen forbindelsen til containeren. Trafikken omdirigeres derefter til andre containere, blot af hensyn til load balancing. Forbindelsen forbliver \u00e5ben (open) i en angivet hvileperiode, lad os sige to minutter, og derefter betragtes den som halv\u00e5ben (half-open). Et fors\u00f8g p\u00e5 at sende den n\u00e6ste anmodning afg\u00f8r den fremtidige tilstand af forbindelsen. Hvis alt er i orden med tjenesten, genoprettes forbindelsen til en aktiv tilstand og bliver igen lukket (closed). Hvis der derimod fortsat er problemer med tjenesten, forbliver forbindelsen afbrudt og hvileperioden genstartes. Her er en forenklet diagram af tilstands\u00e6ndringerne for Circuit Breaker:<\/p>\n
\"Istio
\nDet er vigtigt at bem\u00e6rke, at alt dette foreg\u00e5r p\u00e5 et niveau, lad os sige, systemarkitektur niveau. Derfor vil du p\u00e5 et tidspunkt skulle l\u00e6re dine applikationer at arbejde med Circuit Breaker, for eksempel ved at returnere en standardv\u00e6rdi som svar eller, hvis det er muligt, ignorere eksistensen af tjenesten. Dette kr\u00e6ver brug af bulkhead-m\u00f8nsteret, men det ligger uden for rammerne af denne artikel.<\/p>\n
Circuit Breaker i praksis<\/h3>\n
\nSom eksempel vil vi k\u00f8re to versioner af vores anbefalingsmikroservice p\u00e5 OpenShift. Version 1 vil fungere normalt, mens vi i v2 vil indf\u00f8re en forsinkelse for at simulere nedbremsninger p\u00e5 serveren. For at se resultaterne bruges v\u00e6rkt\u00f8jet siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nAlt ser ud til at fungere, men til hvilken pris? Ved f\u00f8rste \u00f8jekast har vi 100 % tilg\u00e6ngelighed, men se n\u00e6rmere \u2013 den maksimale varighed af transaktionen er hele 12 sekunder. Dette er klart et flaskehals, som skal l\u00f8ses.<\/p>\n
For dette vil vi med hj\u00e6lp fra Istio udelukke henvisninger til langsomme containere. Her er hvordan den relevante konfiguration ser ud med brug af Circuit Breaker:<\/p>\n
\"Istio
\nDen sidste linje med parameteren httpMaxRequestsPerConnection signalerer, at forbindelsen skal brydes, n\u00e5r der fors\u00f8ges at oprette endnu en - anden - forbindelse ud over den allerede eksisterende. Da vores container simulerer en sl\u00f8vende tjeneste, vil s\u00e5danne situationer periodisk opst\u00e5, og s\u00e5 vil Istio returnere en fejl 503, mens siege viser:<\/p>\n
\"Istio<\/p>\n
Okay, vi har en Circuit Breaker, hvad nu?<\/h3>\n
\nS\u00e5 vi har implementeret automatisk frakobling uden at r\u00f8re ved selve servicekoden. Ved at bruge Circuit Breaker og den ovenfor beskrevne procedure Pool Ejection kan vi fjerne de sl\u00f8vende containere fra ressourcepuljen, indtil de er tilbage til normal, og kontrollere deres tilstand med en given hyppighed - i vores eksempel er det to minutter (parameteren sleepWindow).<\/p>\n
Bem\u00e6rk, at evnen til applikationen til at reagere p\u00e5 fejl 503 stadig defineres i niveauet af dens kildekode. Der findes mange strategier til at arbejde med Circuit Breaker, der anvendes afh\u00e6ngigt af situationen.<\/p>\n
I n\u00e6ste indl\u00e6g:<\/b> vil vi fort\u00e6lle om tracing og overv\u00e5gning, som allerede er indbygget eller let kan tilf\u00f8jes til Istio, samt hvordan man med vilje introducerer fejl i systemet.
\n
Kilde: 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: deaktiverer defekte containere | ProHoster","description":"Helligdage er forbi, og vi er tilbage med vores andet indl\u00e6g i serien om Istio Service Mesh.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/54987","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}