From Compose to Kubernetes

RES509 - Virtualisation avancée

Goals for today

By the end of this four-hour session, you should be able to:

• Explain why Kubernetes exists
• Deploy our app to a local cluster
• Scale it
• Break it (on purpose) and recover
• Debug using the right signals: status, events, logs

Docker Compose is great

Compose manages services on one Docker host:

• Define services together in YAML
• Restart containers using restart policies
• Scale compatible services with up --scale
• Keep a simple local development environment

Compose limits

Compose does not give you:

• Scheduling across machines
• Rescheduling workloads onto another host
• A consistent model for rolling updates
• A control plane that watches and reconciles state

Pets vs Cattle

Kubernetes treats Pods like cattle. Persistent data needs storage that survives Pod replacement.

The control loop idea

Controller loop:

• “Start 1 more”

This loop never stops.

Core objects we will use

Keep it simple:

• Pod: the smallest unit that runs
• Deployment: manages replicas and updates
• Service: stable networking to reach the app

We will ignore the rest for now.

Pod: the unit of execution

A Pod is:

• One or more containers that run together
• Shared networking inside the Pod
• Usually short-lived, replaceable

Key idea:

• You do not manage Pods manually in production

Deployment: desired state for Pods

A Deployment lets you say:

• Which image to run
• How many replicas you want
• How updates should roll out

It creates and replaces Pods for you.

Controller hierarchy

If a Pod disappears, the ReplicaSet creates a new one.

Service: stable access

Pods come and go. IPs change. A Service gives you:

• A stable name
• A stable virtual IP
• Routing to eligible, Ready Pods

Today we will use a simple local Service.

Everything is “configuration as code”

Kubernetes is declarative.

You apply YAML, for example:

• deployment.yaml
• service.yaml

You can version it in git, review it, and automate it in CI.

Your debugging toolkit

You will mostly use:

• kubectl get ...
• kubectl describe ...
• kubectl logs ...
• kubectl apply -f ...
• kubectl delete ...
• kubectl rollout status ...

Use status → events → logs to explain a failure.

How to observe what is happening

When something is wrong, check in this order:

• Status: kubectl get
• Details and events: kubectl describe
• Application output: kubectl logs

This is your debugging loop, just as docker compose ps and logs were in RES507.

Lab setup

Use your existing course Ubuntu VM.

• Keep your own fork and completed application
• Run k3s with its default containerd runtime
• Build with Docker, then import the image into k3s
• Run the lab commands inside the VM
• Follow Lab 42’s setup checks before continuing

Docker and k3s have separate image stores.

Lab tasks

In the lab, you will:

• Apply the Deployment YAML
• Apply the Service YAML
• Confirm /health responds
• Set three replicas in the saved manifest
• Delete a Pod and watch its replacement become Ready

Today’s check-ins

• A working deployment with Ready Pods
• The Service configuration and a successful health request
• Three replicas and an observed Pod replacement
• A deliberate failure, its cause, and verified recovery

Save failure evidence before fixing it. Keep short excerpts and a symptom/cause/fix note.

Check-ins provide feedback; the final Lab 42 assessment is later.

Quick check-in

Before the lab:

• Have you used Kubernetes before?
• If yes: what did you use it for?
• If no: what do you expect it to do?

We will keep it practical.

Let’s start the lab

• Open the course website
• Open 42 — Kubernetes Deployment and Runtime Validation
• Work in your own GitHub fork
• Ask questions early

When the core work is verified:

• Start an extension lane
• Keep your evidence ready for a check-in
• Help a neighbor when useful