K8s Cluster Explained: Control Plane, Nodes and the Cost of Running One

A k8s cluster is a set of machines, one group running the control plane that makes decisions and the rest running your containers as worker nodes, and the real cost is rarely the machines but the operational work of keeping the whole thing healthy.

Kubernetes solves a real problem for teams running many services. The trap is adopting the cluster before you have the problem.

Table of contents

• What a cluster physically is
• The control plane, piece by piece
• Worker nodes, pods and what actually runs
• What you take on when you run one
• Managed clusters versus self-managed
• Signs you do not need a cluster yet
• A practical checklist before you build one
• How this fits the rest of the stack
• FAQ

What a cluster physically is

Strip away the vocabulary and a Kubernetes cluster is a group of ordinary machines that cooperate. Some run the software that decides what should happen. The rest run the containers that do the work. The machines can be physical servers, virtual machines or cloud instances, and the cluster does not care which.

The official architecture page describes it as a control plane plus a set of worker machines called nodes. That is the whole structure. You submit a description of what you want, such as three copies of this container image with this much memory each, and the cluster works continuously to make reality match. If a node dies, the cluster notices and starts replacements elsewhere.

That reconciliation loop is the central idea. You declare desired state, controllers compare it to actual state, and they act on the difference. It is why Kubernetes can restart a crashed container without a person involved, and also why it can make confusing changes when your declaration is wrong.

A cluster has a size that matters for cost and complexity. A development cluster can be one node on a laptop. A production one is typically at least three control-plane machines for resilience plus however many workers the workload needs. The post on what makes a big Kubernetes cluster explores the upper end.

The control plane, piece by piece

The control plane is the brain. It has a few components, and knowing them makes error messages less alien.

• API server. The front door. Every tool, from kubectl to controllers, talks to the cluster through it.
• etcd. The key-value database that stores all cluster state. Lose it without a backup and you lose the cluster’s memory.
• Scheduler. Chooses which node each new pod should run on, based on resource requests and constraints.
• Controller manager. Runs the loops that watch state and correct drift, such as keeping the replica count right.

On managed Kubernetes services the provider runs these for you, and you pay a management fee or accept it as part of the product. When you run your own, you are responsible for etcd backups, certificate rotation, upgrades and high availability of all four components.

That is the first honest cost of a self-managed cluster. The control plane is software that needs patching, monitoring and an on-call person who understands it. It is not a one-time install. Kubernetes releases frequently and old versions fall out of support, so upgrades are a recurring project rather than an event.

Worker nodes, pods and what actually runs

Worker nodes are where your applications live. Each node runs a container runtime, an agent called the kubelet that takes instructions from the control plane, and a network component that routes traffic to pods.

A pod is the smallest unit you deploy. Usually it holds one container, sometimes a few that must run together. You rarely create pods directly. You create a Deployment, which manages a set of identical pods and handles rolling updates, and a Service, which gives them a stable network address.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: registry.example.com/web:1.4.2
          resources:
            requests: { cpu: "250m", memory: "256Mi" }

The resource requests matter more than newcomers expect. The scheduler packs pods onto nodes using the numbers you declare, not what the process really uses. Requests that are too high waste money on idle capacity. Requests that are too low cause noisy neighbours and evictions. Right-sizing them is ongoing work.

For deeper reading on the objects involved, the existing posts on Kubernetes deployment YAML and Kubernetes namespaces cover the basics in more detail.

What you take on when you run one

The machines are the visible cost. The hidden costs are skills and time.

A production cluster needs decisions about networking, ingress and TLS, storage classes for persistent volumes, secrets handling, role-based access control, autoscaling, logging and monitoring, backup and disaster recovery, and an upgrade strategy. Each is a topic with its own tools and failure modes. Teams typically add a service mesh, a package manager such as Helm and a GitOps tool before long.

None of that is wrong. For an organisation with dozens of services and a platform team, it is the price of consistency and control. But it is a lot of surface area for a small team with a handful of apps, and the failure mode is a developer spending a quarter on cluster plumbing instead of the product.

