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

Prazniki so minili in vrnili smo se z drugim zapisom v seriji o Istio Service Mesh.<\/p>\n

\"Istio
\n
\nDana\u0161nja tema je Circuit Breaker, kar v sloven\u0161\u010dini pomeni 'samodejni odklopnik' ali 'varovalka'. V Istio ta odklopnik ne izklju\u010di kratkega stika ali prenapolnjenega vezja, ampak okvarjene kontejnerje.
\n<\/a><\/noindex><\/p>\n

Kako naj bi to delovalo v idealnem primeru<\/h3>\n

\nKo mikroservisi upravlja Kubernetes, na primer v okviru platforme OpenShift, se avtomatsko prilagajajo obremenitvi navzgor in navzdol. Ker mikroservisi delujejo v podih, je na eni kon\u010dni to\u010dki lahko ve\u010d primerkov kontejneriziranega mikroservisa, Kubernetes pa usmerja zahteve in uravnava obremenitve med njimi. In \u2013 v idealnem svetu \u2013 bi vse to moralo delovati brezhibno.<\/p>\n

Spomnimo se, da so mikroservisi majhni in efemerni. Efmernost, ki tu pomeni enostavno nastajanje in izginjanje, se pogosto podcenjuje. Rojstvo in smrt novega primerka mikroservisa v podu sta povsem pri\u010dakovana, OpenShift in Kubernetes se s tem dobro spopadata, vse deluje odli\u010dno \u2013 a spet, le v teoriji.<\/p>\n

Kako to dejansko deluje<\/h3>\n

\nIn zdaj si predstavljajte, da je nek konkreten primer mikroservisa, torej kontejner, odpovedal: bodisi ne odgovarja (napaka 503), bodisi \u2013 kar je \u0161e slab\u0161e \u2013 reagira, vendar prepo\u010dasno. Z drugimi besedami, deluje slabo ali ne odgovarja na zahteve, a kljub temu ni samodejno odstranjen iz baze. Kaj storiti v tem primeru? Ponoviti poskus? Odstraniti ga iz usmerjevanja? In kaj pomeni 'predolgo' \u2013 koliko je to v \u0161tevilkah in kdo to dolo\u010da? Morda ga preprosto pustiti na miru in poskusiti kasneje? \u010ce da, kako dolgo pa?<\/p>\n

Kaj je Pool Ejection v Istio<\/h3>\n

\nIn tu prisko\u010di na pomo\u010d Istio s svojimi za\u0161\u010ditnimi mehanizmi Circuit Breaker, ki za\u010dasno odstranijo pokvarjene kontejnerje iz bazena virov za usmerjanje in uravnavanje obremenitve ter izvajajo postopek Pool Ejection.<\/p>\n

Z uporabo strategije zaznavanja odstopanj (outlier detection) Istio zaznava nenavadne pode in jih odstrani iz bazena virov za dolo\u010den \u010das, ki ga imenujemo 'spalno okno' (sleep window). <\/p>\n

Da bi pokazali kako to radi u Kubernetesu na platformi OpenShift, zapo\u010dinjemo sa screenshotom normalno funkcionalnih mikroservisa iz primjera u repozitoriju Red Hat Developer Demos<\/a><\/noindex>. Ovdje imamo dva pod-a, v1 i v2, u kojem svaki radi jedan kontejner. Kada se ne koriste Istio pravila usmjeravanja, Kubernetes po defaultu primjenjuje ravnomjerno uravnote\u017eeno cikli\u010dko usmjeravanje:<\/p>\n

\"Istio<\/p>\n

Pripremamo se za kvar<\/h3>\n

