Multi-Tenant Kubernetes and GPU Capacity, Under Commercial Control
Kubernetes gives you orchestration. It does not give you tenants, entitlements, chargeback or an invoice. Hybr® connects the clusters you already run — upstream Kubernetes, OpenShift or Rancher — and turns their capacity, including GPUs, into services your customers can subscribe to and be billed for.
Bring the clusters you already have
There is no migration and no new distribution to adopt. You register an existing cluster through a short guided flow — basics, authentication, then settings — and it appears in Hybr® alongside the rest of your estate.
- Distributions — upstream Kubernetes, Red Hat OpenShift, or Rancher.
- Authentication — connect with a kubeconfig or a bearer token.
- Environment tagging — mark each cluster as development, staging or production so policy and reporting follow the environment.
- Live state — every registered cluster reports its node count, GPU count and current state in one view.
Assign capacity to tenants, not just to namespaces
This is the step that turns a cluster into a product. Each registered cluster is scoped one of two ways:
- Global shared — pooled capacity that many tenants draw from, with consumption attributed back to each one.
- Tenant subscription — a cluster dedicated to a single customer, for isolation, data residency or contractual reasons.
Because assignment is tied to a Hybr® subscription, the same role-based access control, quotas and approval workflows that govern the rest of your platform apply here too.
GPU-aware from the start
GPUs are the expensive part of the estate, so they are tracked as a first-class resource rather than inferred from node labels. Each cluster declares its GPU scheduling engine — native Kubernetes or Run:AI — and reports GPU counts next to node counts.
That makes GPU-as-a-Service a commercial proposition rather than a spreadsheet exercise: you can see who holds capacity, who is consuming it, and bill accordingly.
Workload visibility across clusters and namespaces
Operations teams get a single place to look. Filter workloads by cluster and by namespace to see what is actually running, without collecting kubeconfigs or jumping between consoles for each customer.
One catalog, one invoice
Kubernetes and GPU consumption feed the same commerce engine as your Microsoft CSP subscriptions, your VMware and Azure Stack workloads, and your AI services. Customers get one consolidated invoice; you maintain one set of offers, price lists and margins.
Who this is for
- Service providers offering managed Kubernetes or GPU capacity and needing per-tenant metering and isolation.
- Telcos and sovereign cloud operators running regional clusters that must stay contractually and geographically separated.
- Enterprise platform teams running shared clusters that need chargeback to business units.
Frequently asked questions
Does Hybr® provision the Kubernetes clusters?
No. You build clusters however you prefer, then register them with Hybr®. Hybr® provides the multi-tenancy, governance, visibility and billing layer above them.
Which distributions are supported?
Upstream Kubernetes, Red Hat OpenShift and Rancher.
How does Hybr® authenticate to a cluster?
With a kubeconfig or a bearer token, supplied during registration.
Can one cluster be dedicated to a single customer?
Yes. Scope it to a tenant subscription instead of global shared, and it is reserved to that customer.
How are GPUs scheduled?
Each cluster is registered with its GPU engine — native Kubernetes scheduling or Run:AI — and GPU counts are tracked per cluster.
Related: AI Factory · LLM Gateway · AI Application & Token Billing · Red Hat OpenShift · VMware Alternative · CSP Billing Ultimate · Cloud FinOps
See it against your own clusters
Register a cluster in a working session and see your own nodes, GPUs and workloads under tenant assignment.