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

Las vacaciones han terminado y regresamos con nuestra segunda publicaci\u00f3n de la serie sobre Istio Service Mesh.<\/p>\n

\"Istio
\n
\nEl tema de hoy es Circuit Breaker, que en t\u00e9rminos el\u00e9ctricos se traduce como \u00abdisyuntor\u00bb o, coloquialmente, \u00abautom\u00e1tico de protecci\u00f3n\u00bb. En Istio, este disyuntor no interrumpe un circuito que se ha cortocircuitado o sobrecargado, sino que apaga contenedores defectuosos.
\n<\/a><\/noindex><\/p>\n

C\u00f3mo deber\u00eda funcionar en ideal<\/h3>\n

\nCuando los microservicios son gestionados por Kubernetes, por ejemplo, en la plataforma OpenShift, se escalan autom\u00e1ticamente hacia arriba y hacia abajo seg\u00fan la carga. Dado que los microservicios funcionan en pods, puede haber varias instancias de un microservicio containerizado en un mismo punto final, y Kubernetes enruta las solicitudes y balancea la carga entre ellas. Y, en ideal, todo esto deber\u00eda funcionar perfectamente.<\/p>\n

Recordemos que los microservicios son peque\u00f1os y ef\u00edmeros. La efimeridad, que aqu\u00ed se refiere a la facilidad de aparici\u00f3n y desaparici\u00f3n, a menudo se subestima. El nacimiento y la muerte de cada instancia de un microservicio en un pod son cosas bastante esperadas; OpenShift y Kubernetes manejan esto bien y todo funciona de maravilla, pero de nuevo, esto es solo en teor\u00eda.<\/p>\n

C\u00f3mo funciona realmente<\/h3>\n

\nAhora imagina que una instancia espec\u00edfica de un microservicio, es decir, un contenedor, ha fallado: o no responde (error 503) o, lo que es peor, responde, pero demasiado lento. En otras palabras, presenta fallos intermitentes o no responde a las solicitudes, pero no se elimina autom\u00e1ticamente del pool. \u00bfQu\u00e9 se debe hacer en este caso? \u00bfRepetir la solicitud? \u00bfEliminarlo del esquema de enrutamiento? \u00bfY qu\u00e9 significa \u00abdemasiado lento\u00bb? \u00bfCu\u00e1nto es eso en n\u00fameros y qui\u00e9n los establece? \u00bfQuiz\u00e1s simplemente darle un respiro y probar m\u00e1s tarde? Si es as\u00ed, \u00bfcu\u00e1nto m\u00e1s tarde?<\/p>\n

Qu\u00e9 es Pool Ejection en Istio<\/h3>\n

\nAqu\u00ed es donde Istio entra en acci\u00f3n con sus disyuntores autom\u00e1ticos Circuit Breaker, que eliminan temporalmente los contenedores defectuosos del pool de recursos de enrutamiento y balanceo de carga, implementando el procedimiento de Pool Ejection.<\/p>\n

Utilizando una estrategia de detecci\u00f3n de anomal\u00edas (outlier detection), Istio detecta pods err\u00e1ticos que se desv\u00edan de la norma y los retira del pool de recursos durante un tiempo determinado, conocido como \u00abventana de sue\u00f1o\u00bb (sleep window). <\/p>\n

Para mostrar c\u00f3mo funciona esto en Kubernetes en la plataforma OpenShift, comencemos con una captura de pantalla de microservicios operativos del ejemplo en el repositorio. Demos de Red Hat Developer<\/a><\/noindex>. Aqu\u00ed tenemos dos pods, v1 y v2, cada uno corriendo un contenedor. Cuando no se utilizan las reglas de enrutamiento de Istio, Kubernetes aplica por defecto un enrutamiento c\u00edclico equilibrado:<\/p>\n

\"Istio<\/p>\n

Prepar\u00e1ndonos para la falla<\/h3>\n

