Lightning Talk: Managing Drivers in a Kubernetes Cluster
summary
Problem: drivers must match kernel and break ops workflows. Proposal: run a container per node that loads compiled kernel modules, uses DKMS when available, and sleeps so Kubernetes handles lifecycle and upgrades via normal rollout semantics. Compares to brittle SSH/Ansible installs and inflexible base-image AMIs. Notes complexities: need privileged containers, device-plugin and runtime hooks, and points to the NVIDIA device driver container example and VM runtime implications.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:12Drivers ? For What?
- 1:07Drivers? What are they?
- 1:36Drivers? How?
- 1:55Drivers in Kube, Using SSH
- 2:29Drivers in Kube, Base Image
- 3:16Drivers in Kube, Containers
- 3:26Drivers Containers?
- 4:13Call to Action
related talks
30mRunning AI Workloads in Containers and Kubernetes
26mAutomating GPU Infrastructure for Kubernetes
05mLightning Talk: Sharing a GPU Among Multiple Containers
09mLightning Talk: Optimize the Ray Schedule and Autoscaling on Kubernetes Cloud: A Hetero...
06mLightning Talk: Zombie Kubernetes!: Making Nodes Rise From The Dead
06mKubernetes Love Machine Learning, Even on Private Cloud
10mLightning Talk: K8s Issue #52757: Sharing GPUs Among Multiple Containers
07mLightning Talk - Say what? You're Running the Storage Platform IN Kubernetes?