What is Kubernetes? A short answer, then ten creative uses.

Kubernetes has a reputation for being the thing you add when a project has become serious, and a second reputation for being the thing that made a simple project complicated. Both are deserved. This article starts from the question people actually type: what is Kubernetes? Kubernetes runs containers across a group of machines and keeps them running the way you described, without anybody watching. Its obvious use — running a large application on many servers — is covered by every tutorial there is. This article is about the other uses: the ones that turn a cluster into a build farm, a fire drill, a GPU pool or an exit door from your cloud provider. First, briefly, what Kubernetes is and how it differs from Docker. Then ten creative ways to use it, counted down from ten, which you can build on a desk tonight, to one, the use we would keep if we could keep only one.

What is Kubernetes, actually?

Docker runs a container on one machine. Kubernetes runs many containers on many machines, and keeps them running. You describe what you want — three copies of this web app, this much memory each, reachable at this address — and Kubernetes works continuously to make the cluster match: it starts the containers, moves them off a machine that has died, restarts the ones that hang, and replaces them one by one when you release a new version. That loop, comparing what you asked for with what is actually running and closing the gap, is the whole idea.

Four words do most of the work. A cluster is the group of machines, called nodes, plus a control plane that makes the decisions. A pod is the smallest thing Kubernetes runs: one or more containers that share an address. A deployment says how many identical pods should exist and how to roll out a new version. A service is a stable address in front of pods that come and go. All of it is written as short text files, called manifests, which means the whole setup can live in a Git repository — the idea behind number one.

Kubernetes came out of Google, which had run its own services on an internal system called Borg for a decade. Google open-sourced Kubernetes in June 2014, released version 1.0 in July 2015 and handed it to the newly formed Cloud Native Computing Foundation, where it was the first project to graduate. The name is Greek for helmsman, and K8s is simply the K, the eight letters in between, and the s.

It is now the default way larger organisations run containers: in the Cloud Native Computing Foundation’s 2025 survey, 82% of container users ran Kubernetes in production. Individual developers are another matter. In the 2025 Stack Overflow survey, 71.1% of respondents used Docker and 28.5% used Kubernetes — most people who work with containers never touch a cluster. Kubernetes also does not stand still. A new version comes out about three times a year, 1.37 in August 2026, and each is supported for about fourteen months, which is part of what it costs, as the section on costs explains.

Kubernetes vs Docker: not rivals

Docker builds and runs containers; Kubernetes decides where, and how many of them, run across a group of machines. They are not alternatives. The same image, built with Docker, runs on a laptop under Docker and on a cluster under Kubernetes, unchanged. The honest comparison is Kubernetes against Docker Compose, which runs several containers together on a single machine.

The headline “Kubernetes drops Docker”, from 2022, confused a lot of people. What was removed in Kubernetes 1.24 was dockershim, an adapter Kubernetes used to talk to Docker’s engine on each node. Clusters now talk to containerd or CRI-O directly. Images built with Docker follow the open OCI image standard, so they run exactly as before. For a developer, nothing changed.

The rule of thumb is short. One or two servers and a handful of services: Docker Compose, and the ideas in ten creative ways to use Docker. Many services, several machines, traffic that rises and falls, or several teams deploying independently: that is the problem Kubernetes was built for, and the point at which its weight starts to pay for itself.

How we ranked them

Creative is a cheap word, so we gave it a test. Every entry had to be something other than running your main application, and it had to take something real off somebody’s week: a bill, a fragile manual step, a server that only one person understands, a risk nobody has measured.

Kubernetes is heavier than Docker, so we raised the bar. Most entries assume a cluster already exists — a managed one from a cloud provider, or a small one built with k3s — and ask what else it can do once you are paying for it. A use that would justify building a cluster from nothing is rare, and we say so where it applies.

The order runs from ten to one on what that is worth to a small business or a small development team, not on how clever the trick is. Every entry gets the same three beats: what it replaces, roughly how it is done, and the honest limit.

10. A Raspberry Pi cluster on the desk

What it replaces: reading about Kubernetes instead of watching it work. k3s is a certified Kubernetes distribution packed into a single small binary, built for small and ARM machines. Three or four Raspberry Pis, or a couple of old laptops, make a real cluster in an evening.

