Ensuring High Availability for KubeVirt Virtual Machines
summary
Changes a KubeVirt controller so running VMs that lack launcher pods get their status flipped to Failed, forcing immediate recreation; uses Kubernetes + KubeVirt plus Node Health Check with the SNR remediator to trigger node fencing, and runs 31 experiments with an unhealthy-duration of 1s as baseline. Finds the launcher pod response consumes ~51% of recovery time, implements a controller watcher change that cuts launcher respond and total VM recovery, yielding 55% faster recovery in measured runs.
AI-written summary · about
chapters (9)
- 0:00Introduction to KubeVirt high availability
- 1:05Node Health Check & remediators
- 3:15Deploy Node Health Check
- 4:43Measuring VM recovery time
- 7:16Baseline VM recovery scenario
- 8:21Launcher pod bottleneck
- 9:46Fixing launcher pod time
- 10:28Results after fix
- 11:13Conclusions
related talks
38mKubeVirt Intro: Virtual Machine Management on Kubernetes
31mKubeVirt: What If Kubernetes Orchestrated Your VMs?
18mKubeVirt Alchemy: Transform VMs into K8s Workloads
43mMaking Running Virtual Machines in a Kubernetes Cluster a Mainstream Activity
43mKubeVirt - Kubernetes, Virtualization and Your Future Data Center
31mVMs + Containers = The Perfect Wedding
42mVirtual Machine Orchestration in Kubernetes Utilizing KubeVirt
23mRunning VM workload on Kubernetes using KubeVirt