Kubernetes for sysadmins: when it is worth it, and when it is not

What Kubernetes actually is

Kubernetes is two things in one package. The first is a scheduler: a control plane that decides which container runs on which machine in a fleet, restarts containers that crash, and moves them when nodes fail. The second is an opinion about how applications should be described: declarative YAML manifests for every resource, immutable container images, no-ssh-into-the-box discipline, secrets and config as first-class API objects.

The scheduler part is what gets the marketing. The opinion part is what actually shapes the day-to-day. You do not write scripts that run things on servers; you write manifests that describe a desired state, you apply them, the control plane converges. When a node dies, the control plane reschedules the affected workloads onto other nodes. When you push a new image, you update the manifest, the control plane rolls the change forward, the old pods are drained as the new pods come up.

It runs on top of a fleet of nodes that are otherwise plain Linux boxes. Nothing about Kubernetes requires special hardware. The nodes can be VMs, bare metal, or a mix. The control plane (the API server, scheduler, controller manager and etcd) lives somewhere reachable from the nodes and the operators.

From the outside it is a fancy way to run containers. From the inside it is a strict accountancy of what is meant to be running where, plus the machinery to make reality match.

What Kubernetes solves

The problems Kubernetes does well, in roughly the order they show up:

• Scheduling many containers across many hosts. If you have ten services that need to live on five hosts and you cannot fit them all on one, the scheduling problem is non-trivial. K8s solves it.
• Self-healing. Crashed containers come back. Failed nodes get their workloads rescheduled. The control plane keeps trying to make reality match desired state.
• Rolling deploys. New version goes out a few pods at a time, old version drains, traffic shifts. If the new version fails its health checks, the rollout stops.
• Resource limits. Each container declares CPU and memory requests and limits. The scheduler packs them onto nodes. Misbehaving workloads cannot starve their neighbours.
• Service discovery and load balancing. Each service gets a DNS name inside the cluster. Pods come and go; the name resolves to whichever pods are healthy now. The reverse proxy in front of each service handles connection distribution.
• Configuration and secrets. ConfigMaps and Secrets are API objects. You declare them, the pod consumes them as files or environment variables. The application code does not need to know how the secret got there.

This is a substantial list. The fact that K8s solves these problems well is why it became dominant. The next question is whether you have these problems.

What Kubernetes does not solve

The list of things people expect Kubernetes to solve, and don't:

• Stateful workloads. Kubernetes can run them, but the operational complexity for databases, queues and caches inside the cluster is real and ongoing. Most teams end up running stateful services outside the cluster or with a dedicated operator that itself is a substantial project to operate.
• Your application's reliability. A flaky app gets rescheduled and crashes again. K8s does not make a bad app good; it makes a bad app respawn faster.
• Network policy by default. Pods can talk to other pods by default. NetworkPolicies are an opt-in feature that requires a compatible CNI. Without them, K8s does less for network security than a typical VM with a firewall.
• Security. Pod-to-pod TLS, runtime security, secret rotation, image vulnerability scanning, RBAC sanity, audit logging. Each is a thing you set up; K8s gives you the primitives, not the policy.
• Cost optimisation. A cluster of underused nodes is still a cluster of underused nodes. Cluster autoscaling helps, but only when your workloads have actual peaks and troughs.
• Developer experience for small teams. The "every dev gets their own ephemeral namespace" pattern needs significant tooling to make pleasant. Without it, K8s is friction for a small team.

The operational tax

Kubernetes has an operational cost. It is not abstract; it is engineering time. The components that need ongoing attention:

• Cluster upgrades. K8s ships a minor release every four months. Each is supported for about a year. If you self-host you upgrade every six to nine months or fall off support. Each upgrade is a non-trivial change to the control plane and the nodes.
• Certificate management. The internal PKI has certificates that expire. They need to be rotated. Some distributions handle this automatically; others assume you will.
• Storage drivers. If you use persistent volumes, the CSI driver is one more component to keep current and to debug when it misbehaves.
• Networking. The CNI plugin (Calico, Cilium, Flannel, Weave) is its own substack. Network performance, NetworkPolicy enforcement and IPv6 dual-stack all happen here.
• Observability. Prometheus, Grafana, an ingress for them, alert manager, log aggregation. Not strictly K8s but expected as part of the stack.
• Ingress controller. nginx-ingress, Traefik, or something exotic. The same questions as the reverse-proxies guide, plus the integration with K8s service discovery.
• Knowing what is broken. When something fails, the question is which of the dozen layers is the cause. Cluster troubleshooting becomes a skill of its own.

A reasonable rule of thumb: expect at least one full-time engineer per non-trivial production cluster, plus whatever time the application developers spend writing manifests. Managed K8s reduces the load by taking the control plane off your plate; it does not eliminate the rest.

When K8s is worth it

Honest signals that Kubernetes will repay its operational cost for your workload:

• You have more than a dozen distinct services in active development. Each has its own deployment pipeline.
• Multiple instances per service are the normal state, with traffic shifting between them on every deploy.
• You deploy more than once a day, and zero-downtime is a hard requirement.
• You have a team of engineers, not a solo operator or a pair, and the cluster supports multiple teams.
• The workloads are stateless or mostly so, and the stateful parts have been thought through carefully.
• You are already on a cloud provider whose managed K8s offering is mature, so the control-plane operational cost is zero.

If most of these are true, Kubernetes solves problems you have. The investment in learning and operating it pays off.

When it is not, and what to use instead

If most of those signals are missing, you are in the part of the problem space where Kubernetes is overkill. Three honest alternatives:

docker-compose on a single host. Underrated for small to medium production. One compose file describes all the services, restart policies handle crashes, healthchecks gate startup, a reverse proxy in front handles TLS and routing. Adds up to a real deployment that fits on one screen of YAML. The ceiling is "one machine you can fit it all on" and "an outage during deploy that takes seconds, not zero." For many shops that is fine.

