Skip to main content

What is Kube-DC?

Kube-DC is an open-source, Kubernetes-native cloud platform that delivers multi-tenant compute, networking, storage, and data services on shared infrastructure. It gives Organizations one consistent API and web console for governed Projects, virtual machines, Managed Clusters, databases, and the cloud resources around them.

Kube-DC Cloud is the hosted offering built with Kube-DC: the service provider operates the platform underneath; you manage your Organization, Projects, access, workloads and services.

What you can run​

  • Projects — the default way to deploy. Take your Project's kubeconfig and run applications, jobs, services, VMs and compatible Helm charts directly — no cluster to provision first. → Projects
  • Virtual Machines — Linux and Windows guests with cloud-init, persistent storage, browser console and SSH, on the same network as your containers
  • Managed Clusters — a tenant-controlled cluster of your own, provisioned by the platform, for software that needs operators, CRDs or other cluster-scoped control
  • Managed Databases — PostgreSQL and MariaDB with scheduled credential rotation
  • Networking — a private network (VPC) per Project, public and floating IPs, load balancers, HTTPS ingress with automatic certificates
  • Storage & data — block volumes for pods and VMs, S3-compatible object buckets, backups
  • Security services — managed secrets, certificates, database credentials and encryption keys

The mental model​

Kube-DC organizes everything in two levels:

Kube-DC cloud resource modelAn Organization contains Projects. A Project maps to a backing namespace and can contain applications and namespaced Kubernetes resources, virtual machines, networking, storage, managed services, and Managed Clusters with a separate Kubernetes API.GOVERNANCEOrganizationidentity · membershipbilling · shared quotaProjectworking boundary · backing namespacePROJECT CAPABILITIESApplicationsnamespacedresourcesVirtual machinesKubeVirtPlatform servicesnetwork · storagemanaged servicesManaged Clustersseparate API
An Organization supplies the identity, membership, billing, and shared-quota boundary; each Project is a separate working boundary containing namespaced workloads and optional Managed Clusters.

An Organization is the account boundary: it owns an organization-scoped identity realm (SSO), membership and billing.

A Project is the working boundary for a team or environment. It combines a Kubernetes backing namespace, Project RBAC, a private network, an optional quota, and a kubeconfig for direct API access — ready the moment it exists.

Within a Project you choose the execution boundary per workload:

  • Deploy directly in the Project for supported namespaced resources and unprivileged workloads — the fast, default path.
  • Create a Managed Cluster when the software needs control of Kubernetes at cluster scope (operators, CRDs, multiple namespaces, privileged access).

These are separate deployment targets with separate API endpoints — a choice you make upfront, not a migration you perform later.

Kube-DC manage organization view

Kubernetes-native management​

Kube-DC exposes its cloud services through Kubernetes APIs installed and operated by the platform. Everything you can click in the console is a Kubernetes resource in your Project, so the same state is available to:

  • The Kube-DC web console
  • kubectl and the Kubernetes API
  • Compatible Helm charts — charts whose rendered resources use the Project's supported namespaced APIs
  • Terraform, through the Kubernetes provider
  • An externally managed GitOps controller (Argo CD, Flux) targeting your Project kubeconfig
  • AI coding assistants, via agent skills

A Project does not permit tenants to install cluster-level extensions — see Projects for the exact capability boundary.

Next steps​