\nPrije nego \u0161to napravimo Pool Ejection, trebamo stvoriti Istio pravilo usmjeravanja. Recimo da \u017eelimo raspodijeliti zahtjeve izme\u0111u podova u omjeru 50\/50. Tako\u0111er, pove\u0107at \u0107emo broj kontejnera v2 s jednog na dva, ovako:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nSada postavljamo pravilo usmjeravanja da se promet raspodijeli izme\u0111u podova u omjeru 50\/50.<\/p>\n
\"Istio
\nA evo kako izgleda rezultat ovog pravila:<\/p>\n
\"Istio
\nMo\u017ee se prigovoriti da na ovom ekranu nije 50\/50, ve\u0107 14:9, ali s vremenom \u0107e se situacija stabilizirati.<\/p>\n
Uzrokovanje kvara<\/h3>\n
\nSada \u0107emo izbaciti jedan od dva kontejnera v2, tako da imamo jedan ispravan kontejner v1, jedan ispravan kontejner v2 i jedan neispravan kontejner v2: <\/p>\n
\"Istio<\/p>\n
Popravak kvara<\/h3>\n
\nDakle, imamo neispravan kontejner i do\u0161lo je vrijeme za Pool Ejection. Uz vrlo jednostavnu konfiguraciju isklju\u010dit \u0107emo ovaj neispravni kontejner iz bilo kojih shema usmjeravanja na 15 sekundi s nadom da \u0107e se sam vratiti u ispravno stanje (ili \u0107e se ponovo pokrenuti ili obnoviti svoju funkcionalnost). Evo kako izgleda ova konfiguracija i rezultati njenog rada:<\/p>\n
\"Istio
\n\"Istio
\nKao \u0161to se mo\u017ee vidjeti, neispravan kontejner v2 vi\u0161e se ne koristi pri usmjeravanju zahtjeva, jer je isklju\u010den iz pulta. No, nakon 15 sekundi automatski \u0107e se vratiti u pul. U su\u0161tini, upravo smo pokazali kako radi Pool Ejection.<\/p>\n
Po\u010dinjemo graditi arhitekturu<\/h3>\n
\nPool Ejection u kombinaciji s mogu\u0107nostima pra\u0107enja Istio-a omogu\u0107ava po\u010detak izgradnje okvira za automatsku zamjenu neispravnih kontejnera kako bi se smanjili, a u nekim slu\u010dajevima i potpuno uklonili zastoji i kvarovi.
\n\u2003
\nNASA ima jedan poznati moto \u2013 Failure Is Not an Option, \u010diji je autor \u0161ef misije Gene Kranz<\/a><\/noindex>. V sloven\u0161\u010dino ga lahko prevedemo kot \u201ePoraz ni mo\u017enost\u201c, kar pomeni, da lahko vse deluje, \u010de imate dovolj volje. V resni\u010dnem \u017eivljenju pa napake ne nastanejo le ob\u010dasno, ampak so neizbe\u017ene, povsod in v vsem. Kako se torej spopasti z njimi v primeru mikroservisov? Po na\u0161em mnenju je bolje zana\u0161ati se ne na voljo, temve\u010d na sposobnosti kontejnerjev. Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, i Istio<\/a><\/noindex>.<\/p>\n
Istio, kot smo \u017ee omenili, izvaja odli\u010dno uveljavljeno koncept avtomatskih odklopnikov iz fizi\u010dnega sveta. Tako kot elektri\u010dni odklopnik prekine te\u017eavni del vezja, tako programski Circuit Breaker v Istio prekine povezavo med tokom zahtevkov in problemati\u010dnim kontejnerjem, ko nekaj ni v redu s kon\u010dno to\u010dko, na primer, ko je stre\u017enik padel ali za\u010del upo\u010dasniti.<\/p>\n
Pri tem se v drugem primeru te\u017eave le pove\u010dujejo, saj usihanje enega kontejnerja ne povzro\u010da le veri\u017enih zamud v storitvah, ki se sklicujejo nanj, in posledi\u010dno zni\u017euje u\u010dinkovitost sistema kot celote, temve\u010d tudi povzro\u010da ponavljajo\u010de se zahtevke na \u017ee tako po\u010dasi delujo\u010do storitev, kar le \u0161e poslab\u0161a situacijo.<\/p>\n
Circuit Breaker v teoriji<\/h3>\n
\nCircuit Breaker je proxy, ki nadzira tok zahtevkov do kon\u010dne to\u010dke. Ko ta to\u010dka preneha delovati ali - odvisno od nastavitev - za\u010dne upo\u010dasniti, proxy prekine povezavo s kontejnerjem. Po tem se promet preusmeri na druge kontejnerje, preprosto zaradi uravnavanja obremenitve. Povezava ostaja odprta (open) v \u010dasu dolo\u010denega okna spanja, recimo dve minuti, nato pa se \u0161teje za polodprto (half-open). Poskus po\u0161iljanja naslednjega zahtevka dolo\u010da nadaljnje stanje povezave. \u010ce je s storitvijo vse v redu, se povezava vrne v delovno stanje in postane spet zaprta (closed). \u010ce pa s storitvijo \u0161e vedno nekaj ni v redu, se povezava znova prekine in okno spanja se ponovno aktivira. Tako izgleda poenostavljena diagram stanja Circuit Breaker:<\/p>\n
\"Istio
\nPomembno je opozoriti, da vse to poteka na ravni, recimo, sistemske arhitekture. Zato boste v nekem trenutku morali nau\u010diti svoje aplikacije delovati s Circuit Breakerjem, na primer, da v odgovoru posredujejo privzeto vrednost ali pa, \u010de je to mogo\u010de, ignorirajo obstoj storitve. Za to se uporablja bulkhead pattern, vendar presega obseg tega \u010dlanka.<\/p>\n
Circuit Breaker v praksi<\/h3>\n
\nZa primer bomo na OpenShiftu zagnali dve razli\u010dici na\u0161ega mikrostoritve za priporo\u010dila. Razli\u010dica 1 bo delovala normalno, medtem ko bomo v v2 vklju\u010dili zamudo, da posnemamo zaostanke na stre\u017eniku. Za ogled rezultatov uporabljamo orodje siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nVse se zdi, da deluje, ampak po kak\u0161ni ceni? Na prvi pogled imamo 100 % dostopnost, toda poglejte \u2013 najve\u010dja dol\u017eina transakcije je kar 12 sekund. To je o\u010ditna o\u017eina in potrebno jo je raz\u0161iriti.<\/p>\n
Zato bomo s pomo\u010djo Istio izklju\u010dili dostop do po\u010dasnih kontejnerjev. Tako izgleda ustrezna konfiguracija z uporabo Circuit Breakerja:<\/p>\n
\"Istio
\nZadnja vrstica s parametrom httpMaxRequestsPerConnection signalizira, da se mora povezava prekiniti, ko posku\u0161a ustvariti \u0161e eno \u2013 drugo \u2013 povezavo poleg \u017ee obstoje\u010de. Ker na\u0161 kontejner posnema po\u010dasno storitev, se bodo take situacije ob\u010dasno pojavljale, in takrat bo Istio vrnil napako 503, kakor pa bo pokazal siege:<\/p>\n
\"Istio<\/p>\n
Dobro, imamo Circuit Breaker, kaj zdaj?<\/h3>\n
\nTorej, implementirali smo samodejno izklopitev, ne da bi se dotaknili izvorne kode storitev. Z uporabo Circuit Breakerja in zgoraj opisane procedure Pool Ejection lahko odstranimo po\u010dasne kontejnerje iz nabora virov, dokler se ne vrnejo v normalo, in preverimo njihovo stanje z dolo\u010denim \u010dasovnim intervalom \u2013 v na\u0161em primeru je to dve minuti (parameter sleepWindow).<\/p>\n
Upo\u0161tevajte, da sposobnost aplikacije, da reagira na napako 503, \u0161e vedno dolo\u010da izvorna koda same aplikacije. Obstaja veliko strategij dela s Circuit Breakerjem, ki se uporabljajo glede na situacijo.<\/p>\n
V naslednjem prispevku:<\/b> bomo govorili o sledenju in izvajanju nadzora, ki sta \u017ee vgrajena ali jih je enostavno dodati v Istio, ter o tem, kako namerno vna\u0161ati napake v sistem.
\n
Izvor: 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: izklopite okvarjene kontejnerje | ProHoster","description":"Prazniki so minili in vrnili smo se z drugim zapisom v seriji o Istio Service Mesh.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/54987","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}