Kubernetes: Enabling Communication Between Angular Frontend and Express Backend

Frontend and Backend Development
1

Using minikube, my Angular app can’t resolve the Express backend’s DNS. How can Kubernetes route requests without manually setting NodePort?

apiVersion: v1
kind: Service
metadata:
  name: api-backend-svc
  labels:
    app: sample-service
    layer: backend
spec:
  type: NodePort
  ports:
    - port: 4000
      targetPort: 4000
  selector:
    app: sample-service
    layer: backend

curl http://api-backend-svc.default.svc.cluster.local:4000/api
2

In my experience managing a similar setup, switching the backend service to a ClusterIP type rather than NodePort proved beneficial for internal communication. Deploying both the frontend and backend within the same namespace ensured that Kubernetes DNS resolved service names correctly. I also verified that the pods were in a ready state and that the labels matched across deployments and services to avoid endpoint registration issues. This configuration allowed the Angular application to access the Express backend seamlessly via Kubernetes internal networking, eliminating the need for manual port configuration adjustments.

3

hey, try swtiching the service to clusterip, then use an ingress to route internally. check ns details too, sometimes the label mismatch messes up dns resolution. that worked fine for me in a similar setup.

4

hey, ive seen similar dns issues. have u thought about testing a headless service? sometimes a faulty label in the ns can break resolution. any idea if using an ingress might help or if there are missing endpoints? curious to hear more abt your set-up!

5

In addressing similar connectivity issues, I found that verifying consistency in service definitions and deployment labels was essential. I switched the backend service from a NodePort to a ClusterIP configuration, which allowed easier routing within the cluster. It was important to ensure that both the exposed ports and the label selectors in the service YAML exactly matched those in the pod deployment. Additionally, reviewing any network policies helped to identify if internal traffic was inadvertently blocked, ensuring the Angular frontend could properly access the Express backend.