Kubernetes: Classroom Bootcamp

An eight-hour classroom bootcamp on running applications at scale with Kubernetes, taught by installing Smarter’s Helm chart on a local cluster. Students start from the Docker Compose services they already know, and add only what Kubernetes brings: scheduling, scaling, ingress, secrets and network policies. Smarter’s Helm chart is the one that runs it in production: four Deployments from the same image as Docker Compose, liveness, readiness and startup probes, autoscalers that scale the web server from 3 to 25 pods, an init Job, a backup CronJob, Bitnami subcharts for the database, Redis and monitoring, and values validated by a JSON Schema. Smarter also manages Kubernetes itself, creating an ingress for each deployed LLMClient and a Deployment, Service and GPU node group for each self-hosted model. See Course Formats and Grading for the standard bootcamp day, the grading scale and the course policies, and Kubernetes for Running Applications at Scale for an overview of the subject.

At a Glance

Students

Developers, operations and platform engineers who know Docker and want to learn Kubernetes.

Deployment

Each student runs a local cluster (kind, minikube, or the one built into Docker Desktop) with the kubectl and helm command-line tools. A laptop with 16 GB of memory is recommended.

Cost

Free on local clusters. See Kubernetes for Running Applications at Scale for the cost of a managed cluster in the cloud, which this bootcamp does not need.

Warning

Students work only on their own local clusters. Never point the labs at a shared or production cluster, and check kubectl config current-context before every command that changes anything.

Learning Objectives

By the end of the bootcamp, students can:

  1. Explain the Kubernetes control plane, nodes, and the main objects: Pods, Deployments, Services, ConfigMaps, Secrets, Jobs and Ingresses.

  2. Install an application with a Helm chart, and read the chart’s templates and values.

  3. Map each Kubernetes object to the Docker Compose service it replaces.

  4. Scale an application horizontally, and observe the autoscaler.

  5. Write a network policy, and explain why the cloud metadata address must be blocked.

Technical Prerequisites

  • Required: Docker: images, containers, Compose, exec and logs. The Docker course covers this.

  • Required: the Linux command line, YAML, and Git.

  • Required: basic networking: IP addresses, ports, DNS and HTTP.

  • Required: a local cluster running, with kubectl get nodes and helm version working, before the bootcamp.

  • Helpful: the concepts of a load balancer and a reverse proxy, and some cloud experience.

Schedule

The files that the lectures refer to are listed in full under Smarter in the Source Code.

Block

Min

Content

1

45

Lecture 1: Why Kubernetes. What Compose cannot do: many machines, self-healing, rolling updates, scaling. The control plane and nodes, the declarative model, and ADR 003 on Kubernetes.

2

45

Lab 1: Objects by hand. Create a Deployment and a Service for a small web image with kubectl, scale it, delete a pod and watch it come back, and roll out a new version. Produces Assignment 1.

3

45

Lecture 2: Helm. Charts, templates, values and releases. A tour of helm/charts/smarter/: the app, worker, beat and infrastructure worker Deployments, the init Job, the Service, the autoscalers and the ConfigMaps, and the subcharts for the database, Redis and monitoring, with database.type to use an external database instead.

4

45

Lab 2: Install Smarter. Install the chart on the local cluster with a local values file, watch the init Job seed the database, and log in. Produces Assignment 2.

5

45

Lecture 3: Configuration and secrets. ConfigMaps, Secrets, environment variables and mounted files, and what a Kubernetes Secret does and does not protect.

6

45

Lecture 4: Scaling. Requests and limits, the Horizontal Pod Autoscaler, readiness and liveness probes, and how Smarter’s hpa-app and hpa-worker templates scale the web and worker pods.

7

45

Lab 3: Load test. Install the metrics server, load test the web service, and watch the autoscaler add pods. Record pods, CPU and response times. Produces Assignment 3.

8

45

Lecture 5: Networking. Services, Ingress, DNS inside the cluster, and network policies. Server-side request forgery and the cloud metadata address. How Smarter deploys an LLMClient with its own ingress.

9

45

