Request processing error; nested exception is fake.Exception RetryableException: Connection timeout expired when executing GET http://fraud:8081/api/v1/fraud-check/6

[codersergg]

I'm doing a microservices deployment in k8s.
Zipkin shows error: Request processing error; nested exception is fake.Exception RetryableException: Connection timeout expired when executing GET http://fraud:8081/api/v1/fraud-check/6 .
Rabbitmq is not working.
I can't figure out what's going on.

https://github.com/codersergg/microservices-and-distributed-systems

NAME READY STATUS RESTARTS AGE
pod/customer-5b8d7cd7dd-7ppkv 1/1 Running 2 (22m ago) 45m
pod/fraud-bc6fb777c-6fkdp 1/1 Running 2 (22m ago) 43m
pod/notification-79997f988c-snwx7 1/1 Running 2 (22m ago) 44m
pod/postgres-0 1/1 Running 2 (22m ago) 55m
pod/rabbitmq-0 1/1 Running 4 (22m ago) 55m
pod/zipkin-0 1/1 Running 2 (22m ago) 55m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/customer LoadBalancer 10.104.88.212 127.0.0.1 80:31989/TCP 45m
service/fraud NodePort 10.102.20.243 80:30348/TCP 43m
service/kubernetes ClusterIP 10.96.0.1 443/TCP 56m
service/notification NodePort 10.101.126.40 80:31045/TCP 44m
service/rabbitmq NodePort 10.97.190.10 15672:31672/TCP,5672:30672/TCP 55m
service/zipkin LoadBalancer 10.107.29.196 127.0.0.1 9411:31734/TCP 55m

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/customer 1/1 1 1 45m
deployment.apps/fraud 1/1 1 1 43m
deployment.apps/notification 1/1 1 1 44m

NAME DESIRED CURRENT READY AGE
replicaset.apps/customer-5b8d7cd7dd 1 1 1 45m
replicaset.apps/fraud-bc6fb777c 1 1 1 43m
replicaset.apps/notification-79997f988c 1 1 1 44m

NAME READY AGE
statefulset.apps/postgres 1/1 55m
statefulset.apps/rabbitmq 1/1 55m
statefulset.apps/zipkin 1/1 55m

[fallousamb]

Hello I'm facing the same problem while registring a customer
Did you resolve your problem ?
Thanks !

[DmitriKonnovNN]

Hi!
I hope you guys managed to resolve this issue. To everyone who's currently struggling with this annoying problem,my understanding of the issue.
First of all, let's make it clear: This issue turns out its ugly head iff we make use of our micro services running on our localhost. This is okay because we've not dockerized all the services yet and we perhaps don't want to as our microservices aren't fully done yet.
Well, our gateway and eureka seem to mix up host configs. Eureka make use of host.docker.internal that's configured by docker and is 172.20.10.5 (on Windows 10); Spring Cloud Gateway per default uses ribbon as load-balancer implementation, which seems to erroneously forward our request to 172.20.10.5 (host.docker.internal) as well. And that's the issue. Our services (as long as we started them on localhost without dockerizing) ain't there up. They're up and running on 127.0.0.1.

Below you can find some solutions:
https://localcoder.org/spring-boot-cloud-eurka-windows-10-eurkea-returns-host-docker-internal-for-clien
https://dimitr.im/fix-eureka-localhost