{"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: disabilitiamo i contenitori difettosi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Istio
\n
\nL'argomento di oggi \u00e8 il Circuit Breaker, che in termini elettrici si traduce come 'interruttore automatico' e colloquialmente \u00e8 noto come 'dispositivo di protezione'. Solo che in Istio questo interruttore non disattiva un circuito sovraccarico o in corto, ma container difettosi.
\n<\/a><\/noindex><\/p>\n

Come dovrebbe funzionare idealmente<\/h3>\n

\nQuando i microservizi sono gestiti da Kubernetes, ad esempio all'interno della piattaforma OpenShift, si scalano automaticamente su e gi\u00f9 in base al carico. Poich\u00e9 i microservizi operano in 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 idealmente \u2013 tutto ci\u00f2 dovrebbe funzionare perfettamente.<\/p>\n

Ricordiamo che i microservizi sono piccoli ed efimeri. La loro efimerit\u00e0, qui intesa come semplicit\u00e0 di nascita e di scomparsa, \u00e8 spesso sottovalutata. La nascita e la morte di un'istanza di microservizio in un pod sono eventi piuttosto attesi; OpenShift e Kubernetes gestiscono bene questa dinamica, e tutto funziona magnificamente \u2014 ma di nuovo, solo in teoria.<\/p>\n

Come funziona realmente<\/h3>\n

\nAdesso immaginate che un'istanza specifica di microservizio, cio\u00e8 un contenitore, sia diventata inaffidabile: o non risponde (errore 503), oppure \u2014 cosa pi\u00f9 problematica \u2014 reagisce, ma con grande lentezza. In altre parole, sta dando problemi o non risponde alle richieste, ma non viene automaticamente rimossa dal pool. Cosa si deve fare in questo caso? Ripetere la richiesta? Rimuoverlo dallo schema di routing? E cosa significa \u00abtroppo lentamente\u00bb \u2014 quale sia il valore numerico e chi lo stabilisce? Forse, sarebbe meglio dargli una pausa e riprovare pi\u00f9 tardi? Se s\u00ec, quanto pi\u00f9 tardi?<\/p>\n

Cosa significa Pool Ejection in Istio<\/h3>\n

\nE qui entra in gioco Istio con i suoi automatismi di protezione Circuit Breaker, che rimuovono temporaneamente i container non funzionanti dal pool di 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 identifica i pod che si discostano dalla norma e li rimuove dal pool di risorse per un determinato periodo, chiamato \u00abfinestra di sonno\u00bb (sleep window). <\/p>\n

Per mostrare come funziona in Kubernetes sulla piattaforma OpenShift, iniziamo con uno screenshot di microservizi funzionanti dall'esempio nel repository Red Hat Developer Demos<\/a><\/noindex>. Qui abbiamo due pod, v1 e v2, ognuno con un container attivo. Quando le regole di routing di Istio non vengono utilizzate, Kubernetes applica per default un bilanciamento uniforme del routing ciclico:<\/p>\n

\"Istio<\/p>\n

Preparandoci al guasto<\/h3>\n

\nPrima di effettuare il Pool Ejection, dobbiamo creare una regola di routing Istio. Supponiamo di voler distribuire le richieste tra i pod con un rapporto 50\/50. Inoltre, aumenteremo il numero di container 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 una regola di instradamento per distribuire il traffico tra i pod in un rapporto di 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 col tempo la situazione si stabilizzer\u00e0.<\/p>\n
Causing a failure<\/h3>\n
\nOra disabilitiamo uno dei due container v2, cos\u00ec avremo un container v1 funzionante, un container v2 funzionante e un container v2 guasto: <\/p>\n
\"Istio<\/p>\n
Fixing the failure<\/h3>\n
\nQuindi, abbiamo un container guasto e ora \u00e8 il momento dell'Eiezione del Pool. Con una configurazione molto semplice, escluderemo questo container guasto da qualsiasi schema di instradamento per 15 secondi, con la speranza che torni a uno stato funzionante (o si riavvi, o ripristini le prestazioni). Ecco come appare questa configurazione e i risultati del suo funzionamento:<\/p>\n
\"Istio
\n\"Istio
\nCome si pu\u00f2 vedere, il container guasto v2 non viene pi\u00f9 utilizzato per l'instradamento delle richieste, poich\u00e9 \u00e8 stato rimosso dal pool. Tuttavia, dopo 15 secondi torner\u00e0 automaticamente nel pool. Infatti, abbiamo appena mostrato come funziona l'Eiezione del Pool.<\/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 difettosi, riducendo cos\u00ec al minimo i tempi di inattivit\u00e0 e i guasti.
\n\u2003
\nLa NASA ha un motto ben noto: Failure Is Not an Option, attribuito al direttore di volo Gene Kranz<\/a><\/noindex>. In italiano pu\u00f2 essere tradotto come \u00abIl fallimento non \u00e8 un'opzione\u00bb, e il significato qui \u00e8 che tutto pu\u00f2 funzionare se si ha abbastanza determinazione. Tuttavia, nella vita reale i guasti non accadono solo occasionalmente, sono inevitabili, ovunque e in ogni cosa. Come affrontarli nei microservizi? A nostro avviso, \u00e8 meglio non fare affidamento sulla forza di volont\u00e0, ma sulle capacit\u00e0 dei contenitori. Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, e Istio<\/a><\/noindex>.<\/p>\n
Istio, come abbiamo gi\u00e0 detto sopra, implementa magnificamente il concetto di interruttori automatici ben collaudato nel mondo fisico. Proprio come un interruttore elettrico disconnette una parte problematica del circuito, cos\u00ec il Circuit Breaker software in Istio interrompe la connessione tra il flusso delle richieste e il contenitore problematico quando c'\u00e8 qualche problema con l'endpoint, ad esempio quando il server \u00e8 andato in crash o ha iniziato a rallentare.<\/p>\n
Nel secondo caso, i problemi diventano ancora pi\u00f9 numerosi, poich\u00e9 i rallentamenti di un container non solo causano ritardi a catena nei servizi che lo utilizzano 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
Il Circuit Breaker in teoria<\/h3>\n
\nIl Circuit Breaker \u00e8 un proxy che controlla il flusso delle richieste verso un endpoint. Quando questo endpoint smette di funzionare o, a seconda delle impostazioni configurate, inizia a rallentare, il proxy interrompe la connessione con il contenitore. Il traffico viene quindi reindirizzato ad altri contenitori per bilanciare il carico. La connessione rimane aperta (open) per un periodo di sospensione definito, diciamo due minuti, e poi viene considerata semi-aperta (half-open). Il tentativo di inviare la richiesta successiva determina lo stato successivo della connessione. Se il servizio funziona correttamente, la connessione torna attiva e si chiude (closed) nuovamente. Se invece ci sono ancora problemi con il servizio, la connessione viene interrotta e il periodo di sospensione si riattiva. Ecco come appare un diagramma semplificato del cambio di stato del Circuit Breaker:<\/p>\n
\"Istio
\n\u00c8 importante notare che tutto ci\u00f2 avviene a livello di architettura di sistema. Pertanto, a un certo punto, dovrete insegnare alle vostre applicazioni a lavorare con il Circuit Breaker, ad esempio, fornendo un valore predefinito in risposta oppure, se possibile, ignorando l'esistenza del servizio. A questo scopo si utilizza il pattern bulkhead, ma questo esula dall'argomento di questo articolo.<\/p>\n
Circuit Breaker in pratica<\/h3>\n
\nPer esempio, eseguiremo due versioni del nostro microservizio di raccomandazioni su OpenShift. La versione 1 funzioner\u00e0 normalmente, mentre in v2 inseriremo un ritardo per simulare un rallentamento del server. Per visualizzare i risultati utilizziamo 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 che prezzo? A prima vista abbiamo il 100% di disponibilit\u00e0, ma osservate meglio: la durata massima della transazione \u00e8 di ben 12 secondi. Questo \u00e8 chiaramente un collo di bottiglia, e deve essere ampliato.<\/p>\n
Per fare ci\u00f2, utilizzeremo Istio per escludere le richieste 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 una nuova, seconda connessione oltre a quella gi\u00e0 esistente. Poich\u00e9 il nostro contenitore simula un servizio lento, tali situazioni si presenteranno periodicamente, e allora Istio restituir\u00e0 un errore 503, ed ecco cosa mostrer\u00e0 siege:<\/p>\n
\"Istio<\/p>\n
OK, abbiamo un Circuit Breaker, e adesso?<\/h3>\n
\nQuindi, abbiamo implementato l'auto-disconnessione senza toccare il codice sorgente dei servizi stessi. Utilizzando il Circuit Breaker e la procedura di Pool Ejection sopra descritta, possiamo rimuovere i contenitori lenti dal pool delle risorse fino a quando non tornano alla normalit\u00e0 e controllare il loro stato a intervalli regolari \u2013 nel nostro esempio, ogni due minuti (parametro sleepWindow).<\/p>\n
Si noti che la capacit\u00e0 dell'applicazione di rispondere all'errore 503 \u00e8 comunque definita a livello di codice sorgente. Esistono numerose strategie per lavorare con il Circuit Breaker, che vengono applicate a seconda della situazione.<\/p>\n
Nel prossimo post:<\/b> parleremo del tracciamento e del monitoraggio gi\u00e0 integrati o facilmente aggiungibili in Istio, cos\u00ec come di come introdurre errori nel sistema in modo intenzionale.
\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: disattiviamo i container difettosi | ProHoster","description":"Le festivit\u00e0 sono terminate e siamo tornati con il nostro secondo post della serie su Istio Service Mesh. Oggi il tema \u00e8 il Circuit Breaker, che in italiano significa \u00abinterruttore automatico\u00bb, comunemente noto come \u00abdispositivo di protezione\u00bb. Solo che in Istio questo dispositivo non interrompe un circuito cortocircuitato o sovraccarico, ma container difettosi. Come dovrebbe funzionare in modo ideale Quando","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. \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","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"},"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}]}}