Nomad. HashiCorp's container scheduler. Same shape as K8s, dramatically less complexity. A single binary that runs on each node, declarative job specifications, native integration with Consul for service discovery and Vault for secrets. Operates well at the scale where Kubernetes is too heavy and docker-compose is too small. The community is smaller and the ecosystem narrower, but the operational story is honest.

Plain systemd, one service per machine. The original. Still works. Pin services to machines, hold deploys with ansible or a simple shell script, use a load balancer in front for any service that needs replicas. It is unfashionable. It is also straightforward to understand and operate. For a fleet of fewer than twenty hosts running fewer than fifty services, the systemd approach is rarely the wrong answer; it is usually only the boring one.

The mistake to avoid is reaching for Kubernetes because the cloud provider's tutorials lead there, or because the architecture diagram looks more modern with a hexagonal cluster icon. The actual decision is between operational cost and the problems K8s solves. If you do not have those problems, you do not need the cost.

Managed Kubernetes: GKE, EKS, AKS, DOKS

If you have decided yes, the next question is who runs the control plane. Managed Kubernetes is dramatically less work than self-hosted; that is true on every provider. The differences between providers are real but smaller than the partisan camp would have you believe.

GKE (Google). Generally considered the most mature managed K8s, in part because Google originated Kubernetes. Auto-upgrade, Autopilot mode (the control plane and node sizing are both managed), strong defaults. The downside is GCP's network and storage offerings have a smaller surface than AWS, which matters if your application leans on managed databases or queues.

EKS (AWS). The most widely deployed in 2026. Mature, deeply integrated with the rest of AWS, but the integration friction is real if you want strong defaults out of the box. Be prepared to install several add-ons (the EBS CSI driver, the AWS load balancer controller, cluster autoscaler) that other providers ship pre-configured. EKS Fargate removes the node management for some workloads at a cost premium.

AKS (Azure). Solid, good integration with Azure Active Directory, the right call when your other infrastructure is on Azure. Outside Azure shops it is rarely the first pick on its own merits.

DOKS (DigitalOcean). Significantly cheaper than the big three. Less mature on advanced features (no spot nodes, narrower add-on catalogue). The right call for small teams that want managed K8s without committing to a hyperscaler. Linode and Vultr offerings are in the same category.

The honest test is which cloud you are otherwise on. If you are an AWS shop, EKS. If you are a Google shop, GKE. If you are starting fresh and cost matters, DOKS. None of these is wrong; the integration story dominates the technical differences.

Self-hosted Kubernetes: k3s, Talos, kubeadm

If you want to run Kubernetes yourself on your own hardware or VMs, three distributions worth knowing:

k3s. A single-binary K8s distribution from Rancher Labs (now SUSE). Lighter than vanilla K8s, single command install, ARM-friendly. Drops or replaces some non-essential components (etcd is optional, replaced by SQLite for single-node use). For homelab, edge deployments, and small production clusters, k3s is the practical pick.

Talos. A Kubernetes-specific Linux distribution. The OS itself is read-only and minimal; the only interface is the K8s API. No SSH, no shell, no package manager. The strict immutability is the security argument. The operational discipline it forces is the cultural argument. The learning curve is steep.

kubeadm. The official bootstrap tool. Maximum control, minimum opinion. You install the OS, you run kubeadm init, you install a CNI, you install everything else. The right call when you have specific requirements that other distributions cannot meet. The wrong call when you do not, because the setup work is genuine.

Self-hosted K8s in 2026 is a serious commitment. Unless you have a compliance or sovereignty reason that managed cannot meet, managed K8s is almost always the better economics. The self-hosted path is a legitimate one; it just costs more in engineering time than people expect when they start.

A minimum viable cluster

If you are doing K8s and want the smallest possible cluster that still earns its operational cost, three nodes is the floor.

Three nodes, each running:

• 4 vCPU, 8 GB RAM, 80 GB disk. Smaller than this and you spend more on the control plane than on your workloads.
• A managed K8s control plane on top, not the nodes themselves. Self-hosting the control plane on three nodes is technically possible and operationally a poor use of those nodes.
• An ingress controller (nginx-ingress or Traefik), with cert-manager for automatic TLS, and a Prometheus and Grafana stack from kube-prometheus-stack.
• An external database (RDS, Cloud SQL, or a dedicated VM). Not in the cluster.
• External object storage for user uploads and backups. Not in the cluster.

That is a usable production cluster. Three nodes with managed control plane is around USD 200 per month at most providers, plus the database and storage. Smaller than that, K8s is paying for itself badly. Larger than that, K8s starts to actually pay for itself.

A pragmatic verdict

The honest summary, written from outside the K8s evangelism circle:

• If you have a real fleet of services, a real team, real deploy frequency, and the operational budget for managed K8s, Kubernetes is the right call. It is the most mature option for that shape of work.
• If you have a single application on a single machine, or even a few applications on a few machines, you are paying for an answer to a problem you do not have. docker-compose or systemd is the right call.
• If you are in the middle, Nomad deserves consideration that the K8s-default ecosystem usually denies it.
• If you are choosing for career reasons rather than workload reasons, be honest about that with yourself, and do not impose the cost on your employer.

Kubernetes is a powerful piece of infrastructure that became dominant for good reasons. It is also overprovisioned for most of the workloads people apply it to. The question is not "should I learn Kubernetes." It is "should this workload run on Kubernetes," and the honest answer is often no. Saying no to K8s does not make you a luddite; it makes you an operator who has chosen the right tool for the size of the job. The K8s community will be there when the workload outgrows the simpler answer. Until then, the simpler answer is the right one.