For years, Chris Wolford wanted to build his own Kubernetes distribution, one that would stay dependable long after installation. “I wanted the cluster you learn on to behave exactly like the tenth one you run,” he says. His home lab became the place where he started turning that idea into working software.
That idea now underpins CIQ Stratum Pro, the commercial Kubernetes offering from CIQ, built on the open source CIQ Stratum Kubernetes Engine (SKE). SKE provides the foundation for installing and operating a cluster. Stratum Pro adds fleet management, single sign-on, and support from CIQ.
For Chris, bringing that prototype from his home lab to products that help teams operate Kubernetes is a milestone built on years of experience operating infrastructure and a clear conviction about what makes it dependable.
As Director of Engineering at CIQ, Chris leads the team that builds SKE, Stratum Pro, and Fuzzball, the CIQ workflow orchestration platform for AI and HPC. Across these products, his team works on a challenge familiar to anyone trying to put increasingly powerful computing resources to use: reducing the complexity users have to manage without taking away the control they need.
His work on SKE and Stratum Pro brings that goal to Kubernetes, from the reliability of an individual cluster to the demands of managing a fleet.
From operating infrastructure to building it
Before joining CIQ, Chris spent nearly 12 years at NASCAR, where his work included cloud modernization and Kubernetes adoption. There, reliability had an especially concrete meaning.
“In broadcast and on race day, the green flag drops at a set time whether your systems are ready or not,” he says. “There’s no ‘we’ll push it to next week.’”
That experience taught him to value repeatability, knowing exactly what was running, and having a recovery path when something went wrong. Those priorities followed him into his work on HPC and AI infrastructure.
CIQ offered the opportunity to build on that experience with a talented team developing technology in the open. Its stack spans Rocky Linux and three variants of RLC Pro, Warewulf provisioning, Apptainer containers, and Fuzzball workflows. For someone who had spent years stitching vendors together and owning the gaps between them, that breadth was compelling.
“The chance to build the whole thing as one stack, where the layers are actually designed to work together, was too good to pass up,” he says.
SKE gave Chris an opportunity to apply those lessons to a problem he knew firsthand: keeping Kubernetes dependable long after installation.
Engineering for the days after installation
“When you run Kubernetes in production with an immovable deadline, you learn quickly that the install is the easy day,” he says. “The hard part starts after, when the projects underneath you drift apart and every upgrade becomes a small research project.”
A Kubernetes cluster is built from about 10 upstream projects, each with its own releases and requirements. Teams assembling those pieces inherit the work of determining whether their particular combination will continue to behave as expected.
SKE brings the cluster lifecycle into one signed binary, with every component built from unmodified upstream source, pinned together, and tested as a set.
Chris explains, “The things I cared about most are the things Stratum does by default: every component pinned and tested as a set, upgrades that check health at each step and stop before they make things worse, snapshots on a schedule, and certificates that renew before they expire.”
“Consistency is a reliability feature,” he states. “If every cluster is a stamp of the same thing, then what you learned last time is still true this time.”
Chris also points to the responsibilities of maintaining a cluster for years: renewing certificates, rotating the certificate authority, and making sure the software can uninstall cleanly. These are the details he wants operators to be able to trust.
Bringing a growing fleet into view
Managing a fleet adds another layer of operational responsibility. Chris describes a pattern he has seen as organizations adopt Kubernetes.
“Kubernetes usually arrives one team at a time,” he says. “One team stands up a cluster, then another, and pretty soon you have a platform nobody planned.”
Each cluster can develop its own upgrade schedule, access arrangements, and dependence on the person who built it. Understanding the whole environment becomes a challenge of its own.
That is the problem CIQ Stratum Pro addresses. Built on SKE, it brings GPU clusters and the general fleet into one web interface, with visibility into health, versions, and workloads. Single sign-on connects access to the organization’s existing identity provider.
Stratum Pro also adds an app catalog, optional CIS hardening with per-control checks, and support from CIQ. Teams can examine hardening results and get help from the company building the software they operate.
For Chris, this extends the same principle that shaped the engine: what a team learns operating one cluster should remain useful as its responsibilities grow. SKE supplies the consistent cluster foundation; Stratum Pro helps teams manage that foundation across a fleet.
Giving AI agents room to earn trust
SKE, the engine underlying Stratum Pro, includes a built-in Model Context Protocol (MCP) server that lets AI agents interact with a cluster. For Chris and his team, building that capability meant deciding how much authority an agent should have, and how operators would control it.
The team chose tiers. By default, the server provides read-only access, allowing an agent to inspect cluster status, list nodes, read logs, and plan an upgrade. Write tools aren’t registered until an operator explicitly enables them. Destructive operations require a separate switch.
“The agent can’t talk its way past a tool that doesn’t exist,” Chris explains. The guiding question came from a familiar relationship: “What would I be comfortable handing a new teammate on day one?”
An agent can begin by helping an operator understand an environment, then take on more responsibility as the operator chooses. The design makes human control part of how the capability works.
Staying close to the work
Chris’s lab remains part of his engineering routine. Alongside setting direction with product and helping the team prioritize, he runs the software himself to see what users experience.
One recent setup put three NVIDIA DGX Sparks on his desk, provisioned through Warewulf from a single RLC Pro AI image, with Fuzzball running on top. He went from hardware to submitting GPU jobs with only one physical task at the nodes: plugging them in.
“Seeing the whole CIQ stack click together like that, end to end, is when I knew what this team could do,” he says.
His work on Fuzzball, SKE, and Stratum Pro gives him a view across research computing, AI, and Kubernetes. As he sees it, increasingly, those environments share hardware and operational needs. He wants the people using them to benefit from a common foundation, with less time spent solving the same infrastructure problems independently.
Success would mean a researcher can run a workload without waiting on infrastructure setup, or a platform engineer can upgrade a fleet without organizing a weekend around it. The time saved goes back to the model, simulation, or analysis.
For Chris, SKE and Stratum Pro carry the idea he started in his home lab into the environments other people depend on. The measure of success will be what those people can accomplish with the products his team builds.
“If we get it right, people won’t talk about Stratum or Fuzzball much at all,” he says. “They’ll just talk about what they built on top.”
