What Exactly Is Kubernetes Used For?

Here's the honest answer from someone who's run it in production since 2018: Kubernetes is a distributed systems operating system. It's not "container orchestration" — that's what the docs say. What it actually does is give you a single, abstracted machine out of many physical ones.

I run SIVARO. We build data infrastructure and production AI systems. We've deployed Kubernetes in eight different environments, from bare metal in colos to managed services in three clouds. I've watched teams burn millions on complexity they didn't need. I've also watched teams scale from zero to 200K events/sec because Kubernetes made the hard parts boring.

So let me tell you what it's actually for.

The Short Answer (Because You're Busy)

Kubernetes is for three things:

Running containers across many machines — you describe what you want, it makes it happen
Self-healing infrastructure — things crash, Kubernetes fixes them
Standardizing how teams deploy — every service gets the same API, same lifecycle, same config

Everything else — autoscaling, service discovery, canary deployments, secrets management — is either a bonus or a distraction, depending on who you ask.

Kubernetes.io docs call it "an open-source system for automating deployment, scaling, and management of containerized applications." That's technically correct. But it misses the point.

The real question isn't "what does kubernetes actually do?" The real question is "what problem does it solve that matters to my business?"

What I Thought Kubernetes Was For (vs. What It Actually Does)

In 2017, I believed Kubernetes was about containers. Everyone did. Docker was hot, we were all microservices-curious, and the pitch was simple: "Package your app in a container, throw it at a cluster, magic happens."

I was wrong.

Kubernetes isn't about containers. Containers are just the unit of delivery. Kubernetes is about control.

What does kubernetes actually do? It gives you a declarative API for infrastructure. You write a YAML file that says "I want three copies of this service, each with 1 CPU and 2GB of RAM, exposed on port 8080." Kubernetes makes that true. If a machine dies, it recreates the containers somewhere else. If traffic spikes, it spins up more copies (if you've configured autoscaling). If you push a bad image, it rolls back.

This is powerful. It's also dangerous.

Because once you have this power, you start wanting to use it for everything. And that's how you end up with a 50-node cluster running a two-service application that could have been a single VM.

The Cluster: Your New Computer

Think about what an operating system does for a single machine:

Manages processes (start, stop, restart)
Allocates resources (CPU, memory, disk)
Provides networking (IP addresses, DNS, ports)
Handles failures (if a process crashes, the OS tells you)

Kubernetes does all of that, but for a cluster of machines. Red Hat's explainer frames it as "container orchestration." I prefer "distributed OS."

The control plane is the kernel. The nodes are the hardware. Pods are processes. Services are DNS entries. Deployments are systemd unit files.

Once you internalize this mapping, everything makes sense. You're writing configuration for a computer that happens to span 20 physical machines.

This is why people who "get" Kubernetes often have trouble explaining it to ops teams. The ops team thinks in terms of machines, IP addresses, and SSH keys. Kubernetes thinks in terms of desired state and reconciliation loops. The mental models don't match.

What Kubernetes Is Really Good At

1. Standardizing Deployment Across Teams

At SIVARO, we run about 40 microservices in production. Before Kubernetes, each team had their own deployment scripts. One team used Ansible. Another used bash scripts with scp. A third just SSH'd in and ran docker-compose manually.

This was a disaster.

When something broke, you had to learn three different deployment systems to debug it. Security audits were nightmares — we couldn't prove what was running where.

Kubernetes forced a standard. Every service gets a Deployment YAML. Every Deployment gets a Service. Every Service gets tested in staging before hitting production. The patterns are the same whether you're running a Go API, a Python worker, or a Rust data pipeline.

Google Cloud's Kubernetes docs emphasize multi-cloud portability. That's real, but it misses the bigger win: internal portability. When every team speaks the same deployment language, your infrastructure team can actually sleep at night.

2. Actually Useful Auto-Healing

I once watched a node die at 3 AM during a data processing run. Kubernetes detected the node was unhealthy, cordoned it off, and rescheduled the pods onto healthy nodes. The job completed 11 minutes late instead of failing entirely.

No human intervention. No pagers. No 3 AM fire drills.

That's the promise. And when it works, it's genuinely magical.

Kubernetes has a component called the controller manager that runs reconciliation loops. These loops constantly compare the current state of the world to the desired state you specified. When they diverge — a pod crashes, a node goes down, a liveness probe fails — Kubernetes takes corrective action.

This is what "self-healing" actually looks like. It's not AI. It's not magic. It's a bunch of loops running every 10 seconds checking "is this thing still alive?"

3. Resource Efficiency at Scale

Here's where the math gets interesting.

Running 40 microservices on 40 VMs (one service per VM) costs you 40x the base OS overhead. Even if each VM is tiny, you're paying for 40 kernels, 40 sets of monitoring agents, 40 security patches.

Run those same 40 services on a 5-node Kubernetes cluster, and you're paying for exactly 5 OS instances. Kubernetes schedules the containers across nodes based on resource requests and limits. Your CPU utilization goes from 15%% to 70%%. Your memory usage gets packed tighter.

At $100/month per VM, that's $4,000/month for the old way vs. $500/month for the Kubernetes way. The savings are real.

But — and this is a big but — you only get those savings once you're past a certain scale. If you have 5 services, just run them on 5 VMs. The Kubernetes overhead (what does kubernetes actually do for you besides add complexity?) isn't worth it.

What Kubernetes Is Terrible At

1. Simple Applications

I'll be direct: if your app fits on one machine, you don't need Kubernetes.

There's a popular Hacker News thread titled "I Didn't Need Kubernetes, and You Probably Don't Either" that makes this point brutally. The author's argument is simple: Kubernetes solves distributed systems problems. If you don't have distributed systems, you don't need a distributed systems solution.

I agree with most of it.

For a single Node.js app with a PostgreSQL database, run them on a $40/month VPS. Use docker-compose for local dev. Set up a cron job to reboot the machine weekly. Done.

Kubernetes would add: a control plane (3 machines minimum for HA), etcd (another 3 machines), network overlay complexity, ingress configuration, certificate management, and a learning curve that'll cost you weeks.

Ona's departure from Kubernetes illustrates this perfectly. They were a small team running straightforward applications. Kubernetes was overkill. They moved to simpler infrastructure and their deployment time dropped from 30 minutes to 2.

2. Stateful Workloads (Databases, Specifically)

Running PostgreSQL on Kubernetes is a rite of passage. Everyone tries it. Many regret it.

The problem is fundamental: Kubernetes assumes containers are ephemeral. Databases are the opposite of ephemeral. StatefulSets and PersistentVolumeClaims help, but they don't solve the core tension.

When a database pod restarts, it needs the same disk. Kubernetes can do this — but the failover behavior is awkward. If the node with your PostgreSQL pod dies, Kubernetes has to:

Detect the node is dead (30-60 seconds)
Mark the pod as failed
Schedule a new pod
Attach the same persistent volume
Start PostgreSQL
Wait for recovery

Total downtime: 2-5 minutes. For a database? That's unacceptable.

Managed DB services (RDS, Cloud SQL, Aurora) handle this in seconds. They're built for state. Kubernetes isn't.

I've seen teams make it work with operators like Zalando's Postgres Operator or Crunchy Data. It's possible. But the complexity isn't worth it for most teams. Run your databases outside Kubernetes. Your SRE will thank you.

3. Teams Without Dedicated Infrastructure People

Kubernetes requires ongoing maintenance. The control plane needs upgrades every few months. etcd needs monitoring. Node OS images need patching. CNI plugins break on kernel updates. DNS resolution fails for mysterious reasons.

If you don't have someone whose job is "keep the cluster running," you'll end up in a bad place.

This is why managed Kubernetes services (EKS, AKS, GKE) are popular. They handle the control plane. But even managed clusters need node management, application configuration, and incident response.

The teams I see fail with Kubernetes are the ones who treat it as "set it and forget it." It's not. It's a complex distributed system that needs care and feeding.

Why Are People Moving Away From Kubernetes?

This question comes up constantly. The Kubernetes hate piece by Dilshan W captures the mood well: Kubernetes has become synonymous with unnecessary complexity.

The reasons I see most often:

Cost surprises. Managed Kubernetes is free, but the supporting infrastructure isn't. Load balancers, NAT gateways, persistent volumes, monitoring — the bill adds up. I've seen teams triple their cloud costs moving to Kubernetes because they didn't account for these hidden expenses.

Operational complexity. A Reddit thread asked "What is the main reason you would give a company to use Kubernetes?" The top answer was about scalability. But the second highest was about not using it unless you absolutely need it.

Toolchain fatigue. Kubernetes itself is just the start. You need Helm for packaging. Istio or Linkerd for service mesh. Prometheus for monitoring. Fluentd for logging. ArgoCD for GitOps. Each tool adds cognitive load. Your team spends more time learning tools than building product.

The "it's just YAML" problem. Yaml configuration files grow exponentially. A simple deployment might be 50 lines. A production setup with health checks, resource limits, affinity rules, and configmaps can be 500 lines. Multiply that by 40 services and you have 20,000 lines of config to maintain.

When You Actually Need Kubernetes

I've found three scenarios where Kubernetes is the right answer.

Scenario 1: You Need to Scale Past Single-Machine Limits

If your application needs more CPU, memory, or network bandwidth than one machine can provide, you need a cluster. Kubernetes makes that cluster manageable.

We hit this at SIVARO during a data processing pipeline that needed 128 cores and 512GB RAM per batch job. No single VM could handle it efficiently. Kubernetes let us spread the work across 4 nodes, each processing a shard of data.

Scenario 2: You Have Multiple Teams with Different Release Cadences

When you're running 5+ teams deploying independently, Kubernetes provides guardrails. Each team gets their own namespace. Resource quotas prevent noisy neighbors. Network policies enforce security boundaries.

The Kubernetes overview describes this as "multi-tenancy." In practice, it means your infrastructure team isn't the bottleneck for deployments.

Scenario 3: You Need Zero-Downtime Deployments

Running rolling updates by hand is error-prone. Kubernetes handles this natively. You update the Deployment YAML with a new image tag. Kubernetes creates new pods, waits for them to pass readiness probes, then terminates old pods.

If something goes wrong — the new pods crash, health checks fail — Kubernetes stops the rollout. Your users never see the bad version.

Is Kubernetes CI or CD?

This question ("is kubernetes ci or cd?") comes up because Kubernetes blurs the line between CI/CD tools and deployment platforms.

Kubernetes is neither CI nor CD. It's the deployment target that CI/CD pipelines push to.

CI runs tests and builds container images. CD deploys those images to environments. Kubernetes is the platform that runs the deployed containers.

Most teams use something like GitHub Actions or GitLab CI to build images, then kubectl apply or helm upgrade to push to Kubernetes. Some use GitOps tools like ArgoCD or Flux that watch git repositories and sync changes automatically. That's CD — but Kubernetes is just the executor.

Think of it this way: Kubernetes is to CD what an aircraft carrier is to a navy. The carrier doesn't plan the mission — it just provides the runway and the fuel.

How Kubernetes Actually Works (The 5-Minute Version)

You need the mental model. Here it is:

You write YAML describing your desired state. "Run 3 copies of myapp:v2, each with 0.5 CPUs and 512MB RAM."
You submit the YAML to the Kubernetes API server (using kubectl apply or a CI/CD pipeline).
The control plane stores the desired state in etcd, a distributed key-value store.
Controllers (replication controller, node controller, etc.) watch etcd and make reality match the desired state.
The scheduler assigns pods to nodes based on resource availability and constraints.
The kubelet on each node runs the containers and reports status back.
The kube-proxy manages networking so services can reach each other.

That's it. Everything else is complexity layered on top.

Here's the simplest deployment you can write:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

This deploys 3 copies of nginx. If one crashes, Kubernetes starts another. If you change the image, Kubernetes rolls an update.

And here's what a service looks like to expose it:

yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer

Kubernetes assigns a stable IP and DNS name (nginx-service.default.svc.cluster.local). Other services can reach it without knowing which node it runs on.

What Does Kubernetes Actually Do in Production?

Let me give you a real example from SIVARO.

We run a stream processing pipeline that ingests 200K events per second. The pipeline has 4 stages: ingestion, transformation, enrichment, and storage. Each stage is a separate microservice.

Before Kubernetes, we ran this on 10 VMs. Deployments required SSHing into each machine, pulling new images, and restarting services. If a VM died, we had manual failover. If traffic spiked, we had to provision new VMs and manually reconfigure load balancers.

With Kubernetes:

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ingestion-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ingestion
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

This autoscaler monitors CPU usage and adjusts the number of ingestion pods between 3 and 20. When traffic drops at night, it scales down. When we run a campaign that spikes traffic, it scales up. No manual intervention.

The cost difference? Before Kubernetes, we had to provision for peak load: 10 VMs running 24/7. That's about $3,000/month. After Kubernetes, we provision for average load (3 pods/node, 5 nodes) and burst up. Total cost: $1,500/month, with capacity to handle 2x traffic spikes.

We saved 50%% while adding resilience.

The Hard Truth: Most Teams Don't Need Kubernetes

I've been running Kubernetes since 2018. I love it. I also know it's wrong for most teams.

Here's my litmus test. Answer these questions honestly:

Do you have more than 10 microservices?
Do you have more than 2 developers working on infrastructure?
Do you need to deploy more than once a week?
Do you have unpredictable traffic patterns?
Do you need to run workloads across multiple cloud providers or on-prem?

If you answered "no" to 3 or more of these, you don't need Kubernetes.

The "Do You Actually Need Kubernetes" video makes this case well. The creator runs a successful SaaS on a single server with docker-compose. His argument: complexity is a bad trade-off unless you're getting concrete benefits.

What should you use instead?

Single VM with docker-compose — perfect for 1-5 services
Platform-as-a-Service (Heroku, Railway, Fly.io) — great for 5-15 services with simple needs
Managed containers (AWS ECS, Google Cloud Run) — good for 10-30 services without the Kubernetes learning curve
Kubernetes — only when you've outgrown the above

I've migrated teams from Heroku to Kubernetes. I've also migrated teams from Kubernetes to simpler options. Each time, the right choice depended on the team's size, skills, and scale.

FAQ: What Exactly Is Kubernetes Used For?

Q: What exactly is kubernetes used for in simple terms?

Running containerized applications across multiple machines reliably. You tell it what you want (3 copies of your app, listening on port 8080), and it makes that happen. If machines fail, it fixes things. If traffic increases, it scales up. It's like having a robot sysadmin for your containerized apps.

Q: Is kubernetes ci or cd?

Neither. Kubernetes is the platform that runs what CI/CD pipelines produce. CI builds container images. CD deploys them to environments. Kubernetes is the environment — it hosts and manages the deployed containers.

Q: What does kubernetes actually do that Docker doesn't?

Docker runs containers on a single machine. Kubernetes runs containers across many machines, provides service discovery, handles rolling updates, manages secrets, and self-heals when things fail. Docker is a container runtime. Kubernetes is a container platform.

Q: Why are people moving away from kubernetes?

Three reasons: (1) They never needed it — their app fit on a single machine. (2) They underestimated operational complexity — maintaining clusters is a full-time job. (3) Hidden costs — managed Kubernetes is free, but the supporting infrastructure (load balancers, storage, monitoring) adds up. Ona's blog post documents this journey honestly.

Q: Is Kubernetes only for large companies?

No, but it makes most sense for teams with 10+ services and dedicated infrastructure engineers. Small teams can use managed Kubernetes (K3s, GKE Autopilot) effectively, but the learning curve is real. If you're a solo developer, skip it.

Q: Can Kubernetes run stateful applications?

Yes, but it's harder. StatefulSets and PersistentVolumeClaims support stateful workloads like databases. You'll need a storage provisioner (like CSI drivers) and careful configuration. Most teams prefer managed databases (RDS, Cloud SQL) and only run stateless apps on Kubernetes.

Q: What's the easiest way to try Kubernetes?

Use kind (Kubernetes in Docker) for local testing:

bash
# Install kind on macOS
brew install kind

# Create a cluster
kind create cluster --name test

# Verify it works
kubectl get nodes

# Clean up
kind delete cluster --name test

Or use Minikube for a full local cluster experience. Both run on your laptop and give you a production-like environment for testing.

The Bottom Line

Kubernetes is a powerful tool for a specific set of problems. If you need to run many containers across many machines with high reliability, it's the best option available.

If you don't have those problems, Kubernetes will create them.

The people who hate Kubernetes aren't wrong — they're usually trying to use it for the wrong application. The people who love it aren't wrong either — they've seen it solve real distributed systems challenges.

My advice: start simple. Use docker-compose on a VM. Graduate to managed containers (ECS, Cloud Run) when you outgrow that. Only reach for Kubernetes when you need to orchestrate across 5+ machines with complex networking, autoscaling, and deployment patterns.

At SIVARO, we use Kubernetes for our production AI systems. It's the right choice. But we also have services running on single VMs that will never move to the cluster. Knowing the difference is what makes a good infrastructure decision.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.