How I Update My Kubernetes Homelab From The Mountains

Summary of Technological Concepts, Features, and Analysis

Scenario & Goal

• The speaker (“Misha”) is upgrading a Kubernetes home lab while traveling in the Norwegian mountains.
• He uses a remote management setup so he doesn’t need to directly access the lab network (e.g., via SSH).

Architecture

• The home lab uses a multicluster architecture.
• One cluster, “Yotenheim,” contains all applications and is the upgrade target.
• Yotenheim consists of 4 nodes:
  • Three control planes (to maintain quorum)
  • One worker

Upgrade Management Tool: Cedaro Omni

• Misha uses Cedaro Omni as a web/UI-based control plane for managing updates remotely.
• Omni provides an API endpoint, which Misha accesses indirectly via a generated kubeconfig URL—so he avoids SSH’ing into the lab network.
• Omni can generate boot images that include join tokens.
  • This enables nodes to join clusters by communicating with Omni’s API.

Talos Linux Upgrades (Immutable OS Behavior)

• The cluster runs Talos Linux.
• Current Talos version before the upgrade: 1.12.6.
• Upgrade strategy: update Talos OS patch/minor versions first, before Kubernetes.

Example upgrade flow

• 1.12.6 → 1.12.10 (patch)
• 1.12.10 → 1.13.7 (minor)

How the upgrade works (node-by-node, with safe rollback)

For each node, Omni performs a controlled sequence:

1. Drain/evict workloads (pods move elsewhere)
2. Reboot into a new Talos image
3. Rejoin and restart control-plane components as needed (e.g., etcd)

If something fails, Omni can roll back to the old image automatically.

Design comparison

• Misha highlights Talos’ immutable image-based OS approach.
• He compares it to similar “image/switchable” operating models on his laptop (e.g., Fedora Atomic variants).

Kubernetes Upgrade Phase

• After Talos is updated, Misha upgrades Kubernetes.
• Example shown:
  • Kubernetes upgrades to 1.15.7 (auto-detected “latest available” in the UI).
• Kubernetes upgrade depends on Talos version compatibility:
  • If you’re upgrading beyond the current Kubernetes target, Talos may need to be upgraded again (Talos appears as a step again).

Drain nuance

• Talos upgrades include draining because they involve a reboot.
• In Misha’s described process, Kubernetes upgrades usually don’t require a drain.

Observability During the Upgrade

Misha monitors upgrade progress using:

• kubectl get nodes (readiness + scheduling state)
• k9s (pod rescheduling and status visibility)

Observed behavior:

• Nodes become SchedulingDisabled / cordoned
• Pods are rescheduled onto remaining nodes
• After reboot and component readiness (including static pods), the node returns to Ready and becomes schedulable again

What’s Actually Being Updated

• The emphasis is that Omni/Talos updating primarily updates the OS layer first.
• Claimed benefit:
  • Reduces operational overhead versus managing Kubernetes directly on raw Linux hosts (e.g., K3s / kubeadm workflows).
  • Centralizes OS update and rollback using Talos releases.

Guidance / Recommendations (Review-Style Stance)

Misha explicitly does not recommend Talos for beginners.

• He gives a “hard no” for early learners, arguing:
  • Talos may hinder career growth/learning
  • Automation can cause atrophy of skills (less hands-on practice upgrading/managing systems)
• For more experienced users, Talos + Omni becomes more attractive due to:
  • Stability
  • Easy remote upgrades (particularly helpful while traveling)

Offerings / Resources

• A free Kubernetes home lab guide is offered via a link in the description (form submission).
• A private mentoring/job-focused program called “CubeCraft”, using Kubernetes home labs as evidence for DevOps job preparation.

Main Speakers / Sources

• Main speaker: Misha (video host)
• Technology sources/tools mentioned:
  • Cedaro Omni
  • Talos Linux
  • Kubernetes
  • k9s
  • kubectl
• Related referenced entity: Justin Garrison (mentioned as a friend)