Score:0

Backend URL variable doesn't point to the correct port

in flag

I just deployed frontend and backend pods, and there's an issue with connectivity between them.

The backend pod is configured in the following way:

apiVersion: v1
kind: Pod
metadata:
  name: af-backend-pod
  labels:
    name: af-backend-pod
    app: adv-format
spec:
  containers:
  - name: af-backend
    image: localhost:5000/backend:1.2
    ports:
    - containerPort: 4040
    env:
    - name: NODE_ENV
      value: "test"

Backend pod's service:

apiVersion: v1
kind: Service
metadata:
  name: af-backend
  labels:
    name: af-backend-service
    app: adv-format
spec:
  ports:
  - port: 4040
    targetPort: 6011
  selector:
    name: af-backend-pod
    app: adv-format

The issue appears when the frontend tries to call the backend using its name defined in the pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: af-frontend-pod
  labels:
    name: af-frontend-pod
    app: adv-format
spec:
  containers:
  - name: af-frontend
    image: localhost:5000/frontend:1.1
    ports:
    - containerPort: 80
    env:
    - name: REACT_APP_SETUP
      value: "test"
    - name: REACT_APP_BACKEND_URL
      value: "af-backend"             # <- this
    - name: REACT_APP_BACKEND_PORT
      value: "6011"

Currently, the frontend is exposed by a NodePort service at port 30120. Logging errors to console shows that the frontend tries to call the backend using URL like http://10.11.12.13:30120/ which is incorrect: I'd expect to see the backend API at port 6011, internally.

Is my understanding correct? Or should I expose the backend service to be accessible externally as well?

Or maybe there's a way to format the backend's URL, cutting out the port and replacing it with the desired one?

Mikołaj Głodziak avatar
id flag
Which version of Kubernetes did you use and how did you set up the cluster? Did you use bare metal installation or some cloud providor? It is important to reproduce your problem.
AbreQueVoy avatar
in flag
Hej Mikołaj. It's a 3-node cluster running on OpenStack server instances. It was installed with Kubespray; all nodes run v1.22.2.
Mikołaj Głodziak avatar
id flag
if I can see correctly you only set a variable to that host. Are you using any ingress?
AbreQueVoy avatar
in flag
No, I only use NodePort. And I suppose the issue here is related to the fact that React variables get set up on the build time, while here they are needed during runtime.
Mikołaj Głodziak avatar
id flag
Is it possible to hardcode it in the image?
Score:0
br flag

The problem is in Backend pod's sevice.spec.ports configuration. Target port is the port where the service will forward the traffic. In this case it is 4040, because the backend pod is listening on 4040. And the service port should be 6011 because the FE pod will be calling the service on this port. There is no need to expose the backend service as NodePort. You can also try netcat command from the FE container to check if the service the accessible. Command: nc -v Service_IP 6011 (expect "Succeeded" in response.)

apiVersion: v1
kind: Service
metadata:
  name: af-backend
  labels:
    name: af-backend-service
    app: adv-format
spec:
  ports:
  - port: 4040        << Wrong Should be 6011; FE Pod calls the service at 6011
    targetPort: 6011  << Wrong Should be 4040; backend pod container port 4040
  selector:
    name: af-backend-pod
    app: adv-format
AbreQueVoy avatar
in flag
Thanks, @Rajesh Dutta. I changed the `targetPort` to be 4040 as well and this port is exposed now. Yet, there's still no connectivity between frontend and backend when we talk about the website, but the backend is reachable from inside of the frontend container. What might be blocking the traffic, assuming that website frontend calls the correct URL of the backend?
Rajesh Dutta avatar
br flag
Did you also changed the `port` field to 6011? (1) Try to do nslookup af-backend and see if the DNS resolving in the FE. (2) Try with this setting in the FE pod. Normally its not required. - name: REACT_APP_BACKEND_URL value: "af-backend.default.svc"
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.