Skip to main content
In this tutorial you’ll deploy the multi-tier voting application to a Minikube cluster. The app consists of five components: voting frontend, result frontend, redis, postgres, and a worker. We’ll create one Pod manifest per component and Services to expose them. The project directory is named voting-app. Prerequisites:
  • Minikube or a Kubernetes cluster
  • kubectl configured to target your cluster
  • Files saved under the voting-app directory
Quick reference:

Pod manifests

Create the following Pod YAML files inside the voting-app directory. Voting app Pod (voting-app-pod.yaml)
The voting app image referenced above comes from a sample repository similar to the one below: dockersamples/example-voting-app
A screenshot of a GitHub repository page for "dockersamples/example-voting-app," showing the Code tab with a file list, branch selector, commit info, and action buttons like "Go to file," "Add file," and "Code."
Result app Pod (result-app-pod.yaml)
Redis Pod (redis-pod.yaml)
Postgres Pod (postgres-pod.yaml) The worker and result components require a PostgreSQL database. For this demo we inject credentials via plain environment variables in the Pod manifest. In production, store credentials securely using Kubernetes Secrets or an external vault.
Using plain text environment variables for database credentials is convenient for demos, but in production you should store credentials in Kubernetes Secrets or a vault solution.
Worker Pod (worker-app-pod.yaml) The worker is an internal background process and does not expose network ports, so we omit the ports section.

Service manifests

Create Services to expose the Pods. Redis and Postgres use internal ClusterIP Services. The frontends are exposed via NodePort so they are accessible from your host/Minikube. Redis Service (redis-service.yaml)
Postgres Service (postgres-service.yaml / named db)
Voting Service (voting-app-service.yaml) — NodePort on 30004
Result Service (result-app-service.yaml) — NodePort on 30005

Resources summary

Apply manifests and verify

From the voting-app directory (where all YAML files are saved), apply the manifests in the following recommended order (frontend first, then datastore services, then worker, then result frontend): Example file listing
Create resources
Check status of Pods and Services
Sample expected output (condensed)

Access the frontends (Minikube)

If using Minikube, get accessible URLs:
Example:
Open the voting service URL in a browser and cast votes. Flow summary:
  • Voting frontend records votes in Redis.
  • Worker reads votes from Redis and writes aggregates into Postgres.
  • Result frontend reads aggregated totals from Postgres and displays them.
If vote counts do not update:
  • Verify Postgres env variables (POSTGRES_USER, POSTGRES_PASSWORD) match what worker/result expect.
  • Ensure Service selectors match Pod labels exactly.

Conclusion

You have successfully deployed the multi-tier voting application to Kubernetes:
  • Created Pods for voting, result, redis, postgres, and worker.
  • Provided ClusterIP services for internal components (redis, db).
  • Exposed frontends via NodePort services (voting and result).
  • Verified end-to-end behavior by casting votes and viewing results.
Further reading and references:

Watch Video