Kubernetes
What Managed Kubernetes at ByteDC is, and who it is for
A plain language explainer of Managed Kubernetes at ByteDC, what a pod is, and whether you actually need it.
What this is
An explanation of Managed Kubernetes at ByteDC in plain language, written for someone who has not used Kubernetes before.
If you finish this page and conclude that you do not need Kubernetes, that is a useful outcome. Plenty of workloads run better and cheaper on a Cloud Server.
What Kubernetes does
Kubernetes runs your application inside containers and keeps it running. If a copy of your application crashes, Kubernetes starts a replacement. If you need more capacity, you tell Kubernetes to run more copies rather than building another server yourself.
The unit you work with is called a pod. For practical purposes you can think of a pod as behaving like a small compute instance running one copy of your application. It is not literally the same thing as a virtual machine, but that comparison gets you to the right mental model on day one: more pods means more copies of your application running, and more resource consumed.
What "managed" means here
Kubernetes has two halves. The control plane is the machinery that makes decisions about where things run. Your workloads are the applications you actually care about.
ByteDC runs the control plane. You run your workloads.
In practice, that split means:
ByteDC does: create the cluster, run and maintain the control plane, provide the networking layer, keep etcd highly available, and enforce your quota.
You do: build your application into a container image, deploy it, connect your services together, watch your own logs, and delete the cluster when you are finished.
Every plan includes a managed control plane, Cilium CNI for networking, auto-scaling, and high availability etcd.
The three plans
Plan | What you get | Price |
|---|---|---|
KaaS Starter | A namespace on a shared control plane, with RBAC and quota | $31.9 per month including VAT |
KaaS Pro | A vCluster with your own API server, running on shared nodes | $108.9 per month including VAT |
KaaS Enterprise | A dedicated RKE2 cluster with full isolation and highly available etcd | Contact Sales |
Screenshot needed: Kubernetes as a Services page showing the three plan cards.
The difference between them is isolation. Starter gives you your own namespace inside a shared cluster. Pro gives you your own API server. Enterprise gives you a dedicated cluster.
How tenants are kept apart
On the shared plans, the boundary between customers is the namespace. Your namespace is yours, and other customers cannot see into it.
This is enforced by the permission layer rather than by convention. Without a valid namespace binding, the cluster view shows nothing at all, and an incorrect namespace also shows nothing. ByteDC has verified this behaviour by deliberately removing and mis-setting the namespace binding and confirming that no resources became visible.
Who this is for
Kubernetes is a good fit if:
Your application is already containerised, or you are willing to containerise it
You need to run multiple copies of a service and scale that number up and down
You are running several services that need to talk to each other
Your team is comfortable with container tooling
A Cloud Server is the better choice if:
You have one application and it does not need to scale
Your application is not containerised and there is no appetite to change that
You want to log into a machine and manage it directly
That last point matters more than it sounds. Managed Kubernetes at ByteDC does not currently give you terminal access to the cluster, so if your working style is to open a shell and fix things by hand, this service will frustrate you. See Proof of concept limits and what changes in production.
What you should understand after reading this
You can explain what a pod is, you know that ByteDC runs the control plane and you run your workloads, you know the three plans differ by isolation level, and you have made a judgement about whether Kubernetes suits your application.