Remataron as vacacións e volvemos coa nosa segunda publicación da serie Istio Service Mesh.
O tema de hoxe é Circuit Breaker, que traducido ao ruso enxeñaría eléctrica significa "interruptor", na linguaxe común - "interruptor". Só en Istio esta máquina non desconecta un circuíto en curto ou sobrecargado, senón colectores defectuosos.
Como isto debería funcionar idealmente
Cando os microservizos son xestionados por Kubernetes, por exemplo, dentro da plataforma OpenShift, escalan e baixan automaticamente dependendo da carga. Dado que os microservizos se executan en pods, pode haber varias instancias dun microservizo en contedores nun punto final e Kubernetes encamiñará as solicitudes e o equilibrio de carga entre elas. E, idealmente, todo isto debería funcionar perfectamente.
Lembramos que os microservizos son pequenos e efémeros. A efémera, que aquí significa a facilidade de aparecer e desaparecer, adoita ser infravalorada. O nacemento e a morte doutra instancia dun microservizo nun pod son cousas bastante esperadas, OpenShift e Kubernetes manexan isto ben, e todo funciona moi ben, pero de novo en teoría.
Como funciona en realidade
Agora imaxina que unha instancia concreta dun microservizo, é dicir, un contedor, quedou inservible: ou non responde (erro 503), ou, o que é máis desagradable, responde, pero moi lentamente. Noutras palabras, faise falla ou non responde ás solicitudes, pero non se elimina automaticamente do grupo. Que se debe facer neste caso? Volver tentalo? Debo eliminalo do esquema de enrutamento? E que significa "moi lento": cantos son os números e quen os determina? Quizais dálle un descanso e téntao de novo máis tarde? Se é así, canto despois?
Que é Pool Ejection en Istio
E aquí Istio vén ao rescate coas súas máquinas de protección de interruptores, que eliminan temporalmente os contedores defectuosos da agrupación de recursos de enrutamento e equilibrio de carga, implementando o procedemento de expulsión da piscina.
Usando unha estratexia de detección de valores atípicos, Istio detecta os pods de curva que están fóra de liña e elimínaos do grupo de recursos durante un período de tempo especificado, chamado xanela de suspensión.
Para mostrar como funciona isto en Kubernetes na plataforma OpenShift, comecemos cunha captura de pantalla dos microservizos que funcionan normalmente a partir do exemplo do repositorio . Aquí temos dous pods, v1 e v2, cada un con un contedor. Cando non se usan as regras de enrutamento de Istio, Kubernetes utiliza por defecto un enrutamento round-robin uniformemente equilibrado:
Preparándose para un accidente
Antes de facer a expulsión do grupo, cómpre crear unha regra de enrutamento de Istio. Digamos que queremos distribuír as solicitudes entre pods nunha proporción de 50/50. Ademais, aumentaremos o número de contedores v2 de un a dous, así:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Agora establecemos unha regra de enrutamento para que o tráfico se distribúa entre os pods nunha proporción 50/50.
Este é o resultado desta regra:
Podes atopar erros no feito de que esta pantalla non sexa 50/50, senón 14:9, pero co paso do tempo a situación mellorará.
Facendo un fallo
Agora imos desactivar un dos dous contedores v2 para que teñamos un contenedor v1 saudable, un contenedor v2 saudable e un contenedor v2 defectuoso:
Arranxando o fallo
Entón, temos un recipiente defectuoso e é hora de expulsar a piscina. Usando unha configuración moi sinxela, excluiremos este contedor fallido de calquera esquema de enrutamento durante 15 segundos coa esperanza de que volva a un estado saudable (reiniciar ou restaurar o rendemento). Este é o aspecto desta configuración e os resultados do seu traballo:
Como podes ver, o contenedor v2 fallido xa non se utiliza para as solicitudes de enrutamento porque foi eliminado do grupo. Pero despois de 15 segundos volverá automaticamente á piscina. En realidade, só mostramos como funciona Pool Ejection.
Imos comezar a construír arquitectura
Pool Ejection, combinado coas capacidades de monitorización de Istio, permítelle comezar a construír un marco para a substitución automática de contedores defectuosos para reducir, se non eliminar, o tempo de inactividade e os fallos.
A NASA ten un lema forte: o fracaso non é unha opción, cuxo autor é considerado o director de voo . Pódese traducir ao ruso como "O fracaso non é unha opción", e o significado aquí é que todo se pode facer funcionar se tes suficiente vontade. Non obstante, na vida real, os fracasos non só ocorren, son inevitables, en todas partes e en todo. E como tratar con eles no caso dos microservizos? Na nosa opinión, é mellor confiar non na forza de vontade, senón nas capacidades dos contedores, , E .
Istio, como escribimos anteriormente, implementa o concepto de interruptores automáticos, que se demostrou ben no mundo físico. E do mesmo xeito que un interruptor de circuíto eléctrico apaga unha sección problemática dun circuíto, o software Circuit Breaker de Istio abre a conexión entre un fluxo de solicitudes e un contenedor de problemas cando algo está mal no punto final, por exemplo, cando o servidor falla ou comeza a fallar. máis amodo.
Ademais, no segundo caso só hai máis problemas, xa que os freos dun contedor non só provocan unha fervenza de atrasos nos servizos que acceden a el e, como consecuencia, reducen o rendemento do sistema no seu conxunto, senón que tamén xeran reiterados. solicitudes a un servizo xa lento, o que só agrava a situación.
Interruptor en teoría
Circuit Breaker é un proxy que controla o fluxo de solicitudes a un punto final. Cando este punto deixa de funcionar ou, dependendo da configuración especificada, comeza a ralentizarse, o proxy rompe a conexión co contedor. O tráfico é entón redirixido a outros contedores, simplemente debido ao equilibrio de carga. A conexión permanece aberta durante unha xanela de suspensión determinada, digamos dous minutos, e despois considérase semiaberta. Un intento de enviar a seguinte solicitude determina o estado adicional da conexión. Se todo está ben co servizo, a conexión volve a funcionar e pecharase de novo. Se aínda hai algo mal co servizo, desconéctase a conexión e volve activarse a xanela de suspensión. Aquí tes o aspecto dun diagrama de estado de interruptor simplificado:
É importante notar aquí que todo isto ocorre a nivel de, por así dicir, arquitectura do sistema. Así que nalgún momento terás que ensinar ás túas aplicacións a traballar con Circuit Breaker, como proporcionar un valor predeterminado en resposta ou, se é posible, ignorar a existencia do servizo. Para iso úsase un patrón de anteparos, pero está fóra do alcance deste artigo.
Circuit Breaker en práctica
Por exemplo, executaremos dúas versións do noso microservizo de recomendación en OpenShift. A versión 1 funcionará ben, pero na v2 incorporaremos un atraso para simular desaceleracións no servidor. Para ver os resultados, use a ferramenta :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Todo parece funcionar, pero a que custo? A primeira vista, temos unha dispoñibilidade do 100 %, pero bótalle unha ollada máis atentamente: a duración máxima da transacción é de ata 12 segundos. Este é claramente un pescozo de botella e hai que ampliar.
Para iso, utilizaremos Istio para eliminar as chamadas a contedores lentos. Así se ve a configuración correspondente usando Circuit Breaker:
A última liña co parámetro httpMaxRequestsPerConnection indica que a conexión debe desconectarse ao tentar crear outra, unha segunda conexión, ademais da existente. Dado que o noso contedor simula un servizo lento, tales situacións aparecerán periódicamente e, a continuación, Istio devolverá un erro 503, pero isto é o que mostrará Siege:
OK, temos Circuit Breaker, que segue?
Entón, implementamos o apagado automático sen tocar o código fonte dos propios servizos. Usando Circuit Breaker e o procedemento de expulsión da piscina descrito anteriormente, podemos eliminar os recipientes de freo da agrupación de recursos ata que volvan á normalidade e comprobar o seu estado cunha frecuencia especificada; no noso exemplo, isto é de dous minutos (parámetro sleepWindow).
Teña en conta que a capacidade dunha aplicación para responder a un erro 503 aínda está definida no nivel do código fonte. Hai moitas estratexias para usar Circuit Breaker, dependendo da situación.
Na seguinte publicación: Falaremos do rastrexo e seguimento que xa está integrado ou engadido facilmente a Istio, así como de como introducir erros intencionadamente no sistema.
Fonte: www.habr.com