Connecting fronted pod with backend pod

Create a service for your deployment and point your app to that service name The key to connecting a frontend to a backend is the backend Service. A Service creates a persistent IP address and DNS name entry so that the backend microservice can always be reached. A Service uses selectors to find the Pods that it routes traffic to.

First, configure the MySQL service as a ClusterIP service. It will be private, visible only for other services. This is could be done removing the line with the option type.

apiVersion: v1
kind: Service
metadata:
   name: app-api-mysql-svc
spec:
   selector:
     app: app-api-mysql
   ports:
     - protocol: TCP
       port: 80
       targetPort: [the port exposed by the mysql pod]

Now that you have your backend, you can create a frontend that connects to the backend. The frontend connects to the backend worker Pods by using the DNS name given to the backend Service. The DNS name is “app-api-mysql-svc”, which is the value of the name field in the preceding Service configuration file.

apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: app-api-mysql
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer

Similar to the backend, the frontend has service too. The configuration for the Service has type: LoadBalancer, which means that the Service uses the default load balancer of your cloud provider.

You can also proxy all your backend calls through your front end server

If you are routing (or willing to route) all your microservices/backend call thru the server side of your front end and if are deploying both your front end and backend in the same k8s cluster in the same namespace, then you can use KubeDNS add-on (If it is not available in your k8s cluster yet, you can check with the k8s admin) to resolve the backend service name to it's IP. From your front end server, Your backend service will always be resolvable by it's name.

Since you have kubeDNS in your k8s cluster, and both frontend and backend services resides in same k8s cluster and same namespace, we can make use of k8s' inbuilt service discovery mechanism. Backend service and frontend service will be discoverable each other by it's name. That means, you can simply use the DNS name "backend" to reach your backend service from your frontend pods. So, just proxy all the backend request through your front end nginx to your upstream backend service. In the frontend nginx pods, backend service's IP will resolvable for the domain name "backend". This will save you the CORS headache too. This setup is portable, meaning, it doesn't matter whether you are deploying in dev or stage or prod, name "backend" will always resolve to the corresponding backend.

More information you can find here: backend-frontend, frontend-backend-pod-connection.

Connecting Persistent Volume to pod

MySQL requires a PersistentVolume to store data. Their PersistentVolumeClaims will be created at the deployment step.

Many cluster environments have a default StorageClass installed. When a StorageClass is not specified in the PersistentVolumeClaim, the cluster’s default StorageClass is used instead.

When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provisioned based on the StorageClass configuration.

Here you can find detailed guide how to configure MySQL pod with Persisten Volume: pv-mysql-wordpress.

Check the guide on deploying wordpress and connecting to mysql with persistent volume.