\nAntes de realizar la Eliminaci\u00f3n de Pool, debemos crear una regla de enrutamiento de Istio. Supongamos que queremos distribuir las solicitudes entre los pods en una proporci\u00f3n de 50\/50. Adem\u00e1s, aumentaremos el n\u00famero de contenedores de v2 de uno a dos, as\u00ed:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nAhora establecemos una regla de enrutamiento para que el tr\u00e1fico se distribuya entre los pods en una proporci\u00f3n de 50\/50.<\/p>\n
\"Istio
\nY as\u00ed es como se ve el resultado de esta regla:<\/p>\n
\"Istio
\nSe podr\u00eda argumentar que en esta pantalla no es 50\/50, sino 14:9, pero con el tiempo la situaci\u00f3n se ajustar\u00e1.<\/p>\n
Provocando la falla<\/h3>\n
\nAhora dejaremos fuera de operaci\u00f3n uno de los dos contenedores v2, de modo que tengamos un contenedor v1 funcionando, un contenedor v2 funcionando y un contenedor v2 fallido: <\/p>\n
\"Istio<\/p>\n
Reparando la falla<\/h3>\n
\nAs\u00ed que tenemos un contenedor fallido, y ha llegado el momento de la Eliminaci\u00f3n de Pool. Con una configuraci\u00f3n muy simple, excluiremos este contenedor fallido de cualquier esquema de enrutamiento durante 15 segundos, a la espera de que se recupere a un estado operativo (ya sea reinici\u00e1ndose o restaurando su rendimiento). As\u00ed es como se ve esta configuraci\u00f3n y los resultados de su ejecuci\u00f3n:<\/p>\n
\"Istio
\n\"Istio
\nComo se puede ver, el contenedor v2 fallido ya no se utiliza para el enrutamiento de solicitudes, ya que fue excluido del pool. Sin embargo, despu\u00e9s de 15 segundos, volver\u00e1 autom\u00e1ticamente al pool. En realidad, acabamos de mostrar c\u00f3mo funciona la Eliminaci\u00f3n de Pool.<\/p>\n
Comenzando a construir la arquitectura<\/h3>\n
\nLa Eliminaci\u00f3n de Pool combinada con las capacidades de monitoreo de Istio permite comenzar a construir un marco para la sustituci\u00f3n autom\u00e1tica de contenedores fallidos, con el fin de reducir, e incluso eliminar, los tiempos de inactividad y fallas.
\n\u2003
\nNASA tiene un lema muy conocido: Failure Is Not an Option, cuyo autor es el director de vuelos Gene Kranz<\/a><\/noindex>. En espa\u00f1ol se podr\u00eda traducir como \u00abEl fracaso no es una opci\u00f3n\u00bb, y aqu\u00ed el significado es que todo se puede hacer funcionar con suficiente determinaci\u00f3n. Sin embargo, en la vida real, las fallas no solo ocurren, son inevitables, en todas partes y en todo. \u00bfY c\u00f3mo lidiar con ellas en el caso de los microservicios? En nuestra opini\u00f3n, es mejor confiar no en la fuerza de voluntad, sino en las capacidades de los contenedores. Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>como Istio<\/a><\/noindex>.<\/p>\n
Istio, como ya hemos mencionado antes, implementa la probada en el mundo f\u00edsico idea de los interruptores autom\u00e1ticos. As\u00ed como un disyuntor el\u00e9ctrico desconecta la parte problem\u00e1tica de un circuito, el Circuit Breaker en Istio interrumpe la conexi\u00f3n entre el flujo de solicitudes y el contenedor problem\u00e1tico cuando hay algo mal con el punto final, por ejemplo, cuando el servidor se ha ca\u00eddo o ha comenzado a ralentizarse.<\/p>\n
Adem\u00e1s, en el segundo caso hay a\u00fan m\u00e1s problemas, ya que la lentitud de un contenedor no solo causa una cascada de retrasos en los servicios que acceden a \u00e9l y, como consecuencia, disminuye el rendimiento del sistema en general, sino que tambi\u00e9n genera solicitudes repetidas hacia un servicio que ya est\u00e1 funcionando lentamente, lo que solo agrava la situaci\u00f3n.<\/p>\n
Circuit Breaker en teor\u00eda<\/h3>\n
\nCircuit Breaker es un proxy que controla el flujo de solicitudes hacia un punto final. Cuando este punto deja de funcionar o, dependiendo de la configuraci\u00f3n establecida, comienza a ralentizarse, el proxy rompe la conexi\u00f3n con el contenedor. El tr\u00e1fico se redirige a otros contenedores, simplemente por razones de balanceo de carga. La conexi\u00f3n permanece abierta (open) durante un per\u00edodo de tiempo de espera establecido, digamos, dos minutos, y luego se considera semiabierta (half-open). El intento de enviar la siguiente solicitud determina el estado de la conexi\u00f3n. Si todo est\u00e1 bien con el servicio, la conexi\u00f3n vuelve a su estado operativo y se cierra (closed) nuevamente. Si el servicio sigue teniendo problemas, la conexi\u00f3n se interrumpe y se vuelve a iniciar el per\u00edodo de espera. As\u00ed es como se ve un diagrama simplificado de los estados del Circuit Breaker:<\/p>\n
\"Istio
\nEs importante se\u00f1alar que todo esto ocurre a nivel de arquitectura del sistema, por lo que en alg\u00fan momento tendr\u00e1s que ense\u00f1ar a tus aplicaciones a trabajar con Circuit Breaker, por ejemplo, proporcionando un valor por defecto en respuesta o, si es posible, ignorando la existencia del servicio. Para ello se utiliza el patr\u00f3n bulkhead, aunque esto est\u00e1 fuera del alcance de este art\u00edculo.<\/p>\n
Circuit Breaker en la pr\u00e1ctica<\/h3>\n
\nPara ilustrar, ejecutaremos en OpenShift dos versiones de nuestro microservicio de recomendaciones. La versi\u00f3n 1 funcionar\u00e1 normalmente, mientras que en v2 incorporaremos una demora para simular una ralentizaci\u00f3n en el servidor. Para ver los resultados, se utiliza la herramienta siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nTodo parece funcionar, \u00bfpero a qu\u00e9 precio? A primera vista, tenemos un 100 % de disponibilidad, pero observa: la duraci\u00f3n m\u00e1xima de la transacci\u00f3n es de 12 segundos. Esto es claramente un cuello de botella y debe resolverse.<\/p>\n
Para ello, utilizaremos Istio para excluir las solicitudes a los contenedores lentos. As\u00ed es como se ve la configuraci\u00f3n correspondiente utilizando Circuit Breaker:<\/p>\n
\"Istio
\nLa \u00faltima l\u00ednea con el par\u00e1metro httpMaxRequestsPerConnection indica que la conexi\u00f3n debe interrumpirse al intentar crear una nueva \u2013 segunda \u2013 conexi\u00f3n adem\u00e1s de la que ya existe. Dado que nuestro contenedor simula un servicio lento, estas situaciones surgir\u00e1n peri\u00f3dicamente, y entonces Istio devolver\u00e1 un error 503, y esto es lo que mostrar\u00e1 siege:<\/p>\n
\"Istio<\/p>\n
Bien, tenemos Circuit Breaker, \u00bfy ahora qu\u00e9?<\/h3>\n
\nAs\u00ed que hemos implementado la desconexi\u00f3n autom\u00e1tica sin tocar el c\u00f3digo fuente de los propios servicios. Usando Circuit Breaker y el procedimiento de Ejectaci\u00f3n de Pool descrito anteriormente, podemos eliminar de la agrupaci\u00f3n de recursos los contenedores que est\u00e1n fallando hasta que se recuperen, y verificar su estado con una frecuencia definida \u2013 en nuestro ejemplo, cada dos minutos (par\u00e1metro sleepWindow).<\/p>\n
Ten en cuenta que la capacidad de la aplicaci\u00f3n para reaccionar a un error 503 sigue estando determinada a nivel de su c\u00f3digo fuente. Existen m\u00faltiples estrategias de trabajo con Circuit Breaker que se aplican seg\u00fan la situaci\u00f3n.<\/p>\n
En la pr\u00f3xima publicaci\u00f3n:<\/b> hablaremos sobre el trazado y monitoreo que ya est\u00e1n integrados o se pueden agregar f\u00e1cilmente en Istio, as\u00ed como sobre c\u00f3mo introducir errores en el sistema intencionadamente.
\n
Fuente: 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\udd47Circuit Breaker de Istio: desconectando contenedores defectuosos | ProHoster","description":"Las vacaciones han terminado y regresamos con nuestra segunda publicaci\u00f3n de la serie sobre Istio Service Mesh.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/54987","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}