Standing room only
I looked up from the podium and the room was full. Not “a few empty seats in the back” full — 780 attendees had saved my session in the KubeCon agenda, engineers packed in, people standing along the walls, and more trying to get in through the doors.
This was my talk at KubeCon + CloudNativeCon Europe 2026 in Amsterdam: Multi-Tenant GPUs on Bare Metal OpenShift AI — A GitOps Blueprint from the Trenches.
After months of preparation, after the nerves of the morning, after checking the slides one last time — seeing that room filled with people who cared about the same problems I have been solving every day was the most incredible feeling of my career.
What I presented
The talk was not theoretical. It was a battle-tested blueprint from real production infrastructure:
The environment: bare metal, no safety net
We run a Dell AI Factory bare-metal cluster — PowerEdge R660 control plane, R670 CPU nodes, and XE7740 GPU workers loaded with NVIDIA H200 GPUs. PowerScale scale-out NAS with RDMA. Latest OpenShift plus OpenShift AI, NVIDIA GPU and Network Operators, and Run:AI for scheduling.
All of this in an air-gapped environment with a local Quay mirror. No public registries. No cloud abstractions. Every layer is ours to manage.
The real problems
“It runs” does not mean “it is safe to share.” From day one we had to solve:
- Noisy neighbors hoarding GPU memory, causing latency spikes for everyone else
- Queue explosions where jobs starve and scheduling becomes “random wins”
- MIG misfit — some workloads thrived with Multi-Instance GPU partitioning, others crawled
- Driver drift — proprietary kernel modules and firmware mismatches across nodes
- Network chaos — SR-IOV misconfigured, RDMA failures killing distributed training
The GitOps-driven solution
We needed guardrails, not manual intervention. The blueprint I shared covers:
- GPU partitioning strategies — when to use MIG, when to use time-slicing, when to dedicate full GPUs
- NVIDIA GPU Operator configuration — managing driver lifecycles across bare-metal nodes
- Network Operator and SR-IOV — NicClusterPolicy for RDMA-capable network isolation
- Run:AI scheduling — fair-share policies, quotas, and preemption that actually work
- GitOps everything — ArgoCD managing the entire GPU infrastructure stack declaratively
The energy in the room
What struck me most was the quality of the questions. These were not surface-level “what is Kubernetes” questions. People were asking about:
- Specific MIG partition layouts for different model sizes
- How we handle firmware updates without disrupting running training jobs
- SR-IOV virtual function allocation strategies for multi-tenant RDMA
- Whether our GitOps approach works with air-gapped OCI registries
These are the questions of people who are living these problems right now. GPU infrastructure on Kubernetes is not a future trend — it is today’s reality, and the room proved it.
Why this topic resonated
A year ago, GPU on Kubernetes was a niche topic. Today, every enterprise is trying to figure out how to share expensive GPU resources across teams without chaos. The demand for AI infrastructure on Kubernetes has exploded, and the tooling is finally catching up.
The fact that hundreds of engineers showed up for a talk about bare-metal GPU multi-tenancy tells you where the industry is heading. Cloud GPUs are expensive and scarce. Enterprises are building their own GPU clusters. And they need the patterns, operators, and GitOps blueprints to manage them.
Get the slides
I have published the full slide deck for anyone who could not attend or wants to revisit the content:
The deck covers the full architecture, configuration examples, lessons learned, and the GitOps blueprint we use in production.
Thank you
To everyone who showed up, who asked questions, who came up afterward to share their own GPU war stories — thank you. This is what makes KubeCon special. Not the expo hall, not the swag. The people who are building real infrastructure and sharing what they learn.
A special thanks to the KubeCon program committee for selecting this talk, and to the incredible Cloud Native community leaders who make events like this possible.
What is next
If you are building GPU infrastructure on Kubernetes and want to go deeper:
- 📥 Download the slides — full architecture and configuration details
- 📖 NVIDIA GPU Operator deep dive — getting started with GPU scheduling
- 🔧 SR-IOV NicClusterPolicy guide — network isolation for GPU workloads
- 🎓 Packt Workshop: Build and Scale AI on Kubernetes — hands-on training
- 📅 Book a consultation — let us talk about your GPU infrastructure
See you at the next one.
Read more about the KubeCon 2026 side events, the companies shaping Cloud Native, and my experience co-hosting Cloud Native Rejekts.