It earns its place because Kubernetes only makes sense when you see it recover. Run an app with three copies, then pull the power cable on one board, and watch the cluster notice and start the missing copy somewhere else. Release a new version and watch it replace the pods one at a time without the page going down. No diagram teaches that as well.

The honest limit: it is a classroom, not a server room. SD cards wear out, home internet is not a data centre, and a cluster on a desk has no backups unless you build them. Use it to learn, then run real work on a managed cluster or proper machines.

9. A fire drill: break things on purpose

What it replaces: finding out during a real outage that the retry logic never worked. Chaos engineering tools that run inside the cluster — Chaos Mesh and LitmusChaos are the open-source ones — kill pods, add network delay between services, fill a disk or cut a node off, on a schedule you choose.

The point is to rehearse. Kill the payment service’s pods on staging and see whether the checkout shows a clear message or a white page. Slow the database by half a second and see which page times out first. Every finding is a fix made on a quiet Tuesday instead of during a sale.

The honest limit: it is a discipline, not a product. Without monitoring that tells you what happened, a chaos experiment is just an outage you caused. Start on staging, keep every experiment small and reversible, and only bring it near production once the team trusts both the tool and its own dashboards. A small team without uptime commitments may get more from simpler checks first.

8. Scheduled jobs that survive the server they ran on

What it replaces: the crontab on one server that quietly stopped when the server was rebuilt, and the nightly backup that has been failing since March without anybody knowing. A Kubernetes CronJob runs a container on a schedule, anywhere in the cluster, so the job no longer depends on one machine staying alive.

It also fixes the details a plain crontab leaves to luck. A concurrency policy stops a slow backup from starting a second copy on top of itself. Failed runs are retried a set number of times. The last successful and failed runs are kept for inspection, and the schedule can be given an explicit time zone, so a 02:00 job does not move when the clocks change.

The honest limit: Kubernetes runs the job, it does not care whether the job did anything useful. A backup that exits successfully after writing an empty file is still a successful run. Alert on failures, check the output, and test the restore. For two jobs a month on a single server, a crontab with a ping to an uptime monitor is perfectly adequate.

7. Build machines that exist only while a job runs

What it replaces: paying per minute for hosted CI runners, or a build server that runs all night and still has last week’s files on it. GitHub’s Actions Runner Controller runs self-hosted runners as pods: when a workflow starts, a fresh runner appears, does the job, and is deleted. When nothing is building, the number of runners can drop to zero.

Each build starts from a clean image, so nothing leaks from one job to the next — no leftover tokens, no stale cache that makes a broken build pass. Large test suites can fan out across as many runners as the cluster has room for, and the runners sit on the same network as your staging services, which makes integration tests straightforward.

The honest limit is security. A runner inside your cluster runs whatever code the workflow contains, so it must never pick up jobs from pull requests by strangers — GitHub itself advises against self-hosted runners on public repositories. Building container images inside a pod also needs care: the easy way is a privileged container, which hands the build root on the node. Use a rootless builder, and keep runners in their own namespace with no access to production.

6. Workers that sleep at zero and wake up for the queue

What it replaces: a worker server that sits idle for twenty-two hours a day so that it is ready for two. KEDA, a Cloud Native Computing Foundation project, watches a queue, a database table, a schedule or dozens of other event sources, and scales a deployment from zero pods to as many as the work needs, then back to zero when it is done.

It suits any work that arrives in bursts: invoices rendered to PDF at the end of the month, product images resized after an import, a thousand emails after a newsletter goes out, a video converted after an upload. The queue fills, the workers appear, the queue empties, the workers disappear.

The honest limit is the first job of the burst. When nothing is running, the first message waits for a pod to start — seconds normally, longer if the cluster also has to add a machine. And scaling pods to zero saves money only if the machines underneath scale down too, which needs a node autoscaler as well. On a cluster of fixed size, idle pods cost nothing extra and the gain is mostly tidiness.

5. A private AI model that shares one expensive GPU

