Skip to content

Project · DevOps: Git, Docker, Kubernetes and CI/CD

Project: a train seat API on Kubernetes

Projectintermediate· about 5 hours· 7 steps

The brief

A rail-booking start-up wants its seat-availability API on Kubernetes. On a local cluster you load the image, set the train details in a ConfigMap, run three replicas with probes and limits behind a Service, roll out a new version, survive a broken release with a rollback, and write the policy check that stops unsafe Deployments in CI.

Why it matters

Deploying, updating and rolling back apps on Kubernetes is the core of most DevOps and platform jobs in India today, from product companies to banks running EKS or AKS. The same commands work on kind, minikube and a managed cluster, and the CKAD exam asks for exactly these tasks against the clock.

Skills you practise

  • kind or minikube
  • namespaces and ConfigMaps
  • Deployments with probes and resource limits
  • Services and port-forward
  • rolling updates and rollout undo
  • policy checks in JavaScript

You need

  • Docker Desktop or Docker Engine
  • kubectl and kind (or minikube); a cluster with 2 CPUs and 4 GB of memory is enough
  • A bash-style terminal: on Windows use Git Bash or WSL

What you will have at the end

k8s.yaml (ConfigMap, Deployment with probes and limits, Service) for the seat API, the rollout and rollback commands you used, and check-manifest.js, a tested policy check for CI.

How it is marked (rubric, 100 points)
Working deploymentAll output checks pass: Ready node, ConfigMap, 3/3 pods, the Service answering, the update and the rollback.35
Good manifestsPinned image, probes, requests and limits, labels that match, settings in a ConfigMap rather than the image.25
Policy checkcheck-manifest.js passes every test and its messages tell a developer exactly what to fix.20
Operating skillYou can explain how a rolling update avoids downtime, what you saw during the broken release, and why the fix must also go into Git.20

0/7 steps done

Step 1 of 7

Create a local cluster

kubectl talks to a local cluster called rail, and its node is Ready.

kind runs a whole Kubernetes cluster inside a Docker container, which makes it quick to create and throw away. kind create cluster also points kubectl at the new cluster by setting its context (kind-rail). Always check the context before you apply anything: at work, the same kubectl may also reach production.

Run this on your machine, then paste the output below
$ kubectl config current-context; kubectl get nodes
Your notes: k8s.yaml, check-manifest.js

Write down each command you ran. It goes into your project summary.