Deploy a Multi-Service App on Kubernetes
Part of the DevOps Roadmap
In short
This is where the separate pieces become one working system: a frontend, an API and a database on a cluster you control, reachable through one URL. It's the project interviewers love to ask about.
The practice project for this phase — deploy an application with multiple interconnected services (e.g. a frontend, backend, and database) onto a Kubernetes cluster, wiring together Deployments, Services, and Ingress.
Think of it like this
Running a small restaurant
A restaurant has a front counter, a kitchen and a storeroom. Customers only see the counter, the kitchen never talks to the street, and the storeroom keeps stock safe overnight. Your frontend, API and database are the same three rooms, connected by Services.
Watch it happen
The build plan
1/6Write Dockerfiles for frontend and API, build them with pinned tags and push to a registry like GHCR.
The big ideas
What you need to know
Manifests in Git
Keep every YAML file (or a Helm chart) in the repo, so the whole app can be rebuilt from scratch with one command.
Secrets stay out of Git
Create Secrets from the CLI or a secrets tool. Your README explains how, without the real values.
Probes and resources
Readiness probes and CPU or memory requests on every container. They make rollouts and scheduling behave.
Document it
A README with an architecture diagram, setup steps and what you'd improve. Reviewers read this first.
See it in code
Walk through the code
1containers:2 - name: api3 image: ghcr.io/you/shop-api:1.0.04 ports: [{ containerPort: 3000 }]5 env:6 - name: DATABASE_URL7 valueFrom: { secretKeyRef: { name: db-creds, key: url } }8 readinessProbe:9 httpGet: { path: /healthz, port: 3000 }10 periodSeconds: 511 resources:12 requests: { cpu: 100m, memory: 128Mi }13 limits: { memory: 256Mi }1/4A pinned image tag from your registry. Never latest in a project you want to roll back.
This is the container part of the API Deployment, the piece people most often get wrong. Your API needs a /healthz route that checks it can reach the database.
Save yourself the pain
Common mistakes
Oops
Exposing the database with a NodePort so you can 'check it from your laptop'.
Do this instead
Keep it ClusterIP only. Use kubectl port-forward svc/db 5432 when you need to look inside.
Oops
Shipping without probes, then seeing errors during every rollout.
Do this instead
Add readiness probes from day one, so new pods only get traffic once they're actually ready.
Your mission
First milestone: API plus database
Quick check
Your API pods are Running but users get errors for 20 seconds during every rollout. What's the most likely fix?
Go deeper
- 1Choose a simple multi-service sample app to keep focus on the Kubernetes configuration itself.
- 2Write Deployments, Services, ConfigMaps, and an Ingress for the full application.
- 3Document your manifest structure in a README so someone else could deploy it themselves.
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
