Problemas de balanceo de carga con Spring Cloud Kubernetes
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?
davy.ai