{"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\/it\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","title":{"rendered":"Istio Circuit Breaker: disattiviamo i contenitori difettosi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le vacanze sono finite e ritorniamo con il nostro secondo post della serie su Istio Service Mesh.<\/p>\n

\"Istio
\n
\nIl tema di oggi \u00e8 il Circuit Breaker, che in italiano significa \"interruttore automatico\" e in gergo si riferisce a un \"dispositivo di protezione\". Solo che in Istio questo dispositivo non scollega un circuito in cortocircuito o sovraccarico, ma disabilita i contenitori difettosi.
\n<\/a><\/noindex><\/p>\n

Come dovrebbe funzionare in teoria<\/h3>\n

\nQuando i microservizi sono gestiti da Kubernetes, ad esempio all'interno della piattaforma OpenShift, si scalano automaticamente su e gi\u00f9 a seconda del carico. Poich\u00e9 i microservizi operano all'interno di pod, su un singolo endpoint possono esserci pi\u00f9 istanze di un microservizio containerizzato, e Kubernetes instrader\u00e0 le richieste e bilancer\u00e0 il carico tra di esse. E \u2013 in teoria \u2013 tutto questo dovrebbe funzionare perfettamente.<\/p>\n

Ricordiamoci che i microservizi sono piccoli ed efimeri. L'efimerit\u00e0, qui, che significa la facilit\u00e0 di nascita e scomparsa, \u00e8 spesso sottovalutata. La nascita e la morte di un'istanza di microservizio dentro un pod sono eventi piuttosto previsti, OpenShift e Kubernetes li gestiscono bene, e tutto funziona splendidamente \u2013 ma, di nuovo, in teoria.<\/p>\n

Come funziona realmente<\/h3>\n

\nOra immaginate che un'istanza specifica di un microservizio, ovvero un contenitore, sia diventata inservibile: o non risponde (errore 503), oppure \u2013 il che \u00e8 peggio \u2013 risponde, ma troppo lentamente. In altre parole, sta dando problemi o non risponde alle richieste, ma non viene automaticamente rimosso dal pool. Cosa fare in questo caso? Riprovare? Rimuoverlo dallo schema di routing? E cosa significa \"troppo lentamente\" \u2013 quanto \u00e8 questo in numeri, e chi li definisce? Forse, semplicemente dargli una pausa e riprovare pi\u00f9 tardi? Se s\u00ec, quanto tardi?<\/p>\n

Che cos'\u00e8 il Pool Ejection in Istio<\/h3>\n

\nEd ecco che Istio interviene con i suoi interruttori di protezione Circuit Breaker, che rimuovono temporaneamente i contenitori difettosi dal pool delle risorse di routing e bilanciamento del carico, implementando la procedura di Pool Ejection.<\/p>\n

Utilizzando la strategia di rilevamento delle anomalie (outlier detection), Istio rileva i pod problematici che si distaccano dalla norma e li rimuove dal pool delle risorse per un periodo di tempo definito, chiamato \"finestra di sonno\" (sleep window). <\/p>\n

Per mostrare come funziona in Kubernetes sulla piattaforma OpenShift, iniziamo con uno screenshot di microservizi funzionanti dall'esempio nel repository. Dimostrazioni da Red Hat Developer<\/a><\/noindex>Qui abbiamo due pod, v1 e v2, ognuno con un contenitore in esecuzione. Quando non si usano le regole di instradamento di Istio, Kubernetes applica per impostazione predefinita un'instradamento ciclico bilanciato in modo uniforme:<\/p>\n

\"Istio<\/p>\n

Prepararsi a un guasto<\/h3>\n

\nPrima di effettuare il Pool Ejection, \u00e8 necessario creare una regola di instradamento di Istio. Supponiamo di voler distribuire le richieste tra i pod in un rapporto 50\/50. Inoltre, aumenteremo il numero di contenitori v2 da uno a due, in questo modo:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nOra impostiamo la regola di instradamento affinch\u00e9 il traffico venga distribuito tra i pod in un rapporto 50\/50.<\/p>\n
\"Istio
\nEcco come appare il risultato di questa regola:<\/p>\n
\"Istio
\nSi potrebbe obiettare che in questo screenshot non sia 50\/50, ma 14:9, ma con il tempo la situazione si sistemer\u00e0.<\/p>\n
Generiamo un guasto<\/h3>\n
\nOra metteremo fuori uso uno dei due contenitori v2, in modo da avere un contenitore v1 funzionante, un contenitore v2 funzionante e un contenitore v2 non funzionante: <\/p>\n
\"Istio<\/p>\n
Ripariamo il guasto<\/h3>\n
\nQuindi, abbiamo un contenitore non funzionante, e ora \u00e8 tempo di Pool Ejection. Con una configurazione molto semplice, escluderemo questo contenitore guasto da qualsiasi schema di instradamento per 15 secondi, con l'aspettativa che si ripristini da solo (o si riavvii, o recuperi le prestazioni). Ecco come appare questa configurazione e i risultati della sua esecuzione:<\/p>\n
\"Istio
\n\"Istio
\nCome si vede, il contenitore non funzionante v2 non viene pi\u00f9 utilizzato nell'instradamento delle richieste, poich\u00e9 \u00e8 stato rimosso dal pool. Dopo 15 secondi, torner\u00e0 automaticamente nel pool. In effetti, abbiamo appena mostrato come funziona il Pool Ejection.<\/p>\n
Iniziamo a costruire l'architettura<\/h3>\n
\nIl Pool Ejection insieme alle capacit\u00e0 di monitoraggio di Istio consente di iniziare a costruire un framework per la sostituzione automatica dei contenitori guasti, per ridurre o addirittura eliminare i tempi di inattivit\u00e0 e i guasti.
\n\u2003
\nLa NASA ha un famoso motto: Failure Is Not an Option, attribuito al flight director Gene Kranz<\/a><\/noindex>. In russo si pu\u00f2 tradurre come \u00abLa sconfitta non \u00e8 un'opzione\u00bb, e il significato qui \u00e8 che tutto pu\u00f2 funzionare se si ha sufficiente volont\u00e0. Tuttavia, nella vita reale i fallimenti non accadono solo occasionalmente, ma sono inevitabili, ovunque e in tutto. E come affrontarli in caso di microservizi? A nostro avviso, \u00e8 meglio non fare affidamento sulla forza di volont\u00e0, ma piuttosto sulle capacit\u00e0 dei container, Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, e Istio<\/a><\/noindex>.<\/p>\n
Istio, come abbiamo gi\u00e0 scritto sopra, implementa una concetto di interruttori automatici che ha dimostrato di funzionare bene nel mondo fisico. E proprio come un interruttore elettrico disconnette la parte problematica di un circuito, cos\u00ec il Circuit Breaker software in Istio interrompe la connessione tra il flusso di richieste e il container problematico, quando c'\u00e8 qualcosa che non va con il punto finale, ad esempio, quando il server \u00e8 andato gi\u00f9 o ha cominciato a rallentare.<\/p>\n
Nel secondo caso ci sono solo pi\u00f9 problemi, poich\u00e9 i rallentamenti di un container non solo causano un effetto a cascata di ritardi nei servizi che vi si connettono e, di conseguenza, riducono le prestazioni complessive del sistema, ma generano anche richieste ripetute a un servizio gi\u00e0 lento, aggravando ulteriormente la situazione.<\/p>\n
Circuit Breaker in teoria<\/h3>\n
\nCircuit Breaker \u00e8 un proxy che controlla il flusso di richieste verso il punto finale. Quando questo punto smette di funzionare o \u2013 a seconda delle impostazioni fornite \u2013 inizia a rallentare, il proxy interrompe la connessione con il container. Il traffico dopo viene reindirizzato verso altri container, proprio per motivi di bilanciamento del carico. La connessione rimane aperta (open) per un determinato intervallo di sonno, diciamo due minuti, e poi viene considerata semi-aperta (half-open). Il tentativo di inviare la successiva richiesta determina lo stato successivo della connessione. Se il servizio \u00e8 OK, la connessione torna in stato operativo e diventa nuovamente chiusa (closed). Se il servizio continua a non funzionare, la connessione si interrompe e viene riattivato l'intervallo di sonno. Ecco come si presenta un diagramma semplificato dello stato del Circuit Breaker:<\/p>\n
\"Istio
\n\u00c8 importante sottolineare che tutto questo avviene a livello di architettura sistemica. Pertanto, a un certo punto dovrete insegnare alle vostre applicazioni a lavorare con il Circuit Breaker, ad esempio fornendo un valore predefinito in risposta o, se possibile, ignorando l'esistenza del servizio. A tal fine si utilizza il pattern bulkhead, ma questo esula dall'argomento di questo articolo.<\/p>\n
Circuit Breaker in pratica<\/h3>\n
\nPer esempio, avvieremo su OpenShift due versioni del nostro microservizio di raccomandazione. La versione 1 funzioner\u00e0 normalmente, mentre nella v2 inseriremo un ritardo per simulare un rallentamento del server. Per visualizzare i risultati si utilizza lo strumento siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nTutto sembra funzionare, ma a quale costo? A prima vista abbiamo il 100% di disponibilit\u00e0, ma osservate bene: la durata massima della transazione \u00e8 di ben 12 secondi. Questo \u00e8 chiaramente un collo di bottiglia e deve essere risolto.<\/p>\n
Per questo motivo, tramite Istio, escluderemo le chiamate ai contenitori lenti. Ecco come appare la configurazione corrispondente utilizzando il Circuit Breaker:<\/p>\n
\"Istio
\nL'ultima riga con il parametro httpMaxRequestsPerConnection indica che la connessione deve essere interrotta quando si tenta di creare un'altra connessione \u2013 una seconda \u2013 oltre a quella gi\u00e0 esistente. Poich\u00e9 il nostro contenitore simula un servizio che rallenta, situazioni di questo tipo si verificheranno periodicamente, e in tal caso Istio restituir\u00e0 un errore 503, ecco cosa mostrer\u00e0 siege:<\/p>\n
\"Istio<\/p>\n
Ok, ora abbiamo il Circuit Breaker, e adesso?<\/h3>\n
\nQuindi, abbiamo implementato l'autodisconnessione senza toccare il codice sorgente dei servizi stessi. Utilizzando il Circuit Breaker e la procedura di Ejection del Pool descritta sopra, possiamo rimuovere dai pool delle risorse i contenitori problematici fino a quando non tornano alla normalit\u00e0 e controllarne lo stato a intervalli regolari \u2013 nel nostro esempio, ogni due minuti (parametro sleepWindow).<\/p>\n
Si noti che la capacit\u00e0 dell'applicazione di reagire all'errore 503 \u00e8 ancora definita a livello del suo codice sorgente. Esistono diverse strategie per lavorare con il Circuit Breaker, che vengono applicate a seconda della situazione.<\/p>\n
Nel prossimo post:<\/b> parleremo di tracciamento e monitoraggio, che sono gi\u00e0 integrati o facilmente aggiungibili in Istio, oltre a come introdurre errori nel sistema deliberatamente.
\n
Fonte: 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\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: disattivare i container difettosi | ProHoster","description":"Le vacanze sono finite e ritorniamo con il nostro secondo post della serie su Istio Service Mesh.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/54987","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}