Everything in the market talks to the database, so every other tier's error is partly its error. Bring it back first, and the rest of the survey list gets shorter on its own.

It fails twice

A database Pod on a new cluster usually fails in two layers, one after the other:

kubectl describe pod -l app=market-db | tail -3

Warning  FailedScheduling  0/1 nodes are available: pod has unbound immediate PersistentVolumeClaims.

The claim was never recreated on the new cluster. Create it with the same name and access mode the Deployment expects, and let the default StorageClass provision the volume:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: market-db-data
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 1Gi

Then look again. The Pod is scheduled now, and the next layer speaks:

Warning  Failed  Error: secret "market-db-secrets" not found

The password Secret did not travel either. Scheduling happens before container creation, so the storage fault hid the configuration fault. Create the Secret with the key the Deployment references and the kubelet retries by itself.

kubectl create secret generic market-db-secrets --from-literal=POSTGRES_PASSWORD=…

Verify twice

kubectl get deploy market-db
kubectl get endpoints market-db

1/1 says the container is Ready. One endpoint says the Service will deliver the API's connections. Both, before you move on.

What not to do

Never delete a database's PersistentVolumeClaim to make an error go away. With a Delete reclaim policy the volume goes with it, and the data with the volume. Create what is missing; leave what exists.