Lab 4: Fence it in. Write a network policy that stops Smarter’s pods from reaching 169.254.169.254 while still reaching the database, Redis and the internet, and test it (on a cluster whose network plugin enforces policies). Ungraded.

10

45

Lecture 6: Operating a cluster. Logs, events, kubectl describe, upgrades, backups (the chart’s backup CronJob to S3), the bastion pod, managed clusters in the cloud with Spot node groups and the Cluster Autoscaler, and what they cost. Operating Smarter at Scale.

11

30

Capstone kickoff. Students choose a capstone and plan it.

Smarter in the Source Code

Every lecture, lab and assignment in this course rests on the files below. Every reference is to the main branch of github.com/smarter-sh/smarter, or of smarter-infrastructure where named, so that students can open each one during class.

The Helm Chart

Topic

What Smarter does

Where to look

The chart

helm/charts/smarter, published on Artifact Hub and signed with cosign, with Bitnami subcharts for MySQL, MariaDB, Redis, Grafana and Prometheus, and Loki, each switched on or off in the values.

Chart.yaml, README.md

Values, validated

Every setting has a default in values.yaml, and a JSON Schema rejects a values file with a wrong key or type before anything is installed. database.type chooses MySQL, MariaDB or an external database.

values.yaml, values.schema.json

Four Deployments, and a bastion

The web server, the worker, the infrastructure worker and the scheduler: the same image as in Docker Compose, with different commands. A fifth, a bastion pod, gives operators a shell inside the cluster.

deployment-app.yaml, deployment-worker.yaml, deployment-worker-infrastructure.yaml, deployment-beat.yaml, deployment-bastion.yaml

Probes

Liveness on /healthz/, readiness on /readiness/, and a startup probe, so a slow start is not mistaken for a failure.

deployment-app.yaml, urls/console.py

Autoscaling

Horizontal Pod Autoscalers for the web server and the worker, from 3 to 25 web pods at 75% CPU by default.

hpa-app.yaml, hpa-worker.yaml

Jobs

A post-install and post-upgrade Job that creates the database and its user, migrates and initializes the platform, and a CronJob that backs the database up to S3 on a schedule.

job-init.yaml, job-mysql-backup.yaml

Configuration

ConfigMaps for the database, the sample database, the backup script, the bastion’s setup and its welcome banner, a Secret for the image registry, and environment variables for everything else.

templates/

Releasing the chart

A workflow packages, signs and publishes the chart.

helmChartRelease.yml

The Cluster in Production

Topic

What Smarter does

Where to look

EKS and its nodes

Managed node groups on Spot capacity that scale from 0 to 15 nodes, and the Cluster Autoscaler, which adds nodes when pods cannot be scheduled.

smarter-infrastructure: aws/terraform/kubernetes/main.tf

Network policies

Calico, default-deny ingress for the database, Redis and the application, and egress limited to the database ports.

smarter-infrastructure: network_policy.tf

Ingress and certificates

Traefik and cert-manager, installed as Helm releases.

smarter-infrastructure: aws/terraform/kubernetes_ingress/

An Application That Manages Kubernetes

Python paths are under smarter/smarter/.

Topic

What Smarter does

Where to look

The Kubernetes service

One interface for applying and deleting manifests, implemented with kubectl and the cloud’s kubeconfig, and replaced by a fake in tests.

infrastructure/services/kubernetes.py

An ingress per LLMClient

Deploying an LLMClient renders an Ingress from a template, with its own host name and certificate, in a Celery task. LLMClient Deployment.

llmclient/k8s/ingress.yaml.tpl, llmclient/tasks/deploy_default_api.py

Workloads for self-hosted models

An LLMHost becomes a PersistentVolumeClaim for the model, a Secret, a Deployment of the inference server, a Service and an optional Ingress, rendered by a pure function so that the plan can be previewed and tested. Smarter LLM Host.

llmhost/services/renderer.py

Nodes on demand

EKS managed node groups of GPU or CPU nodes, created at zero nodes, scaled up for a model, and scaled down by terminating a chosen idle node.

