Kubernetes: Do You Really Need It?

Most small and mid-sized businesses do not need Kubernetes. If you run a handful of services, deploy a few times a week and your traffic is fairly predictable, a managed platform such as a container service, a platform-as-a-service or even a couple of well-run virtual machines will be cheaper to operate and easier to hire for. Kubernetes earns its complexity when you run many services, need to scale them independently, and have people whose job includes looking after the platform.

That is not a criticism of Kubernetes. It is an excellent piece of engineering, and for the right organisation it is the correct answer. The trouble is that it is often adopted because it is fashionable, then becomes a permanent tax on a team that never needed it. This article helps you decide, explains what you are signing up for, and describes sensible alternatives.

What Kubernetes actually does

Kubernetes is an orchestrator. You tell it, in declarative files, what you want to be running: "three copies of this container, reachable on this address, restarted if they fail, updated gradually when the image changes". Kubernetes then works continuously to make reality match that description across a cluster of machines.

The main building blocks are worth knowing by name:

• Pod: the smallest unit, usually one container, sometimes a few that must run together.
• Deployment: keeps a chosen number of identical pods running and handles rolling updates.
• Service: a stable network address in front of a changing set of pods.
• Ingress or Gateway: routes outside traffic to services, usually by host name or path.
• ConfigMap and Secret: configuration and sensitive values supplied to pods.
• Namespace: a way of dividing a cluster between teams or environments.

If those terms are new, it helps to understand containers first; our article on Docker for business teams is a good starting point.

What it looks like in practice

A minimal Deployment and Service for a web application looks like this:

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
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 3000

That is about forty lines for one small service, and it does not yet include ingress, certificates, autoscaling, network policies, secrets management, logging or monitoring. Each of those is another component to choose, install and maintain. This is the hidden cost: Kubernetes is a platform you assemble, not a product you switch on.

The case for Kubernetes

• Many services, many teams. A common deployment model and namespaces give teams autonomy without chaos.
• Independent scaling. Different components scale on different signals, and the scheduler packs workloads efficiently onto machines.
• Self-healing and rolling updates. Failed pods are replaced and updates roll out gradually, which supports techniques like canary releases.
• A large ecosystem. Tools for monitoring, policy, GitOps and service meshes are built around it.
• Portability. The same manifests work on AWS, Azure and on your own hardware, within limits.

The case against, for small teams

• Operational load. Upgrades, node patching, certificate renewal and networking questions all land on someone.
• A steep learning curve. Debugging a failing pod involves several layers that do not exist on a plain virtual machine.
• Cost beyond compute. The cluster itself, the supporting tools and the engineering time all count.
• Easy to misconfigure. Overly broad permissions, missing resource limits and exposed dashboards are classic problems.
• Overkill for a monolith. A single application with a database gains little from an orchestrator.

A decision guide

Your situation	Sensible starting point
One or two applications, modest traffic	A managed web or app platform, or virtual machines with a deployment pipeline
A few containerised services, small team	A managed container service from your cloud provider, where you supply the image and it runs it
Event-driven or bursty workloads	Serverless functions or serverless containers
Many services, several teams, need for fine control	Managed Kubernetes (EKS or AKS) with a platform owner
Strict portability or on-premises requirement	Kubernetes, ideally with a managed control plane where possible

If you do choose Kubernetes, use the managed offering from your provider rather than running the control plane yourself. On AWS that is Amazon EKS and on Azure it is AKS. You still own the workloads, the configuration and much of the security, but not the control-plane servers.

Questions to ask before you commit

1. How many separately deployable services do we have, and how many will we have in a year?
2. Who will be on call for the cluster, and have they run one before?
3. What specific problem does Kubernetes solve that a managed container service does not?
4. Do we have monitoring, logging and a deployment pipeline ready? Without them a cluster is hard to run. See what to measure and alert on.
5. Could we describe the cluster and everything on it in code, so it can be rebuilt? See infrastructure as code with Terraform.

If you cannot answer the first three confidently, start simpler. Containers are the valuable step; orchestration can follow when the need is real.

Common mistakes

• Adopting it for a CV or a trend. Pick technology to solve a problem you actually have.
• No resource requests and limits. One noisy pod can starve its neighbours, and the scheduler cannot place workloads sensibly.
• Missing readiness probes. Traffic then reaches pods that are not ready, and rolling updates cause brief outages.
• Granting cluster-admin broadly. Use least-privilege roles per team and per automation account.
• Storing secrets in plain manifests. Kubernetes Secrets are only base64-encoded by default; use an external secret store or encryption at rest and keep them out of source control.
• Running stateful systems casually. Databases on Kubernetes need real expertise; a managed database is often the safer choice.
• Skipping upgrades. Kubernetes versions go out of support, and a cluster left alone becomes a risk. Plan regular upgrades.
• One giant cluster for everything. Separate production from experiments, at least by namespace and permissions, and often by cluster.

What it costs to run well

Beyond the cluster itself, budget for the surrounding work. Someone must plan version upgrades, which arrive regularly and are not optional for long. Someone must manage ingress, certificates and DNS, decide how secrets are supplied, and review access. Someone must be reachable when a node fails at night. In a small team these duties land on one or two people, which creates a single point of failure in your organisation rather than in your technology. Count that time honestly when comparing against a managed service, because it is usually the largest cost and the one that does not appear on the cloud invoice.

A middle path

A pragmatic route for many teams is to containerise everything first, deploy to a managed container service, and automate with a pipeline. That gives you most of the day-to-day benefits: repeatable builds, fast rollbacks and horizontal scaling. If you later outgrow it, your images and health checks move straight onto Kubernetes, so nothing is wasted. The reverse journey, from an over-engineered cluster to something simple, is usually harder to justify politically even when it would save money.

Summary

Kubernetes is a tool for scale and organisational complexity, not a badge of maturity. Choose it when you have the services, the team and the operational appetite; otherwise a managed alternative will serve you better and leave more budget for the product. CloudWiss's cloud and DevOps services include Docker containerisation and Kubernetes orchestration, and an honest assessment of whether you need the latter is a good first conversation.