Kubernetes fundamentals lab syllabus

This syllabus is the DarDevLab Kubernetes fundamentals module: a two-week, hands-on path from a local cluster (kind or k3s) through Pods, Deployments, Services, and Ingress, ending in a graded homework assignment Tunisian CS students can run on modest laptops. You should already have completed container basics—building an image and running docker compose—before Week 1 starts.

Faculty and mentors can adopt the outline as-is or slot it into the cloud-native learning 90-day plan as Weeks 5–6. DarDev engineers use the same object model on production clusters; this lab keeps scope tight so students learn kubectl and YAML, not cloud billing.

Who this module is for

• Third- and fourth-year CS students at ENSI, ESPRIT, ISI, or similar programs
• Bootcamp learners with Linux shell comfort and one containerized app
• Interns asked to kubectl get pods on day one without formal training
• Faculty who want a reproducible rubric instead of ad-hoc slide decks

Lab environment — kind or k3s

Every student runs a single-node cluster locally. kind (Kubernetes in Docker) suits Docker Desktop and WSL2 setups common in Tunis dorm laptops. k3s is lighter on RAM and works well on native Linux lab machines or a small VPS if the university blocks nested virtualization.

1. Install kubectl

   Match client version within one minor of the cluster API. Verify with kubectl version --client.

2. Create kind cluster

   kind create cluster --name dardevlab-k8s. Export KUBECONFIG path in README for graders.

3. Or install k3s

   curl installer on Linux; copy /etc/rancher/k3s/k3s.yaml to ~/.kube/config. Document sudo requirements for lab admins.

4. Sanity check

   kubectl get nodes shows Ready. kubectl run debug --image=busybox --rm -it -- echo ok proves scheduling works.

Week 1 — Pods and Deployments

Day 1–2: Pod anatomy. Students apply a single Pod manifest with labels, resource requests, and a failing command to observe CrashLoopBackOff. Teach kubectl describe pod, logs, and events—skills they reuse in every internship ticket.

Day 3–4: Deployment as the unit of change. Two replicas, rolling update with a new image tag, and kubectl rollout undo. Contrast bare Pod (ephemeral) with Deployment (desired state). Whiteboard the ReplicaSet controller once; avoid controller deep dives until advanced track.

1. Lab 1A: Run nginx Pod; port-forward and curl localhost
2. Lab 1B: Convert to Deployment with two replicas; delete a Pod and watch replacement
3. Lab 1C: Broken liveness probe exercise—fix YAML from describe output
4. Lab 1D: Quiz—when to use Job/CronJob (mention only, no full lab)

Week 2 — Services and Ingress

Day 5–6: ClusterIP Service selects Pods by label. Students scale Deployment, confirm Endpoints update, and trace traffic with kubectl get svc,endpoints. Introduce NodePort for lab access when LoadBalancer is unavailable—typical on kind and campus networks.

Day 7–8: Ingress exposes HTTP routes. Install ingress-nginx on kind with the documented extra port mapping, or use k3s bundled Traefik. Apply Ingress rules for two path prefixes on one host. Discuss TLS as reading homework—cert-manager appears in the GitOps lab follow-on.

Capstone mini-project: deploy a two-tier app (API + static front) with one Deployment each, ClusterIP for API, Ingress for external URL. Students document architecture in a one-page diagram—mirrors how DarDev client handoffs start.

Homework rubric — Tunis students

Assign after Week 2. Total 100 points. Another student must reproduce your cluster from README alone—reproducibility is the core learning outcome, not memorized kubectl flags.

• Cluster bootstrap documented (15 pts): kind or k3s steps, KUBECONFIG, version pins
• Manifest quality (25 pts): Deployments with requests/limits, probes, meaningful labels
• Networking (25 pts): working Service + Ingress; curl from host succeeds with screenshot
• Failure narrative (20 pts): inject one misconfiguration, capture events, document fix
• README and git hygiene (15 pts): no secrets committed,.env.example, French or English prose OK

Bonus +5: multi-stage Dockerfile under 150 MB pushed to GHCR. Penalty −10: hard-coded NodePort left in final submission when Ingress is required. Oral defense (5 min, French or English): explain what happens to Pod IP when a node drains—separates copy-paste from understanding.

Grading timeline: mentors allow 48 hours for resubmit on infrastructure flakes (pull timeout, full disk)—common on shared faculty VMs. Link rubric rows to internship skills: STB and Telnet offshore centers routinely ask candidates to sketch Service types in technical screens.

Module sequencing in DarDevLab

Prerequisite: container-basics-tn-students week (images, Compose, first Dockerfile). Next step: gitops-lab-first-deploy where Flux reconciles the same manifests from git—students already trust Deployments before adding controllers.

Faculty needing a semester arc should map this module to Weeks 5–6 of the cloud-native learning 90-day plan, then assign GitLab CI pipeline reading before the GitOps lab. DarDevLab cohorts enroll at dardevlab.com; certification track details live in dardevlab-certification-tracks.

Mentor checklist before Day 1

1. Test kind create cluster on the worst lab PC in the room
2. Pre-pull nginx, busybox, and ingress-nginx images
3. Prepare broken YAML packet for describe/log exercises
4. Share Slack or forum rule: paste kubectl describe snippets, not screenshots only
5. Schedule office hours after Week 1—Deployment confusion peaks on rollout undo

DarDev offers guest workshops for Tunis programs—contact via news.dardev.net when you need a mentor for the capstone grading week.