llmhost/services/nodegroups.py

Self-hosted vector databases

A Qdrant Vectorstore can run on the platform’s own cluster, created, watched and destroyed by Smarter.

vectorstore/kubernetes.py

Graded Assignments

Assignment 1: Self-Healing and Rollouts

Students show a Deployment healing itself after a pod is deleted, scaling, rolling out a new image and rolling back, with the commands and output.

Turn in: the manifests and a terminal log with commentary.

Criterion

Pts

Exemplary

Developing

Manifests

5

Valid, with labels, selectors and resource requests.

Created imperatively, or missing labels.

Self-healing and scaling

5

Both demonstrated.

One only.

Rollout and rollback

6

Both demonstrated, with kubectl rollout history.

Rollout only.

Commentary

4

Explains what the controller did at each step.

Raw output.

Assignment 2: Compose to Kubernetes Map

Students map each service in docker-compose.yml to the Kubernetes objects in the Helm chart that replace it, and list what Kubernetes adds or handles differently.

Turn in: a table and a one-page explanation, with evidence that the chart is installed.

Criterion

Pts

Exemplary

Developing

Installation

4

Chart installed; all pods running.

Some pods failing.

Mapping

8

Every service mapped correctly, including the database and Redis.

Errors or gaps.

Differences

6

Explains scaling, Jobs, Secrets and Services versus Compose.

Lists objects without comparison.

Clarity

2

Clear.

Unclear.

Assignment 3: Autoscaling Report

Students load test the web service and report how the autoscaler responded.

Turn in: a chart of load, pod count and response time over time, and a one-page analysis.

Criterion

Pts

Exemplary

Developing

Test design

5

Load increased in steps, held, then removed.

A single burst.

Data

6

Pods, CPU and response times over time.

One metric.

Analysis

6

Explains the lag and the scale-down behavior.

Describes without explaining.

Recommendation

3

Proposes better requests, limits or thresholds.

None.

Capstone Projects

Students choose one. Capstones are due one week after the bootcamp.

Capstone A: A Hardened Smarter Installation

Learning objective. Take a working Helm installation and make it production-ready in security and resilience, with evidence.

Students harden their local installation with a values file and extra manifests: resource requests and limits on every pod, probes, Pod Disruption Budgets, network policies (including the metadata address), and a non-root security context, and demonstrate that each works.

What students turn in:

  • A Git repository with the values file, extra manifests and a README.md.

  • Evidence for each control: a blocked connection, a pod restarted by a failed probe, a drain that respects the disruption budget.

  • A one-page explanation of each choice.

How it is graded (100 points):

Criterion

Pts

Exemplary

Developing

Resources and probes

20

Realistic requests, limits and probes on every pod.

Some pods only.

Network policies

25

Default deny, with the needed paths allowed; metadata address blocked.

A single policy, or one that breaks the app.

Resilience

20

Disruption budgets and replicas demonstrated.

Not demonstrated.

Evidence

20

Each control shown working.

Claims without evidence.

Documentation

15

Reproducible from the README.md.

Missing steps.

Capstone B: Your Own Application on Kubernetes

Learning objective. Package a multi-process application as a Helm chart, following the patterns of a real one.

Students write a Helm chart for an application of their own (or their Docker capstone) with a web Deployment, a worker Deployment, a Service, an Ingress, a ConfigMap, a Secret, an init or migration Job, and an autoscaler, modeled on Smarter’s chart.

What students turn in:

  • A Git repository with the chart and a README.md.

  • Proof that helm install and helm upgrade work on a local cluster, and that helm lint passes.

  • A one-page comparison with Smarter’s chart.

How it is graded (100 points):

Criterion

Pts

Exemplary

Developing

Works

25

Installs and upgrades cleanly.

Needs manual fixes.

Chart design

20

Sensible values, helpers, labels.

Hard-coded values.

Objects

20

All required objects, correctly configured.

Some missing.

Production readiness

15

Probes, resources, autoscaler.

None.

Documentation

20

Clear README.md and comparison.

Missing.

Further Study