Show Notes
Running GPU workloads on Kubernetes sounds straightforward until you need to isolate multiple tenants on the same server. The moment you virtualize GPUs for security, you lose access to NVIDIA kernel drivers — and almost every tool in the ecosystem assumes those drivers exist. Landon Clipp built a GPU-based Containers as a Service platform from scratch, solving each isolation layer — from kernel separation with Kata Containers + QEMU to NVLink fabric partitioning to network policies with Cilium/eBPF — and shares exactly what broke along the way. In this interview: Why standard NVIDIA tooling (GPU Operator) fails in multi-tenant setups, and how to use CDI with PCI topology scanning to make GPUs visible to Kubernetes without kernel drivers
How to partition the NVLink fabric between tenants using a trusted service VM running Fabric Manager, and why the physical PCIe wiring differs between Supermicro HGX and NVIDIA DGX systems
Why gVisor doesn't work for GPU workloads — NVIDIA's unstable ioctl ABI means Google has to update gVisor for every driver release, and they only support a handful of GPUs
What caused 8-GPU VMs to take 30+ minutes to boot, and the specific fixes (IOMMUFD, cold plugging, kernel upgrades) that brought it down to minutes
How Cilium network policies enforce tenant isolation at the Kubernetes identity level instead of fragile IP-based rules
Where Containers as a Service fits best: inference workloads where AI teams want to ship an OCI image without managing infrastructure or signing multi-million dollar cluster contracts. Sponsor This episode is sponsored by LearnKube — get started on your Kubernetes journey through comprehensive online, in-person or remote training. More info Find all the links and info for this episode here: https://ku.bz/jjK_yJTDz
Interested in sponsoring an episode? Learn more.
More from KubeFM
Non-deterministic agents pose specific challenges for platform teams in observability, state management, governance, and trust. Mauricio (Salaboy) Salatino explains why agentic applications behave like distributed multi-agent systems. His test assigned agents to take an order, cook the pizza, deliver it, and charge the customer. One order crossed 15 containers and produced 200 traces. In this interview: Why agent frameworks can recreate monolith scaling and resource contention
KubeSelect is a new show that tests one bold Kubernetes hypothesis with one expert. Hosts Salman Iqbal and Bart Farrell examine the evidence and ask whether the claim holds up. In episode two, Kat Cosgrove tackles a long-running question: should teams run databases on Kubernetes? StatefulSets, persistent volumes, CSI, and database operators changed the technical answer, but they did not remove the operational risk. In this episode: How Kubernetes storage has matured and why old assumptions persist
Kube Select takes one bold Kubernetes hypothesis and tests it with an expert. In the first episode, Salman Iqbal and Bart Farrell ask whether most organizations have an observability problem or a decision-making problem. Henrik Rexed, Senior Staff Engineer at Dynatrace, challenges the original claim. Teams can collect metrics, logs, and traces, but that telemetry needs system relationships, ownership, and deployment history to support a confident decision. In this episode: Why telemetry without context slows incident response
Kube Signals starts where the keynote ends: with the trends that platform teams will have to operationalize next. In this special episode, Brian Teller speaks with Saiyam Pathak about his KubeCon India keynote and the shift from developer platforms to AI factories. They examine what GPU scarcity, shared accelerators, and AI workloads mean after the conference slides meet real infrastructure. In this interview: Why GPU infrastructure is becoming a platform-engineering concern
At enterprise scale, a deployment pipeline that runs Helm upgrades directly against Kubernetes hides drift, mixes configuration with CI logic, and makes the last pipeline run the source of truth. Elad Cohen explains how WSC Sports moved from Azure DevOps to GitHub Actions and redesigned delivery around Git and Argo CD. The resulting platform separates builds from deployments, keeps service configuration in values files, and continuously reconciles clusters. In this interview: Why CI should change Git instead of the cluster