I am deploying a simple web application. I divided it into 3 pods:front end, back end, and postgres db. Each has services. I created LoadBalancer services each for my front end and back end. ClusterIP service for my postgres db pod. My front end is html/javascript/angularjs/jquery. Backend is Jersey based Java web services.Connection between backend and postgres is working nicely as I tested it from browser. Please see the below. But when I try to access same login web service call from my front end, it does not work.Please see below. No error messages in my backend and front end logs.In my local computer (Eclispe Jee+Tomcat), everything works fine as front end and back end reside on same Tomcat server. So my question is can I call LoadBalancer service from anothe LoadBalancer service in google kubernetes? Certain error is thrown on my front end back end pods, but it popped up spontenaously, not after my web service call. Here I put my deployment info postgres pod. Backend and front end deployment pretty similar to it, only LoadBalancer is added as type. How to access postgresql pod/service in google kubernetes
//The following call on browser to my web service works.
http://23.34.23.34:8080/LocWebService/rest/authorize/admin1
//The following call from my front end does not work on google kubernetes
$http.get("http://23.34.23.34:8080/LocWebService/rest/
authorize/"+$scope.Name)
//The following spontaneous error is thrown on my front end and back end
pods.
[http-nio-8080-exec-3] org.apache.coyote.http11.Http11Processor.service
Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged
at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method
name. HTTP method names must be tokenTechnically, your front end pods should be able to call the external IP of your backend pods and should be able to reach them. However, a better option would be for the front end pods to call the backend pods using the ClusterIP of the service (the same way the backend is calling the DB). You can still keep the service type as LoadBalancer in case you want the backends to be exposed directly.
As to why your specific case is not working, we'll need more logs or error messages to see what is happening with the packet.
Theoretically, what should happen is:
Pod => LB external IP => reach node IP tables => forwarded to backend pod
Now with this, the packet won't actually get past the local node's iptables, it will get DNATed immedialtely and forwarded to the correct backend pod. One possible issue I've seen before is that the backend pod is expecting traffic from an external source and since the traffic is not actually hitting the external LB IP and therefor not using an external IP as the source, the application doesn't take it.