What it replaces: a graphics card bought for one internal AI tool and idle most of the day. NVIDIA’s GPU Operator for Kubernetes can share one GPU between several pods, either by time-slicing it or, on data-centre cards that support it, by splitting it into isolated slices. Several small models — a document summariser, an invoice reader, a classifier for incoming enquiries — can then share one card instead of needing one each.

The data never leaves your infrastructure, which is the whole reason to run models yourself, and the cluster schedules them like any other workload: restarted if they crash, moved if a node fails. Connected to your own documents it becomes the private version of RAG for business.

The honest limit: time-slicing shares the GPU’s time, not its memory, so one model that grows can push the others out, and a fault in one can affect them all. True isolation needs the hardware slicing that only expensive data-centre cards offer. GPU machines are also the most expensive nodes a cluster can have. For one model used by ten people, a single GPU server running it in Docker — number five in ten creative ways to use Docker — is simpler and cheaper.

4. Heavy batch work on cheap spare capacity

What it replaces: paying full price for computing power that only has to be there eventually. Cloud providers sell their unused capacity as spot machines at up to 90% off, with one catch: they can take a machine back at short notice — two minutes on AWS, thirty seconds on Azure, and on Google Cloud no notice at all unless you ask for one. Kubernetes is very good at that catch. When a spot node disappears, its pods are rescheduled onto other machines and failed jobs are retried.

Good candidates are jobs that are large, patient and can be resumed: nightly reports over a year of orders, re-rendering a product catalogue, processing an archive of scanned documents, training or fine-tuning a model that saves checkpoints. Put them on a spot node pool and keep everything else on ordinary machines.

The honest limit: only work that can be interrupted belongs there. Never the database, never the checkout, never anything a customer is waiting for. The job must save its progress, or a reclaimed machine costs you the whole run. And spot capacity can run out for a given machine type, so allow several types and expect the occasional delay.

3. One namespace per client

What it replaces: a separate server for every client or every customer of a software product, each configured by hand and each drifting from the others. A Kubernetes namespace is a named section of a cluster. Give each client their own, with a resource quota so no one can use more than their share, network policies so their services cannot talk to anyone else’s, and their own secrets.

Onboarding becomes applying a template; offboarding becomes deleting the namespace, which removes everything in it. It suits an agency hosting many client applications, and a software product that offers larger customers a dedicated instance. Every client runs on the same tested setup, and an improvement made once reaches all of them.

The honest limit: a namespace is a soft wall. All tenants share the cluster’s control plane and the nodes’ kernels — what the Kubernetes documentation calls soft multi-tenancy, meant for tenants who trust each other. It is right for clients you trust running code you wrote; it is not enough for tenants who might attack each other or for strictly regulated data, which need separate nodes or separate clusters. Note too that Kubernetes stores secrets unencrypted by default unless encryption at rest is switched on — a namespace does not change that.

2. An exit door from your cloud provider

What it replaces: the sentence “we cannot leave” about a cloud provider whose prices went up. Every certified Kubernetes platform — Amazon, Google and Microsoft’s managed services, DigitalOcean, European providers, a cluster on your own hardware — runs the same manifests in the same way. That is what the Cloud Native Computing Foundation’s conformance programme certifies, for more than 90 Kubernetes offerings. An application described for one cluster can be moved to another as a project of weeks, not a rewrite.

The value of an exit is that you rarely have to use it. A credible one changes the conversation about price, and it answers the question of where the data lives: if a client or a regulation requires an EU provider, the move is a known quantity rather than a guess.

The honest limit: portability covers the containers, not the services around them. A managed database, a queue, file storage or the login system bought from the cloud provider is lock-in Kubernetes does not remove, and load balancers, storage and permissions are set up differently on every platform. Keep the data layer portable too, or the door only opens halfway. Running on two clouds at the same time is a different and much more expensive idea — see the list of uses we left off.

1. The whole platform as a Git repository

What it replaces: changes made by hand on a live server, remembered by one person and written down nowhere. In GitOps, a tool running in the cluster — Argo CD or Flux, both graduated Cloud Native Computing Foundation projects — watches a Git repository and keeps the cluster identical to it. A change to production is a pull request. Somebody reviews it, it is merged, and the cluster updates itself.