A useful gut check is to count your services and your people. If you run fewer than ten services, have no one who wants to be the platform owner, and your deploy needs are a build, a release and a rollback, you are probably paying cluster complexity for benefits you do not use. Add the question of who gets paged when etcd is unhealthy at night. If the honest answer is nobody, reconsider.

Managed clusters versus self-managed

There are three ways to get a cluster.

1. Fully self-managed. You provision the machines and install everything. Maximum control, maximum burden. Reasonable on your own hardware or when you need exotic configuration.
2. Managed control plane. A cloud provider runs the control plane and you manage worker nodes. This is the common choice because it removes the hardest pieces.
3. Fully managed or serverless nodes. The provider also manages the nodes, and you pay per pod. Less to operate, less control, and a different cost model.

Even with a managed control plane you still own the workloads, the networking choices, the upgrades of node pools, and the cost of idle capacity. Providers differ in what is included, so read the shared responsibility details before you commit.

If you want a cost estimate before choosing, the Kubernetes calculator post walks through the main inputs. Note that quoted node prices are only part of the figure: add load balancers, persistent disks, egress traffic and the engineer time, which is usually the largest line.

Signs you do not need a cluster yet

Many applications run perfectly well without orchestration. Watch for these signs that you are ahead of your needs:

• Your deploy is one or two services plus a database.
• Traffic is predictable and a bigger machine would cover growth.
• You deploy a few times a week, not hundreds of times a day.
• No team requires isolation guarantees between workloads.

Common alternatives are a managed platform that builds from your repository and runs containers for you, plain virtual machines with a process manager, or a container service from a cloud provider with autoscaling but no cluster concept. The post on Kubernetes alternatives lists the main options.

On RunxBuild, a web service takes a Docker image or a build from a GitHub repository, gets a live route, build and runtime logs and rollback to a previous deploy, and autoscaling between plans you choose. That is not Kubernetes and does not try to be. It covers the common case of a few services and a managed database without the cluster to operate. Details are in the Docker services docs.

A practical checklist before you build one

If you do decide a cluster is right, spend an hour on these before the first node comes up.

1. Decide who owns it and who carries the pager.
2. Choose managed control plane unless you have a reason not to.
3. Set resource requests and limits on every workload from day one.
4. Plan the upgrade cadence and test it on a non-production cluster first.
5. Back up etcd, or confirm the provider does, and rehearse a restore.
6. Put cost visibility in place early, since idle node capacity quietly dominates the bill.
7. Keep stateful systems such as databases outside the cluster unless you have strong reasons, because managed databases handle backups and failover better than most hand-built operators.

Treat the cluster as a product with a roadmap, not a one-time project. The teams that struggle are usually the ones who built it once and left it to age.

How this fits the rest of the stack

Cluster costs are mostly invisible until the invoice and the on-call rota arrive. If your workload is closer to a few services and a database, price that simpler shape in the RunxBuild hosting calculator and compare it with the cluster estimate you have. When you want a service running without an orchestrator, the RunxBuild dashboard is where to create it.

Useful related references:

• Kubernetes Python: The Client Library, the Resources, the Custom Resources, and the Right Way to Use Python with k8s
• cPanel Multiple Servers: What You Can Cluster and What You Cannot
• redis-cli: Connect, Monitor, and Cluster Mode
• Node services on RunxBuild

FAQ

What is a Kubernetes cluster?

It is a group of machines in which a control plane decides what should run and worker nodes run your containers. You declare the desired state and the cluster keeps reality matching it, restarting or rescheduling workloads when nodes fail.

What is the difference between a node and a pod?

A node is a machine, physical or virtual, that runs workloads. A pod is the smallest deployable unit and usually wraps one container. Many pods run on each node.

How many nodes does a production cluster need?

Common guidance is three control-plane machines for resilience plus at least two or three workers, but it depends on the workload. A managed control plane hides the first number from you.

Is Kubernetes overkill for a small project?

Often yes. With a handful of services and one database, the operational work of a cluster can outweigh the benefits. A managed platform or a few virtual machines is usually simpler and cheaper to run.

What is etcd and why does it matter?

etcd is the database that stores all cluster state. If it is lost without a backup, the cluster loses its configuration, so backing it up and securing it is essential on self-managed clusters.