Kubernetes Cluster Deployment Project
Part of the DevOps Roadmap
In short
Running one pod is a tutorial. Running an app with Ingress, autoscaling, config, storage and health checks on a real cluster is what teams actually do. This project shows you can do the second one.
Build on Phase 8's practice project with a more complete setup — including Ingress, autoscaling, and persistent storage where relevant, showing production-adjacent Kubernetes fluency.
Think of it like this
The bus depot manager
A depot manager promises five buses on route 21 all day. If one breaks down, another is sent out. At rush hour, two extra buses go. Passengers just see buses arriving. Kubernetes is the depot manager; your manifests are the promise.
Watch it happen
A request through your cluster
GET shop.example.com
1/5The request reaches the Ingress controller, which owns the public address and the TLS certificate.
The big ideas
What you need to know
Must-have objects
Deployment, Service, Ingress, ConfigMap, Secret and a HorizontalPodAutoscaler. Add a StatefulSet or PVC if you run a database.
Probes and limits
Readiness and liveness probes, plus CPU and memory requests and limits on every container.
Package it
Use Helm or Kustomize so the same app can be installed with different values in another cluster.
Show it working
Record a short demo: load test, pods scaling up, one pod deleted and replaced, all with no errors.
See it in code
Walk through the code
1apiVersion: apps/v12kind: Deployment3metadata: { name: web }4spec:5 replicas: 26 selector: { matchLabels: { app: web } }7 template:8 metadata: { labels: { app: web } }9 spec:10 containers:11 - name: web12 image: ghcr.io/you/shop:3f2a9c113 resources:14 requests: { cpu: 100m, memory: 128Mi }15 limits: { memory: 256Mi }16 readinessProbe: { httpGet: { path: /health, port: 3000 } }1/4A Deployment named web that should always keep two pods running.
The two lines people forget most are resource requests and the readiness probe. The autoscaler needs CPU requests to calculate usage.
Save yourself the pain
Common mistakes
Oops
Running everything as a single pod with no probes and calling it production-ready.
Do this instead
Use at least two replicas, probes and resource requests. Then show what happens when a pod or node dies.
Oops
Putting database passwords straight into the Deployment YAML.
Do this instead
Use a Secret, ideally synced from a secrets manager, and reference it with envFrom or valueFrom.
Your mission
Milestone 1: app reachable via Ingress
Quick check
A pod is running but its app is still loading its cache. Which setting stops users hitting it too early?
Go deeper
- 1Extend your Phase 8 project with Ingress routing and a Horizontal Pod Autoscaler.
- 2Use Helm to package your application's manifests, if you haven't already.
- 3Document your cluster architecture with a simple diagram in your README.
More projects at this stop
End-to-End CI/CD Pipeline Project
Infrastructure as Code Project (Terraform)
Monitoring Stack Setup (Prometheus + Grafana)
Automated Deployment With Rollback Project
Multi-Environment (Dev / Staging / Prod) Setup
Portfolio Website or GitHub Showcase
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
