plains-ya4c9o has three Deployments, a Job and a CronJob. Each is wrong in a different way. Fix them in any order.

kubectl get deploy,jobs,cronjobs -n plains-ya4c9o
kubectl get pods -n plains-ya4c9o

The Deployments

Read READY, UP-TO-DATE and AVAILABLE for each one.

market-web has a rollout in progress to an image that does not exist. Three old Pods serve; one new Pod is stuck. Check the revisions, then go back:

kubectl rollout history deploy/market-web -n plains-ya4c9o
kubectl get pods -n plains-ya4c9o -l app=market-web

market-worker shows 0/0. It needs 2 replicas.

market-api has Pods that restart forever. Read the logs, then check the image the template asks for:

kubectl logs deploy/market-api -n plains-ya4c9o
kubectl get deploy market-api -n plains-ya4c9o -o jsonpath='{.spec.template.spec.containers[0].image}'

The template points at stackmonsters/crasher, a placeholder that exits on start. The container is named crasher. The real image is stackmonsters/monster-market-api.

The Job and the CronJob

nightly-export is a Job whose command exits 1. Read why it stopped retrying:

kubectl describe job nightly-export -n plains-ya4c9o

A Job's template cannot be edited. Delete it and create one with the same name and a command that succeeds. The export prints exported:

kubectl delete job nightly-export -n plains-ya4c9o
kubectl create job nightly-export --image=busybox -n plains-ya4c9o -- sh -c 'echo exported'

report is a CronJob on * * * * * that keeps every finished Job. Set it to every five minutes and keep one successful Job:

kubectl patch cronjob report -n plains-ya4c9o -p '{"spec":{"schedule":"*/5 * * * *","successfulJobsHistoryLimit":1}}'

The last objective is a question: when a Deployment wants 3 Pods and one dies, which object creates the replacement?