It is number one because it turns operations from something people remember into something written down. Every change has an author, a reason and a review — the change record an auditor asks for. Rolling back is reverting a commit. A quick fix typed directly into the cluster is noticed and undone, so the repository stays the truth. And if a cluster is lost, a new one pointed at the same repository rebuilds the applications on its own.

It is also where several entries above come together. The namespaces in number three, the scheduled jobs in number eight and the queue workers in number six are all just files in the repository, reviewed and versioned like code.

The honest limits: secrets cannot go into Git as plain text, so they need an encrypted format or an external secret store from day one. The repository becomes the most sensitive thing you own, because whoever can merge to it controls production. And Git describes the applications, not the data: databases and uploaded files still need real backups and a tested restore.

Five we left off, and why

Kubernetes for a brochure website. A five-page site, or a WordPress site with a contact form, needs good hosting, not a cluster. Kubernetes adds moving parts that such a site will never use, and somebody pays for each of them.

Kubernetes for three containers on one server. Docker Compose runs a handful of services on one machine with a fraction of the complexity. Move up when you genuinely need several machines, automatic scaling or independent teams — not when a conference talk says you will.

Building your own control plane by hand for production. Assembling a cluster from scratch is an excellent way to learn and a poor way to run a business. Use a managed service, or k3s on small installations, and spend the time on the applications instead.

The production database in the cluster, with nobody who knows how to run it there. Databases can run well on Kubernetes, with an operator that handles replicas, backups and upgrades. Without someone who understands that operator, a managed database is usually cheaper once you count the hours.

Multi-cloud for its own sake. Running the same application on two clouds at once doubles the operations work for a level of resilience most businesses never need. Number two is about keeping the option to leave, not about living in two places permanently.

What it all costs

Kubernetes itself is open source and free. The costs are the machines, the control plane, and above all the people.

The control plane is where managed services differ. Amazon EKS charges $0.10 an hour per cluster, about $73 a month. Google GKE charges the same fee but gives each billing account a monthly credit that covers one zonal or Autopilot cluster. Azure AKS has a free tier without an uptime guarantee and a Standard tier at $0.10 an hour, and DigitalOcean does not charge for the control plane at all. On top come the nodes — usually at least three, so that losing one is not an outage — and the load balancers and storage they use.

The largest cost is attention. A cluster needs upgrading roughly three times a year to stay on a supported version, and a cluster nobody upgrades falls out of support in a little over a year; on EKS, staying on an old version then costs $0.60 an hour instead of $0.10. Somebody has to own upgrades, monitoring, security patches and backups. That line, not the hosting bill, is where the decision to use Kubernetes is really made — so make it on purpose.

If you only try one

Try number ten, even if you never put Kubernetes into production. An evening with k3s on two old machines teaches the idea behind every other entry: you describe what should be running, and the cluster keeps it that way when things break.

After that, it depends on where you stand. If your business runs on one or two servers, you probably do not need Kubernetes yet — the self-hosting ideas in ten creative ways to use Docker will do more for you. If you already run a cluster, do number one. It is the entry whose payoff grows every month it stays in place.

And if you would rather somebody else set it up, our Docker work covers Compose on a single server and Kubernetes when an application has outgrown it, and Node.js Hosting + Monitoring keeps it running afterwards. Tell us what runs where today, and we will tell you honestly whether Kubernetes would help — including when the answer is that you do not need it.

Sources

Every product, price and support claim above comes from the project’s or vendor’s own public pages, checked in October 2026. Prices and support terms move, so confirm before you commit.

• Kubernetes Documentation — Overview ↗

  Defines Kubernetes as a portable, extensible, open-source platform for managing containerized workloads and services. The name is Greek for helmsman or pilot, K8s counts the eight letters between the K and the s, and Google open-sourced the project in 2014.

• Kubernetes Blog — 10 years of Kubernetes ↗

  The first commit landed on 6 June 2014 and version 1.0 on 21 July 2015, when Google announced it would donate Kubernetes to the newly formed Cloud Native Computing Foundation. It became the foundation’s first graduated project in March 2018.

• Kubernetes — Patch releases ↗

  Minor releases come out about three times a year and receive roughly fourteen months of support: twelve months of standard support followed by two months of maintenance mode. Version 1.37 was released on 26 August 2026.

