Kubernetes: does a small project need it?

A small project usually does not need Kubernetes: one or two applications, a database and a queue run fine on Docker Compose or a cloud's managed container service, while Kubernetes adds complexity that demands dedicated expertise. It pays off when there are many services, load swings noticeably during the day, you need autoscaling and self-healing, and someone on the team can run it.

Here is what Kubernetes gives you, what it costs and which alternatives exist.

What does Kubernetes give you?

Kubernetes is a container orchestration system: it runs applications on a cluster of servers, keeps the desired number of copies running, restarts failed ones, scales with load and rolls out new versions without downtime. All of it is described declaratively, in configuration files stored alongside the code.

What the project gets:

• self-healing — a failed container or server is replaced automatically;
• scaling — the number of copies grows and shrinks with load;
• zero-downtime deployments — a new version gradually replaces the old one, with automatic rollback on errors;
• one platform for many services, queues and background jobs;
• portability between clouds and your own servers.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.42.0
          ports: [{ containerPort: 8080 }]
          readinessProbe:
            httpGet: { path: /health, port: 8080 }

What does Kubernetes cost?

Kubernetes costs less in server bills than in time and expertise: the cluster must be set up, upgraded, monitored and debugged, and its networking, storage and secrets subsystems each have their own quirks. Without someone who knows it well, a simple problem can take days.

Cost	What it includes
Expertise	A DevOps engineer or team that knows Kubernetes
Cluster management	Version upgrades, nodes, networking, storage
Observability	Metrics, logs and tracing across many pods
Security	Access control, network policies, secrets, image updates
Developer time	Manifests, charts, debugging cluster-specific issues

Managed Kubernetes in the cloud removes part of the work — the provider runs the control plane — but application configuration, observability and security stay with your team.

Photo: Unsplash

What are the alternatives to Kubernetes?

The alternatives are Docker Compose on one or more servers, managed cloud container services and platforms that deploy your app straight from the repository. They cover the needs of most small and medium projects at a far lower operational cost.

How to choose:

1. Docker Compose on a server — one or two servers, simple deployments, few moving parts. Fits many products at launch and beyond.
2. Managed container services — the cloud runs and scales containers for you; no cluster to manage.
3. Deploy-from-repo platforms — deploy on commit with minimal setup; more expensive at scale.
4. Kubernetes — when all of the above is no longer enough.

We covered packaging applications into containers and how production images differ from development ones in Docker for development and production.

When is Kubernetes actually justified?

Kubernetes is justified when the system has many services, load fluctuates significantly, availability requirements are high and there is a team ready to operate it. Then its complexity pays for itself with automation you would otherwise have to build yourself.

Signs it is time

• ten or more services with independent deployments;
• load varies several-fold during the day or season, and manual scaling cannot keep up;
• strict availability and zero-downtime deployment requirements;
• a DevOps engineer or platform team is in place;
• the company runs across several clouds or its own servers and wants one platform.

If you have only one or two services, the question may be architecture rather than infrastructure — see monolith vs microservices.

How do you move to Kubernetes if you do need it?

Move to Kubernetes gradually, starting with a managed cluster in the cloud: migrate one non-critical service first, set up deployments, monitoring and logging, then move the rest. The database often stays in a managed cloud service rather than inside the cluster.

The migration path:

1. Containerise every application and get them running under Docker Compose.
2. Choose managed Kubernetes from a cloud provider.
3. Set up CI/CD, monitoring, log collection and secrets management.
4. Migrate the first non-critical service and rehearse deploys and rollbacks.
5. Move the remaining services one at a time.

In short

• Kubernetes provides self-healing, scaling and zero-downtime deploys for many services.
• The main cost is expertise and time to run the cluster, not just servers.
• Small projects are usually well served by Docker Compose or managed container services.
• Kubernetes is justified with many services, fluctuating load and a team to run it.
• Migrate gradually, starting with a managed cluster and a non-critical service.