My cluster is running… but does it actually work
summary
Automated checkups run as a Kubernetes Job that uses only kubectl and plain YAML to spin up two KubeVirt VMs, connect via serial console, run ping to measure latency, then delete the VMs and write results to the ConfigMap for retrieval. The proof‑of‑concept VM latency checkup reports measured RTTs and failure reasons; a DPDK checkup runs a traffic generator and reports zero packet loss when successful. Non‑admins can execute checks without CRDs.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:24Verifying cluster functionality
- 2:48KubeVirt and high-speed networking
- 4:38Automation for verification
- 5:41Checkup requirements
- 7:29VM latency checkup setup
- 11:45Live VM latency demo
- 13:40Existing and future checkups
- 15:27Writing custom checkups
- 16:13Conclusion
- 16:53Q&A
- 17:56Live DPDK checkup demo
- 20:07Closing Q&A
related talks
33mAm I Using It Right? Checking Best Practices on Live Kubernetes Clusters
28mHow We Tackle KubeVirt’s Growth and Scalability
35mkdevops sync up
43mMaking Running Virtual Machines in a Kubernetes Cluster a Mainstream Activity
37mVirtual Clusters in the Real World: Lessons from k3k’s Journey to Production
20mKubeVirt Benchmar...
23mDon't Let Users Find Your Outages: Synthetic Monitoring for Kubernetes Platforms
36mIt’s All for the Users. More Durable, Secure, and Pluggable. KubeVirt v0.53