The concept

OpenKube is hub and spoke. The hub holds the catalog, policy, identity and billing, and never holds customer data. Each partner datacenter runs one spoke, installed on a small footprint of existing servers. The spoke is what actually builds clusters — so a site keeps running, and keeps serving its tenants, even when the hub is unreachable.

What OpenKube gives you

Control plane Datacenter Cluster

• One hub for every site

  A single API, CLI and console covering every datacenter in the fleet. Add a site and it shows up in the same catalog.

• Catalog and policy

  Define cluster sizes, Kubernetes versions, add-on sets and guardrails once. Every site offers the same menu, with local pricing.

• Identity and access

  SSO, OIDC and LDAP or Active Directory for operators and tenants, with role-based access down to the individual cluster.

• Metering and billing data

  Per-tenant usage on cores, memory, storage and clusters, exported to the billing system already in place.

• A spoke per datacenter

  Installs on a small footprint of existing servers. Provisions bare metal through Redfish and PXE, or virtual machines on the hypervisor already running.

• Storage that is already there

  CSI drivers front the existing SAN, NAS or software-defined storage, so clusters get persistent volumes without new hardware.

• Network that is already there

  Works with existing VLANs, IPAM, load balancers and firewalls. No overlay-only assumptions and no redesign of the fabric.

• Clusters on demand

  A tenant asks for a cluster and gets a conformant one in minutes, isolated from every other tenant on the floor.

• Day-two handled

  Version upgrades, security patching, certificate rotation, node repair and backup run as managed operations, not as tickets.

• Observability included

  Metrics, logs and health for the fleet and for each cluster, visible to the operator and, scoped down, to the tenant.

Datacenter and colocation partners

You have the floor space, power, network and storage. OpenKube turns that into a managed Kubernetes service you sell under your own name, without building a platform engineering team and without replacing anything you own.

How it fits into your datacenter

1. Install the spoke

   Three to five existing servers are enough to start. The spoke registers to the hub over an outbound TLS connection, so nothing new is exposed to the internet and no inbound firewall rules are needed.

2. Point it at what you already run

   Existing SAN, NAS or SDS through CSI. Existing VLANs, subnets and IPAM. Existing hypervisor, or bare metal through Redfish and PXE. Existing Active Directory or LDAP for identity. OpenKube consumes your infrastructure rather than asking for its own.

3. Publish your catalog

   Map cluster sizes to your capacity and your price book. Set the Kubernetes versions and add-ons you are willing to support, and the quotas per customer.

4. Sell and operate

   Your brand, your contract, your invoice. Customers self-serve clusters; OpenKube runs provisioning, upgrades, patching and backup underneath. Usage data lands in your billing system.

What it is worth to you

• Revenue per rack goes up

  A managed platform service carries a materially better margin than colocation or raw bare metal on the same footprint.

• No rip and replace

  The storage, network and servers you have already bought and depreciated are the ones OpenKube uses.

• You keep the customers you were losing

  Tenants who want Kubernetes stop having to leave for a public cloud to get it.

• A sovereignty story that holds up

  Workloads, data and control stay inside your building and your jurisdiction. That is increasingly the whole reason a customer picks you.

• No platform team to hire

  The hard parts — lifecycle, upgrades, multi-tenancy, isolation — are the product, not your roadmap.

• Idle capacity gets used

  Clusters are scheduled against your spare cores and terabytes instead of leaving them stranded.

Kubernetes solution partners

If you sell software that runs on Kubernetes, the private datacenter is usually where your deals slow down: every site is different, and someone has to stand up a cluster before your product can even be installed. OpenKube gives you one target that behaves the same everywhere.

• One API, every site

  The same call provisions a cluster in any partner datacenter. No per-site runbook, no bespoke installer.

• Conformant upstream Kubernetes

  No fork and no bespoke distribution. Your Helm charts and operators install unchanged.

• Add-on slots you can rely on

  Ingress, storage classes, certificates and monitoring are present and consistent, so your prerequisites are met before you arrive.

• Clusters for trials in minutes

  Spin up a short-lived cluster for a proof of concept, then throw it away. Evaluations stop waiting on procurement.

• Reach into private and regulated sites

  Co-sell into customers who will not move to public cloud, using the partner datacenters already on the network.

• Version control you can test against

  Pin the Kubernetes version per cluster, so you can certify your product against exactly what customers will run.

$ openkube cluster create \
    --name acme-prod \
    --site fra1 \
    --size medium \
    --version 1.33 \
    --addons ingress,monitoring,backup

  cluster acme-prod  building on spoke fra1
  control plane      ready
  workers 3/3        ready
  kubeconfig         written to ./acme-prod.kubeconfig

Want to certify your product on OpenKube, or list a datacenter? Write to us.

Contact us

Email

info@openkube.in