Today’s route

• Finish the Lab 42 core and verify it together
• Begin PostgreSQL when your core is verified
• Explain containers, VMs, and the kernel boundary
• Draw the system you actually have

Your extension and final Lab 42 assessment can come later.

First: reopen your work

Use the Lab 42 restart checklist.

• Reopen your VM, fork, work branch, and manifests
• Find the first checkpoint you cannot demonstrate
• Show the expected result and actual symptom
• Resume from there with the troubleshooting sheet

Keep the existing cluster and your working files.

Our four hours

• 15 min: locate your checkpoint
• 15 min: focused troubleshooting demonstration
• 65 min: finish core work, or begin PostgreSQL
• 15 min: break and buffer
• 20 min: architecture discussion
• 75 min: database work or supported recovery
• 35 min: diagram, evidence, and next action

The core handoff

Show and explain:

• Deployment, Service, and both health access paths
• Three Ready replicas; a deleted Pod replaced
• Readiness HTTP 404 event, then verified recovery
• Saved manifests and concise evidence

Check in, then begin Lab 52. No extension is needed to enter.

Use the next diagnostic signal

• Cluster unreachable: service status and kubeconfig
• Image pull error: Pod events and k3s image store
• Pod unready or restarting: events, then app logs
• Service fails: labels, selector, ready endpoints
• Laptop fails: test from the VM first

After 10 minutes without a new finding, request a check-in.

First work block

• Core unfinished: resume your missing Lab 42 checkpoint
• Core verified: begin Lab 52’s guided PostgreSQL setup
• Database already verified: reuse it and draw your system

Save failure events before recovery. We regroup for the architecture discussion after the break.

Where does your app run?

• Your app process runs in a container, inside a Pod
• k3s runs that workload on a node
• Our node is your Ubuntu VM
• The VM has a guest kernel and virtual hardware
• A hypervisor runs the VM on host hardware

Point to those boundaries in your own setup.

Containers and VMs

• Containers on our node share the Ubuntu guest kernel
• Containers isolate processes, filesystems, and networking
• A VM runs its own guest kernel
• The hypervisor provides virtual CPU, memory, and devices

Kubernetes manages workloads; the VM boundary remains.

Choose an isolation boundary

• Shared kernel: a kernel failure can affect many containers
• Separate VMs: separate guest kernels, with extra overhead
• Isolation also depends on configuration and privileges

Discuss: why might cloud tenants need separate guest kernels?

Which failure did you test?

• Deleted app Pod: its ReplicaSet creates a replacement
• Bad readiness path: new Pod stays unready
• Old healthy Pods may still serve during that stalled rollout
• Lost VM: all three local app replicas are unavailable

Three replicas on one VM do not provide node resilience.

The next practical milestone

Follow Lab 52’s guided setup:

• PostgreSQL, its Service, and persistent storage
• Secret references for the app’s database connection
• Insert and retrieve a distinct quote through the app
• Replace the database Pod, keeping its PVC
• Retrieve that same quote again

A successful /health request does not test these operations.

What did persistence prove?

• The quote survives database Pod replacement
• The PVC uses storage on this VM
• Database replacement can interrupt service
• VM or disk loss needs a separate recovery design

Persistence across Pod replacement is a specific result. It does not demonstrate backups or high availability.

Draw what you actually have

Include access paths and boundaries:

• Access: browser, port-forward, and in-cluster client
• App: Service, Pods, and containers
• Database: Service, Pod, and PVC if implemented
• Platform: Ubuntu VM/kernel, hypervisor, hardware

Mark planned components. Distinguish traffic from containment.

Before leaving

• Save the last verified checkpoint and selected evidence
• Link your diagram; add brief kernel and storage notes
• Commit working files and push your own fork
• Agree one next action with the instructor

If still blocked, record the symptom and next diagnostic check. A class demonstration does not complete your individual work.

Continue from your checkpoint

Open 52 — From Kubernetes Recovery to Persistent Data.

• Finish core recovery first if needed
• Verify database work, then the diagram
• Afterward, choose one continuation if time permits

Later: controlled changes and production architecture. We will confirm the remaining scope after today’s check-ins.