K8s in the cloud usually means a managed Kubernetes service, where the provider runs and maintains the control plane and you manage worker nodes and workloads, and that split is the single most important thing to understand before you sign up.
Managed does not mean hands-off. The service removes the hardest piece and leaves a lot of work in place.
Table of contents
- What managed Kubernetes means
- What the provider handles and what you do
- Where the cost really comes from
- Upgrades, security and day-two work
- When a simpler platform is the better answer
- A checklist before you commit
- Keeping a managed cluster healthy over time
- How this fits the rest of the stack
- FAQ
What managed Kubernetes means
Running Kubernetes yourself means operating its control plane: the API server, the scheduler, the controllers and the etcd datastore. That is real work. It needs high availability, backups, certificate rotation and careful upgrades.
A managed service takes that over. The provider runs the control plane, keeps it highly available, patches it and offers a path for version upgrades. The glossary pages describe it as a third party taking responsibility for some or all of the work of setting up and operating the cluster. Note the words some or all. Services differ in how far they go.
In the most common arrangement, you get a working API endpoint and you attach worker nodes. Those nodes are virtual machines, usually grouped into node pools with a machine size, a count and sometimes autoscaling bounds. You deploy workloads using the same objects as any cluster: Deployments, Services, Ingress and so on.
Some offerings go further and manage the nodes too, billing per workload rather than per machine. They reduce operations further and change the cost model and the control you have.
Because the Kubernetes API is standard, workloads are portable in principle between providers. In practice the surrounding pieces differ: load balancers, storage classes, identity integration and networking. So portability is real for the core objects and partial for everything around them. For a wider look at the options, the post on Kubernetes as a service is a good starting point.
What the provider handles and what you do
The line is worth writing down, because most surprises sit on it.
The provider typically handles:
- Running and patching the control plane.
- High availability of the API and datastore.
- Offering supported Kubernetes versions and upgrade tooling.
- Integration points for load balancers, disks and identity.
You still handle:
- Choosing node sizes and counts, and keeping nodes updated.
- Upgrading the cluster and node pools on your schedule, since versions fall out of support.
- Workload configuration: resource requests and limits, health probes, rollout strategy.
- Networking decisions: ingress, TLS, network policies.
- Security: access control, secrets, image scanning, pod security.
- Observability: logs, metrics and alerts.
- Backups of persistent data, which cluster-level tooling does not magically do.
- Cost control.
Teams that miss the second list are the ones who call managed Kubernetes a letdown. The provider is not negligent. The service simply does not include operating your applications.
Read the shared responsibility description of any service you consider, and check the details that matter to you, such as the guaranteed availability of the control plane, how long old versions stay supported and what happens at the end of that support.
Where the cost really comes from
The control plane fee, where one exists, is rarely the large item. The money goes elsewhere, and the typical bill has several pieces.
- Worker nodes. The compute that runs your pods. Usually the biggest line, and idle capacity is the biggest waste.
- Load balancers. Each service of the load balancer type can create a cloud load balancer with its own hourly charge.
- Persistent storage. Disks attached to stateful workloads, plus snapshots.
- Network traffic. Data leaving the provider’s network, and sometimes traffic between zones.
- NAT and ingress infrastructure. Gateways and extra components.
- Observability. Logs and metrics stored and processed can rival compute costs.
- People. Time spent on upgrades, incidents and tooling.
Right-sizing is the main lever. Pods declare resource requests, and the scheduler packs nodes using those numbers. Overstated requests leave nodes mostly empty and billed. Understated ones cause contention. Measure real usage over time and adjust.
Autoscaling helps in two places: scaling pods with load, and scaling the node pool to fit the pods. Both need tuning to avoid thrashing. The existing posts on Kubernetes load balancers and persistent volumes explain two of the usual bill surprises.
Upgrades, security and day-two work
The first deploy is the easy part. The recurring tasks are what define the experience.
Version upgrades. Kubernetes releases frequently and supports each version for a limited window. You must upgrade the control plane and node pools before support ends. Upgrades can deprecate APIs your manifests use, so test in a non-production cluster first.
Node maintenance. Nodes need operating system and runtime patching, or replacement with fresh images. Plan for pods to be rescheduled, which means workloads need multiple replicas and proper readiness probes.
Access control. Use role-based access with least privilege. Avoid long-lived admin credentials, and integrate with your identity provider where possible.
Secrets. Kubernetes secrets are base64 encoded, not encrypted by default. Enable encryption at rest and consider an external secrets system.
Network policy. By default pods can talk to each other freely. Restrict it for sensitive workloads.
Supply chain. Scan images, pin versions and restrict which registries can run in the cluster.
Backups. Back up manifests in Git and persistent data separately, and test the restore.
A team that cannot name who owns each of these is running a cluster by luck. If the people are not there, the answer is not to ignore the list. It is to choose a simpler platform.
When a simpler platform is the better answer
Managed Kubernetes pays off when you run many services, need fine control over scheduling and networking, have a team to operate it and benefit from the ecosystem of tools around it.
It is probably more than you need when you run a handful of services, a database and a few background jobs, and your deploy requirements are build, release and rollback. The overhead of node pools, ingress, upgrades and policies buys little in that case.
Alternatives scale from a single managed container service to a full platform. The post on Kubernetes alternatives lists them, and the discussion of serverless Kubernetes covers the middle ground where nodes are managed for you.
RunxBuild is a platform on the simple end of that range. It does not offer Kubernetes, but a web service takes a Docker image or builds from a GitHub repository, gets a live route, build and runtime logs, rollback to a previous deploy and autoscaling between plans you choose. Managed MySQL and Postgres sit beside it. That covers the common case without clusters or node pools. The Docker services docs describe the container route.
A fair test: if you cannot explain why you need Kubernetes in two sentences that do not mention it being the standard, you probably do not need it yet.
A checklist before you commit
If you do choose a managed Kubernetes service, work through this list first.
- Define who owns upgrades and who carries the pager.
- Check the service’s supported versions window and upgrade process.
- Decide on node pool strategy: sizes, counts, autoscaling bounds.
- Set resource requests and limits on every workload.
- Choose ingress and certificate handling, and test it.
- Put secrets handling and access control in place before real data arrives.
- Plan persistent data: use a managed database where you can, outside the cluster.
- Add cost visibility with labels or namespaces, and set budgets and alerts.
- Keep manifests in Git, deployed by a pipeline, never by hand.
- Practise a restore and an upgrade on a throwaway cluster.
Keep the first project small. Move one low-risk service, run it for a month and learn the real operating cost before committing everything.
Keeping a managed cluster healthy over time
Schedule a recurring review, monthly or quarterly, that looks at three things: the supported versions timeline, the utilisation of each node pool against what you pay for, and the list of workloads without resource requests or health probes. Small drifts are cheap to fix and expensive to ignore.
Document the runbook for the three incidents you are most likely to have: a node pool that will not scale, a failed rollout, and a certificate or ingress problem. Keep it where the on-call person can find it quickly, and update it after each real incident.
How this fits the rest of the stack
Kubernetes cost is mostly idle nodes, load balancers and people, and none of that shows on the product page. Compare a cluster estimate with a simple service and database in the RunxBuild hosting calculator. When your workload is closer to a few services and a database, the RunxBuild dashboard is where one gets created without a cluster.
Useful related references:
- Kubernetes Python: The Client Library, the Resources, the Custom Resources, and the Right Way to Use Python with k8s
- Cloud OS: What the Term Means and Why It Is Slippery
- Cloud Managed Firewall: What It Does, What It Doesn’t, When to Use One
- Services on RunxBuild
FAQ
What does managed Kubernetes include?
Typically the provider runs and patches the control plane with high availability, and offers upgrade tooling. You manage worker nodes, workloads, networking, security, observability and cost.
Do I still need to upgrade a managed cluster?
Yes. Kubernetes versions have limited support windows, so you must upgrade the control plane and node pools on your schedule, testing API deprecations first.
What makes managed Kubernetes expensive?
Mostly worker nodes with idle capacity, load balancers, persistent storage, data transfer, observability volume and the engineering time to operate it, rather than the control plane fee.
Is managed Kubernetes portable between providers?
The core Kubernetes objects are portable, but load balancers, storage classes, identity and networking differ, so moving still takes work.
When should I avoid Kubernetes?
When you run only a few services and need simple build, deploy and rollback. A managed platform or container service is usually cheaper to operate.