es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

Problemas de balanceo de carga con Spring Cloud Kubernetes

21 Jul, 2023 Programación

Tenemos servicios de Spring Boot en ejecución en Kubernetes y estamos utilizando la funcionalidad de balanceador de carga de Spring Cloud Kubernetes con RestTemplate para realizar llamadas a otros servicios de Spring Boot. Una de las principales razones por las que lo tenemos implementado es histórica, ya que anteriormente ejecutábamos nuestros servicios en EC2 utilizando Eureka para el descubrimiento de servicios y después de la migración mantuvimos el cliente de descubrimiento de Spring/capacidad de balanceo de carga en el lado del cliente (actualizando las dependencias, etc., para que funcione con el proyecto Spring Cloud Kubernetes).

Tenemos un problema que cuando uno de los pods de destino deja de funcionar, tenemos múltiples fallos durante un período de tiempo con java.net.NoRouteToHostException, es decir, el balanceador de carga de Spring sigue intentando enviar a ese pod.

Entonces tengo algunas preguntas al respecto:

  • ¿No debería eliminarse automáticamente la instancia de destino cuando esto ocurre? ¿Así que podría suceder una vez, pero después de eso, la lista de pods de destino se reparará?

  • O, si no es así, ¿hay alguna otra configuración que necesitemos agregar para manejar esto, por ejemplo, reintentos/circuit breaker, etc.?

  • Una pregunta más general es, ¿qué beneficio aporta el balanceo de carga del lado del cliente de Spring con Kubernetes? Sin él, nuestro servicio aún podría llamar a otros servicios utilizando la funcionalidad de servicio/load balancing incorporada en Kubernetes, y esto debería manejar automáticamente el problema de los pods que se caen. La documentación de Spring también habla sobre la posibilidad de cambiar del modo POD al modo SERVICIO (https://docs.spring.io/spring-cloud-kubernetes/docs/current/reference/html/index.html#loadbalancer-for-kubernetes). ¿Pero no es este modo de servicio lo que hace automáticamente Kubernetes? Me pregunto si la solución más simple aquí no sería eliminar completamente el balanceador de carga de Spring. ¿Qué perderíamos entonces?

Tags:  , , ,

Answer

  1. Avatar for davy.ai
    davy.ai

    • La instancia objetivo debe eliminarse automáticamente cuando se apague. Spring Cloud Kubernetes Load Balancer se integra con Kubernetes para detectar cambios en el estado de los pods y servicios, y actualiza la lista de objetivos en consecuencia. Sin embargo, puede haber cierto retraso entre el momento en que un pod se apaga y cuando el balanceador de carga actualiza su lista. Durante este tiempo, las solicitudes aún pueden ser enviadas al pod apagado, lo que resulta en errores.
    • Para manejar este problema, se pueden agregar configuraciones de reintento y circuit breaker al proyecto. El reintento intentará volver a enviar la solicitud fallida a un pod diferente. El circuit breaker se puede utilizar para evitar enviar solicitudes al pod apagado y redirigirlas a uno alternativo.
    • Con Kubernetes, el equilibrio de carga en el lado del cliente no es estrictamente necesario ya que Kubernetes proporciona su propia funcionalidad incorporada de servicio/equilibrio de carga. Los beneficios del equilibrio de carga en el lado del cliente de Spring radican en un mayor control sobre las estrategias de equilibrio de carga, como round robin o weighted random, y en su capacidad para trabajar con otros componentes de Spring, como Ribbon. El modo de servicio en Spring Cloud Kubernetes Load Balancer es esencialmente una abstracción sobre los servicios de Kubernetes, con los que interactúa para obtener la lista de objetivos. Eliminar por completo el balanceador de carga de Spring significaría depender de la funcionalidad incorporada de servicio/equilibrio de carga de Kubernetes, que puede ser suficiente para algunos casos de uso, pero puede carecer del nivel de personalización e integración que Spring proporciona.

Comments are closed.