Kubernetes
Proof of concept limits and what changes in production
Every current limitation of ByteDC Managed Kubernetes, stated plainly, and what changes when you move to production.
What this is
An honest list of what ByteDC Managed Kubernetes does not do today, and what changes when you become a production customer.
This page exists so you find out the limits here, at your own pace, rather than discovering them mid project. If one of these limits rules out the platform for your use case, it is better for both sides that you know now.
Limits during a proof of concept
Quota ceiling. An evaluation tenant is capped at 2 vCPU, 4 GB of RAM, and a maximum of 10 pods. Attempting to scale past the pod limit returns a capacity message. See Scaling pods and understanding your quota.
No terminal access. You cannot open a shell against the cluster. The supported interface is Headlamp, plus the portal and your own kubeconfig. The intended model is to build your application into a container image, push it to a registry, and let Kubernetes run that image, rather than logging in and changing things by hand.
Images come from Docker Hub. Your images are pulled from Docker Hub today. ByteDC has already built a Harbor registry which is intended to become the internal registry later, or to serve dedicated customers, but it is not the path to use right now.
Helm charts are not connected. Deploy the image directly. A Helm based install is not available yet.
One region. Cambodia Primary is the only region available. Additional regions are on the roadmap.
Shared cluster type. Clusters created on the evaluation flow come out as type shared. Isolation between tenants is by namespace, which is enforced by the permission layer rather than by convention.
Quota changes are a conversation, not a setting. You cannot raise your own limits in the portal. Quota is set per customer by ByteDC.
What changes in production
Area | Proof of concept | Production |
|---|---|---|
CPU and memory | 2 vCPU, 4 GB RAM | Set per customer, and higher. These values are changeable |
Pod ceiling | 10 pods | Agreed with your account manager |
Quota governance | Standard small allowance, managed centrally | Named accounts go through a separate approval process owned by account management, which understands your actual requirement |
Isolation | Namespace on a shared cluster | Namespace, or your own API server on the Pro plan, or a dedicated cluster on Enterprise |
Registry | Docker Hub | Internal Harbor registry is planned, and dedicated customers are a stated use case for it |
The pattern is that the proof of concept ceilings are deliberate rather than technical. They exist so a trial does not consume production scale resource. Ask your account manager what your production allowance would be, and get the answer before you design around a number.
The plan you choose changes the isolation you get
Three plans, and the real difference is how much of the cluster is yours:
KaaS Starter, $31.9 per month including VAT. A namespace on a shared control plane, with RBAC and quota.
KaaS Pro, $108.9 per month including VAT. A vCluster with your own API server, on shared nodes.
KaaS Enterprise, priced by Contact Sales. A dedicated RKE2 cluster with full isolation and highly available etcd.
Every plan includes a managed control plane, Cilium CNI, auto-scaling and highly available etcd.
If a limitation above is a problem specifically because you are sharing, moving up a plan may solve it. If it is a platform wide limitation such as terminal access, changing plan will not help.
Questions worth asking before you commit
Take these to your account manager. Each one has bitten someone before:
What quota would we get in production, in exact numbers?
When Helm support and the internal registry land, and whether our timeline depends on either
Whether our evaluation environment carries over to production, or whether we rebuild
What the policy is when a wallet balance reaches zero, and how much warning we get
Whether a second region is on the roadmap, if resilience across regions matters to us
What you should understand after reading this
You can list the current limits without looking them up, you know which are proof of concept ceilings and which are platform wide, and you know which questions you still need answered before putting a production workload on the platform.
Common problems
A limit here is a blocker for us. Say so early. ByteDC has invited feature requests, and a capability that should exist can be added. That conversation is more useful before you have built around a workaround.
This page contradicts what I was told verbally. This page is written from the platform as demonstrated and tested. If something a person told you differs, get it confirmed in writing before you rely on it.