{"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\/pt\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","title":{"rendered":"Istio Circuit Breaker: desligando containers com falha","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

As festas acabaram e estamos de volta com nossa segunda postagem da s\u00e9rie sobre o Istio Service Mesh.<\/p>\n

\"Istio
\n
\nO tema de hoje \u00e9 Circuit Breaker, que em portugu\u00eas significa \"disjuntor\". No contexto do Istio, este disjuntor n\u00e3o desliga um circuito sobrecarregado, mas cont\u00eaineres com falhas.
\n<\/a><\/noindex><\/p>\n

Como isso deve funcionar na teoria<\/h3>\n

\nQuando microservi\u00e7os s\u00e3o gerenciados pelo Kubernetes, por exemplo, na plataforma OpenShift, eles s\u00e3o dimensionados automaticamente para cima ou para baixo dependendo da carga. Como os microservi\u00e7os funcionam em pods, pode haver v\u00e1rias inst\u00e2ncias de um microservi\u00e7o cont\u00eainerizado em um \u00fanico ponto final, e o Kubernetes roteia as solicita\u00e7\u00f5es e balanceia a carga entre elas. E \u2013 na teoria \u2013 tudo isso deve funcionar perfeitamente.<\/p>\n

Lembramos que microservi\u00e7os s\u00e3o pequenos e ef\u00eameros. A efemeridade, que aqui significa a facilidade de surgimento e desaparecimento, \u00e9 frequentemente subestimada. O nascimento e a morte de uma inst\u00e2ncia de microservi\u00e7o em um pod s\u00e3o coisas esperadas, OpenShift e Kubernetes lidam bem com isso, e tudo funciona bem \u2013 mas novamente, na teoria.<\/p>\n

Como isso funciona na pr\u00e1tica<\/h3>\n

\nAgora, imagine que uma inst\u00e2ncia espec\u00edfica de um microservi\u00e7o, ou seja, um cont\u00eainer, se tornou inv\u00e1lida: ou n\u00e3o responde (erro 503), ou \u2013 o que \u00e9 pior \u2013 responde, mas muito lentamente. Ou seja, est\u00e1 falhando ou n\u00e3o responde \u00e0s solicita\u00e7\u00f5es, mas n\u00e3o \u00e9 removido automaticamente do pool. O que fazer neste caso? Tentar novamente? Remov\u00ea-lo do esquema de roteamento? E o que significa \"muito lentamente\" \u2013 quanto isso representa em n\u00fameros, e quem os define? Talvez seja melhor esperar e tentar novamente mais tarde? Se sim, quanto mais tarde?<\/p>\n

O que \u00e9 Pool Ejection no Istio<\/h3>\n

\nE aqui o Istio entra em a\u00e7\u00e3o com seus disjuntores, que removem temporariamente cont\u00eaineres com falhas do pool de recursos de roteamento e balanceamento de carga, implementando o procedimento de Pool Ejection.<\/p>\n

Utilizando a estrat\u00e9gia de detec\u00e7\u00e3o de outliers, o Istio detecta pods problem\u00e1ticos que se destacam do grupo e os remove do pool de recursos por um tempo determinado, chamado de \"janela de sono\". <\/p>\n

Para demonstrar como isso funciona no Kubernetes na plataforma OpenShift, come\u00e7aremos com uma captura de tela de microsservi\u00e7os funcionando normalmente do exemplo no reposit\u00f3rio. Demonstra\u00e7\u00f5es de Desenvolvedores da Red Hat<\/a><\/noindex>. Aqui temos dois pods, v1 e v2, cada um executando um cont\u00eainer. Quando as regras de roteamento do Istio n\u00e3o s\u00e3o usadas, o Kubernetes aplica por padr\u00e3o o balanceamento de carga circular:<\/p>\n

\"Istio<\/p>\n

Preparando para a falha<\/h3>\n

\nAntes de realizar a Eje\u00e7\u00e3o do Pool, precisamos criar uma regra de roteamento do Istio. Suponha que queremos distribuir solicita\u00e7\u00f5es entre os pods na raz\u00e3o de 50\/50. Al\u00e9m disso, aumentaremos o n\u00famero de cont\u00eaineres v2 de um para dois, assim:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nAgora definimos a regra de roteamento para que o tr\u00e1fego seja distribu\u00eddo entre os pods na raz\u00e3o de 50\/50.<\/p>\n
\"Istio
\nE aqui est\u00e1 como o resultado dessa regra se parece:<\/p>\n
\"Istio
\nPode-se argumentar que nesta captura n\u00e3o \u00e9 50\/50, mas sim 14:9, mas com o tempo a situa\u00e7\u00e3o se ajustar\u00e1.<\/p>\n
Causando a falha<\/h3>\n
\nAgora vamos derrubar um dos dois cont\u00eaineres v2, de modo que teremos um cont\u00eainer v1 funcionando, um cont\u00eainer v2 funcionando e um cont\u00eainer v2 com falha: <\/p>\n
\"Istio<\/p>\n
Consertando a falha<\/h3>\n
\nPortanto, temos um cont\u00eainer com falha, e chegou a hora da Eje\u00e7\u00e3o do Pool. Com uma configura\u00e7\u00e3o muito simples, excluiremos este cont\u00eainer com falha de quaisquer esquemas de roteamento por 15 segundos na expectativa de que ele se recupere (ou reinicie ou recupere o desempenho). Aqui est\u00e1 como essa configura\u00e7\u00e3o se parece e os resultados de sua execu\u00e7\u00e3o:<\/p>\n
\"Istio
\n\"Istio
\nComo pode ser visto, o cont\u00eainer com falha v2 n\u00e3o est\u00e1 mais sendo usado para roteamento de solicita\u00e7\u00f5es, pois foi removido do pool. Ap\u00f3s 15 segundos, ele voltar\u00e1 automaticamente ao pool. Na verdade, acabamos de mostrar como funciona a Eje\u00e7\u00e3o do Pool.<\/p>\n
Come\u00e7ando a construir a arquitetura<\/h3>\n
\nA Eje\u00e7\u00e3o do Pool em conjunto com as capacidades de monitoramento do Istio permite come\u00e7ar a construir uma estrutura de substitui\u00e7\u00e3o autom\u00e1tica de cont\u00eaineres com falha, para reduzir ou at\u00e9 mesmo eliminar paradas e falhas.
\n\u2003
\nA NASA tem um lema famoso \u2013 Failure Is Not an Option, creditado ao chefe de voos Gene Kranz<\/a><\/noindex>Em portugu\u00eas, isso pode ser traduzido como \"Fracasso n\u00e3o \u00e9 uma op\u00e7\u00e3o\", e a ideia aqui \u00e9 que tudo pode ser feito funcionar, desde que haja vontade suficiente. No entanto, na vida real, falhas n\u00e3o apenas ocorrem, elas s\u00e3o inevit\u00e1veis em todos os lugares e em tudo. E como lidar com elas no caso de microsservi\u00e7os? Na nossa opini\u00e3o, \u00e9 melhor confiar nas capacidades dos cont\u00eaineres, Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, quanto Istio<\/a><\/noindex>.<\/p>\n
O Istio, como mencionado anteriormente, implementa a bem-sucedida concep\u00e7\u00e3o de disjuntores do mundo f\u00edsico. Assim como um disjuntor el\u00e9trico desliga uma parte problem\u00e1tica do circuito, o Circuit Breaker do Istio interrompe a conex\u00e3o entre o fluxo de solicita\u00e7\u00f5es e o cont\u00eainer problem\u00e1tico quando h\u00e1 algo errado com o ponto de extremidade, por exemplo, quando o servidor falhou ou come\u00e7ou a falhar.<\/p>\n
No segundo caso, os problemas s\u00e3o ainda maiores, pois a lentid\u00e3o de um cont\u00eainer n\u00e3o apenas causa um efeito cascata de atrasos nos servi\u00e7os que dependem dele e, consequentemente, reduz o desempenho do sistema como um todo, mas tamb\u00e9m gera solicita\u00e7\u00f5es repetidas para um servi\u00e7o que j\u00e1 est\u00e1 funcionando lentamente, o que apenas agrava a situa\u00e7\u00e3o.<\/p>\n
Circuit Breaker em teoria<\/h3>\n
\nCircuit Breaker \u00e9 um proxy que controla o fluxo de solicita\u00e7\u00f5es para o ponto de extremidade. Quando esse ponto deixa de funcionar ou \u2013 dependendo das configura\u00e7\u00f5es definidas \u2013 come\u00e7a a apresentar lentid\u00e3o, o proxy corta a conex\u00e3o com o cont\u00eainer. O tr\u00e1fego \u00e9 ent\u00e3o redirecionado para outros cont\u00eaineres, simplesmente por causa do balanceamento de carga. A conex\u00e3o permanece aberta (open) durante um intervalo de descanso definido, digamos, dois minutos, e depois \u00e9 considerada semi-aberta (half-open). A tentativa de enviar a pr\u00f3xima solicita\u00e7\u00e3o determina o estado futuro da conex\u00e3o. Se o servi\u00e7o estiver funcionando bem, a conex\u00e3o retorna ao estado operacional e novamente se torna fechada (closed). Se houver algo errado com o servi\u00e7o, a conex\u00e3o \u00e9 quebrada novamente e o intervalo de descanso \u00e9 reativado. Aqui est\u00e1 um diagrama simplificado do ciclo de estados do Circuit Breaker:<\/p>\n
\"Istio
\n\u00c9 importante notar que tudo isso acontece em um n\u00edvel, por assim dizer, de arquitetura do sistema. Portanto, em algum momento, voc\u00ea precisar\u00e1 ensinar seus aplicativos a trabalhar com o Circuit Breaker, por exemplo, fornecendo um valor padr\u00e3o em resposta ou, se poss\u00edvel, ignorando a exist\u00eancia do servi\u00e7o. Para isso, utiliza-se o padr\u00e3o bulkhead, mas isso est\u00e1 al\u00e9m do escopo deste artigo.<\/p>\n
Circuit Breaker na pr\u00e1tica<\/h3>\n
\nComo exemplo, vamos executar duas vers\u00f5es do nosso microsservi\u00e7o de recomenda\u00e7\u00f5es no OpenShift. A vers\u00e3o 1 funcionar\u00e1 normalmente, enquanto na v2 vamos incorporar um delay para simular lentid\u00e3o no servidor. Para visualizar os resultados, utilizamos a ferramenta siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nParece que tudo est\u00e1 funcionando, mas a que custo? \u00c0 primeira vista, temos 100% de disponibilidade, mas observe \u2013 a dura\u00e7\u00e3o m\u00e1xima da transa\u00e7\u00e3o chega a 12 segundos. Este \u00e9 claramente um gargalo, e precisamos solucion\u00e1-lo.<\/p>\n
Para isso, usaremos o Istio para evitar chamadas para cont\u00eaineres lentos. Veja como \u00e9 a configura\u00e7\u00e3o correspondente utilizando o Circuit Breaker:<\/p>\n
\"Istio
\nA \u00faltima linha com o par\u00e2metro httpMaxRequestsPerConnection sinaliza que a conex\u00e3o deve ser interrompida ao tentar criar uma nova \u2013 segunda \u2013 conex\u00e3o al\u00e9m da j\u00e1 existente. Como nosso cont\u00eainer simula um servi\u00e7o lento, essas situa\u00e7\u00f5es ocorrer\u00e3o periodicamente, e ent\u00e3o o Istio retornar\u00e1 um erro 503, enquanto isso, o siege mostrar\u00e1:<\/p>\n
\"Istio<\/p>\n
Ok, temos o Circuit Breaker, e agora?<\/h3>\n
\nAssim, implementamos a desconex\u00e3o autom\u00e1tica sem alterar o c\u00f3digo-fonte dos servi\u00e7os. Usando o Circuit Breaker e o procedimento de Eje\u00e7\u00e3o de Pool descrito acima, podemos remover cont\u00eaineres lentos do pool de recursos at\u00e9 que eles se normalizem e verificar seu estado em intervalos regulares \u2013 no nosso exemplo, a cada duas minutos (par\u00e2metro sleepWindow).<\/p>\n
Observe que a capacidade do aplicativo de reagir ao erro 503 ainda \u00e9 definida no n\u00edvel de seu c\u00f3digo-fonte. Existem v\u00e1rias estrat\u00e9gias para trabalhar com o Circuit Breaker, que s\u00e3o aplicadas dependendo da situa\u00e7\u00e3o.<\/p>\n
No pr\u00f3ximo post:<\/b> vamos falar sobre rastreamento e monitoramento, que j\u00e1 est\u00e3o integrados ou s\u00e3o facilmente adicionados ao Istio, al\u00e9m de como introduzir erros no sistema intencionalmente.
\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\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\udd47Circuit Breaker do Istio: desligando cont\u00eaineres com falhas | ProHoster","description":"As festas acabaram e estamos de volta com nossa segunda postagem da s\u00e9rie sobre o Istio Service Mesh.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/54987","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}