Operations | Monitoring | ITSM | DevOps | Cloud

A Kubernetes Operator is a method of packaging, deploying, and managing a Kubernetes application. It extends the native Kubernetes API by combining custom resources (CRDs) with a dedicated controller: a custom control loop that continuously watches the state of those resources. The primary purpose of an operator is to automate complex, stateful applications (like databases, message queues, or monitoring suites) that require human operational knowledge to maintain.

Today, we’re launching Kubex support for the KAI Scheduler and automated GPU sharing for inference workloads. As AI inference moves into production, platform teams are being asked to serve more models, support more teams, and control GPU costs at the same time. But many inference workloads do not need an entire GPU all the time. When teams reserve full GPUs or oversized GPU fractions to stay safe, expensive capacity can sit idle across the cluster.

During the Toronto KCD (Kubernetes Community Days), I attended an insightful talk on AI resource optimization that highlighted a staggering Gartner study: “AI infrastructure is adding $401 billion in new spending this year alone. Yet, real-world audits tell a much darker story, revealing that average GPU utilization in the enterprise is stuck at a dismal 5%”. While many people in the audience were shocked by that number, the data didn’t come as a surprise to us.

Enterprise AI has crossed an inflection point. The model problem is largely covered. What remains unsolved is the operational impact: how to run AI inference and agentic processes continuously, reliably, and at a cost that doesn’t cancel out the value. Most enterprises are discovering this the hard way. GPU utilization dashboards show 80%. Actual compute efficiency is half that. Token demand is compounding at 200-500% annually as agents multiply every action into dozens of model calls.

Many of us understand the concept of Kubernetes Requests and Limits, and that by reducing over-sized resource requests we can reduce waste in our clusters. And for GKE Autopilot and EKS Fargate clusters that is true. Because you’re being billed directly for the resources you’re requesting, driving down requests can result in instantaneous savings. However in most hosted Kubernetes environments you’re not actually being billed for requests.

Industry analyst recognition means something different from an award. GigaOm does not hand out trophies. They evaluate products against a defined capability framework and tell the market where vendors actually stand. By that measure, Kubex has been named a Leader in two of GigaOm’s 2026 Radar Reports: Kubernetes Resource Management and Cloud Resource Optimization. In the Kubernetes report, we are positioned as an Outperformer. In Cloud Resource Optimization, a Fast Mover.

The early era for AI was defined by experimentation, standing up isolated environments, and finding the first practical use cases. Today, the conversation is different. Enterprises are no longer asking whether AI matters. They are asking how to scale it sustainably, securely, and economically. That shift is giving rise to the AI factory: a repeatable, governed, production-ready environment where data scientists, platform teams, and application teams can build, train, deploy, and operate AI at scale.

TL;DR: Most Kubernetes clusters waste GPU compute through over-provisioned pod requests and suboptimal node selection. This guide covers 10 tools that fix this across four layers: resource lifecycle (Kubex, ScaleOps, Cast.ai), hardware partitioning (GPU Operator, MIG, time-slicing), inference serving (Triton, KServe), and observability (DCGM Exporter, NFD). For most teams, the biggest gains are at the resource lifecycle layer: no model changes required.

In the modern cloud infrastructure landscape, we don’t have a data problem; we have an actionable interpretation gap. Engineering teams are often drowning in metrics that describe a crisis without providing a clear path to remediation. Traditional FinOps, SRE, and DevOps work has become a reactive loop of dashboard-watching and manual firefighting.

By 2026, the GPU shortage isn’t a supply-chain hiccup anymore. It’s baked into the system. Even after pouring billions into CapEx, most enterprises still want 40% more GPU capacity than they actually have. And it’s not because they’re chasing moonshots. Technology companies are training foundation models while serving inference for millions of users on the same clusters. AI labs are juggling fine-tuning, evaluation, and real-time experimentation side by side.