• Kubernetes Blog — Dockershim removal FAQ ↗

  Kubernetes 1.24 removed dockershim; images produced by docker build work with all CRI implementations, such as containerd and CRI-O.

• CNCF — Annual Cloud Native Survey 2025 ↗

  Published January 2026: 82% of container users run Kubernetes in production, up from 66% in 2023.

• Stack Overflow — 2025 Developer Survey, Technology ↗

  Among all respondents, 71.1% used Docker and 28.5% used Kubernetes in 2025.

• Kubernetes Documentation — Multi-tenancy ↗

  Describes namespaces, resource quotas and network policies as the building blocks for sharing a cluster, and distinguishes soft multi-tenancy between trusted tenants from hard multi-tenancy between tenants that do not trust each other.

• Kubernetes Documentation — Secrets ↗

  Secrets are, by default, stored unencrypted in the API server’s underlying data store (etcd); encryption at rest must be enabled separately.

• Kubernetes Documentation — CronJob ↗

  Covers concurrency policy (Allow, Forbid, Replace), job history limits and the time zone field.

• K3s — Requirements ↗

  A certified Kubernetes distribution and Cloud Native Computing Foundation sandbox project that runs on x86 and ARM, including Raspberry Pi. Minimum: 2 CPU cores and 2 GB of memory for a server node, 1 core and 512 MB for an agent; an SSD is recommended on a Raspberry Pi.

• Chaos Mesh ↗

  A chaos engineering platform for Kubernetes that injects pod, network, disk and node faults; an incubating Cloud Native Computing Foundation project, like LitmusChaos.

• GitHub Docs — Actions Runner Controller ↗

  A Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions; runner scale sets can scale down to zero runners.

• GitHub Docs — Self-hosted runner security ↗

  Recommends using self-hosted runners only with private repositories, because forks of a public repository can run code on them through pull requests.

• KEDA ↗

  Kubernetes event-driven autoscaling: scales workloads to and from zero based on queues, databases, schedules and more than 70 other built-in event sources; a Cloud Native Computing Foundation project since 2020, graduated in August 2023.

• NVIDIA — GPU Operator, time-slicing ↗

  Time-slicing lets several pods share one GPU but provides no memory or fault isolation between them; Multi-Instance GPU (MIG) partitions supported data-centre GPUs into isolated instances.

• AWS — EC2 Spot Instances ↗

  Spare EC2 capacity at up to 90% off On-Demand prices, reclaimable with a two-minute interruption notice.

• Google Cloud — Spot VMs ↗

  Spot VMs cost up to 91% less than standard VMs. A preemption notice is optional — none by default, or 120 seconds if configured — and the shutdown that follows takes up to 30 seconds.

• Microsoft Learn — Azure Spot Virtual Machines ↗

  Spot VMs use spare Azure capacity at a discount of up to 90% and can be evicted with 30 seconds’ notice.

• Argo CD ↗

  A declarative GitOps continuous delivery tool for Kubernetes that keeps cluster state in sync with a Git repository; part of the Argo project, which graduated in the Cloud Native Computing Foundation in December 2022.

• Flux ↗

  A GitOps toolkit that reconciles clusters with Git repositories and other sources; graduated in the Cloud Native Computing Foundation in November 2022.

• CNCF — Certified Kubernetes Software Conformance ↗

  Lists over 90 Certified Kubernetes offerings; conformance means the same APIs behave the same way, so workloads move from one certified installation to another.

• Amazon EKS — Pricing ↗

  $0.10 per cluster per hour while the Kubernetes version is in standard support, and $0.60 per cluster per hour once it is in extended support.

• Google Kubernetes Engine — Pricing ↗

  A cluster management fee of $0.10 per cluster per hour, with a free-tier credit of $74.40 a month per billing account, usable on zonal and Autopilot clusters.

• Azure Kubernetes Service — Pricing ↗

  The Free tier has no control-plane charge and no uptime SLA; the Standard tier costs $0.10 per cluster per hour (Azure retail price list, East US).

• DigitalOcean Kubernetes — Pricing ↗

  No charge for the control plane; the high-availability control plane is $40 a month.