Contact

Kubernetes platforms

We design and build Kubernetes platforms for superintelligence (SI) work on GPUs, on servers you control. Every change ships from Git, and each workload reaches only what it needs.

Scope a Kubernetes platformSee what we build

One platform, declared in Git

The cluster, its policies and every workload live in one repository. The cluster follows it.

  • Kubernetes on your servers

    Installed on your GPU servers and the servers around them, with the API and services on your own network.

  • GitOps deployment

    Every workload is declared in Git. A reviewed change merges, the cluster syncs to it, and a revert rolls it back.

  • Network-policy isolation

    Each workload gets only the network paths it needs. All other traffic is denied by default.

  • Admission policies

    The platform rejects workloads that break policy before they start.

  • Encrypted secrets

    Credentials are stored in Git encrypted, and only the cluster can open them.

  • Images built in CI

    Each image is built and tested in CI, kept in a private registry and deployed by digest.

  • Drift checks

    A nightly check lists anything running that Git does not declare.

  • Distributed storage

    Block volumes, object buckets and shared file systems, with volume snapshots.

    Distributed storage
From commit to GPUA reviewed change in the Git repository goes to CI, which builds the image and keeps it in a private registry by digest. The cluster syncs to Git. Inside the Kubernetes cluster, access control, admission policies and network policies sit above four namespaces, each inside a dashed policy boundary: Team A, Team B, an outside developer and a development copy. Under them sit CPU nodes, GPU nodes that give out GPUs by request, and distributed block, object and file storage.Git repositoryReviewed changeCI builds the imagePrivate registry, by digestThe clustersyncs to GitKubernetes clusterAccess controlAdmission policiesNetwork policiesTeam AOwn namespaceTeam BOwn namespaceOutside developerOwn namespaceDevelopment copyOwn namespaceCPU nodesGPU nodes (GPUs by request)Distributed storage: block, object, fileFrom commit to GPUA reviewed change in the Git repository goes to CI, which builds the image and keeps it in a private registry by digest. The cluster syncs to Git. Inside the Kubernetes cluster, access control, admission policies and network policies sit above four namespaces, each inside a dashed policy boundary: Team A, Team B, an outside developer and a development copy. Under them sit CPU nodes, GPU nodes that give out GPUs by request, and distributed block, object and file storage.Git repositoryReviewed changeCI builds the imagePrivate registry, by digestThe cluster syncs to GitKubernetes clusterAccess controlAdmission policiesNetwork policiesTeam AOwn namespaceTeam BOwn namespaceOutsidedeveloperOwn namespaceDevelopmentcopyOwn namespaceCPU nodesGPU nodes (GPUs by request)Distributed storage:block, object, file
From commit to GPUDashed lines mark each namespace's policy boundary.
Diagram in words

A reviewed change in the Git repository goes to CI, which builds the image and keeps it in a private registry by digest. The cluster syncs to Git. Inside the Kubernetes cluster, access control, admission policies and network policies sit above four namespaces, each inside a dashed policy boundary: Team A, Team B, an outside developer and a development copy. Under them sit CPU nodes, GPU nodes that give out GPUs by request, and distributed block, object and file storage.

A change opens as a request in Git. CI builds the image and runs its tests. The change is reviewed and merged. The cluster syncs to the merged commit. A revert restores the version before it.

Update requests for libraries and images open on their own and run the same tests. We build with open source tools, among them Argo CD for GitOps and Cilium for network policy.

Built for GPU work

Workloads ask for GPUs, and the scheduler places them on the nodes that have them.

Model serving and LLM inferenceOpen-weight and commercial model families, served from pinned versions on GPU nodes.
Agents and their toolsAgents and the MCP servers they call, each in its own namespace with its own network rules.
Search and retrievalSearch services and their indexes on block volumes.
Batch and scheduled jobsData processing and evaluation run as scheduled jobs.
  • GPU resourcesGPUs are offered to the scheduler through the device plugin, and a workload gets only the GPUs it requests.
  • GPU nodesNodes carry role labels, and GPU workloads are placed on the nodes that hold GPUs.
  • DriversGPU driver and kernel versions are held, and updated by plan with a node restart.
Sharing GPUs between workloads

Each team in its own space

Teams, products and outside developers share one cluster without reaching each other.

How we test isolation
  • NamespacesEach team, product or tenant runs in its own namespace, with its own credentials.
  • Restricted podsTenant workloads run under the restricted Pod Security standard.
  • Scoped accessOutside developers reach only the namespaces they are given.
  • Development copiesEach product can have a development copy, kept apart from production, that receives each build that passes its tests.
  • Tested isolationBefore handover, we run access, admission and network tests on your cluster and give you the results.

We run it ourselves

Our own products run on Kubernetes we built and operate this way, declared in Git and isolated by network policy, on distributed block, object and file storage.

  • ProductsOur products and their development copies.
  • TenantsEach tenant in its own namespace.

Where it runs

On servers you own, on systems we supply, or inside a private SI cloud.

How a platform project runs

Four steps, from your workloads today to a platform your team runs.

  1. Assess

    We map the workloads, the GPUs and servers, the teams that deploy and the rules they work under.

  2. Design

    We set the cluster layout, the namespaces and policies, storage and the delivery pipeline, and agree the plan.

  3. Build

    We build the platform from Git and test it under your workloads before it takes production traffic.

  4. Hand over

    Your team takes the platform into service with its repository, its policies, the test results and a runbook to run it from.

What you receive

What your team takes over at handover.

  • The repositoryEvery cluster setting, policy and workload, in Git you own.
  • The policiesNetwork, admission and access rules, each with the tests that check it.
  • Test resultsAccess, admission and network tests, run on your cluster before handover.
  • RunbooksUpgrades, node maintenance, adding a team and rolling back, written for your team.

Research

The newest articles from our Insights library, each with a full research report and its sources.

  1. ExplainerMIG, MPS or time-slicing: sharing GPUs on KubernetesMIG vs time-slicing vs MPS on Kubernetes: what each GPU sharing method isolates, what measurements show, how the device plugin exposes it and how to size a slice.Kubernetes platforms7 min readPDF report
  2. ExplainerSlurm or Kubernetes for GPU clusters: how to chooseSlurm vs Kubernetes for GPU clusters: the unit each scheduler places, how a training job starts all at once, where each fits and how one cluster runs both.Kubernetes platforms7 min readPDF report
  3. ExplainerDeploying LLMs on Kubernetes: serving, scaling and rollbacksLLM deployment on Kubernetes, layer by layer: model servers, inference-aware routing, scaling on queues and token backlog, scale to zero and rollbacks by weight and revert.Kubernetes platforms7 min readPDF report

Notices

Trademarks. NVIDIA, AMD, Ceph, Kubernetes and related product names are trademarks of their owners and are used only to identify products. No affiliation or endorsement is implied.

Tell us what your cluster must run.

Scope a Kubernetes platform