What Exactly Is Kubernetes Used For? (And Should You Even Care?)

First, a confession: I've spent more nights than I'd like to admit debugging a cluster that decided to eat its own control plane at 2 AM. I'm Nishaant Dixit, founder of SIVARO — we build data infrastructure and production AI systems. We've been running Kubernetes in production since 2018, processing 200K events per second at peak.

So what exactly is kubernetes used for? Let me give you a straight answer, not a vendor pitch.

Kubernetes is a container orchestration platform. That's the boring, textbook definition. The real answer: it's a distributed systems operating system. You give it a bunch of machines (physical or virtual), and it decides where to run your software, when to restart it, how to scale it, and how to connect it to other services.

But here's the thing most people get wrong — is kubernetes the same as aws? No. Not even close. AWS is a cloud provider. Kubernetes is a platform you run on top of AWS (or GCP, Azure, or your own bare metal). People confuse the two because AWS offers EKS (Elastic Kubernetes Service), which is their managed Kubernetes offering. But Kubernetes itself is provider-agnostic.

I wrote this guide because I keep seeing the same confusion. Teams adopt Kubernetes because "everyone's doing it." Then they hemorrhage engineering time maintaining it. Then they ask why are people moving away from kubernetes? because their own experience is painful.

By the end of this, you'll know exactly what Kubernetes is good for, when it's overkill, and how to avoid the traps I've fallen into.

The Problem Kubernetes Actually Solves

Let me tell you about a system we built at SIVARO in 2019 — a real-time fraud detection pipeline. We had:

12 microservices
A Kafka cluster
Three databases (Postgres, Redis, Cassandra — yes, the architecture was messy)
A batch processing job that ran hourly
A streaming job that ran continuously

Before Kubernetes, this meant:

Each service had its own deployment script
Scaling required manual intervention
Rolling updates meant copying files to servers by hand (I wish I was joking)
If a server died, someone got paged at 3 AM to reprovision it

That's the problem Kubernetes solves. It takes your containerized applications and says: "I'll handle the rest." Red Hat's definition gets this right — it's about automation of deployment, scaling, and management.

But here's the catch. Most people don't have twelve microservices. Most people have one Rails app or one Node.js backend. And for them, Kubernetes is a chainsaw when they need a pocket knife.

Container Orchestration: The Technical Meat

Let's get into how it actually works. A Kubernetes cluster has two parts:

Control plane — the brains. Runs the API server, scheduler, and controller managers. Makes all the decisions.

Worker nodes — the muscles. Run your actual applications inside containers.

When you deploy something to Kubernetes, you write a YAML file that describes what you want. Like this:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:latest
        ports:
        - containerPort: 8080

This says: "Run three copies of my-app, make sure they're always running, and expose port 8080."

Kubernetes then:

Pulls the image from a registry
Schedules each replica to a worker node
Monitors health by checking the port
Replaces any container that crashes
Distributes traffic across all healthy replicas

That's the core loop. But the real power comes from the other primitives.

Services — stable networking. Pods (the smallest deployable units) come and go. Services give them a fixed IP and DNS name.

yaml
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

ConfigMaps and Secrets — configuration management. You never hardcode database URLs or API keys in your image. You inject them at runtime.

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgres://db.internal:5432/mydb"

HorizontalPodAutoscaler — automatic scaling. When CPU goes above 70%%, spin up more pods. When traffic drops, scale down.

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

This is what the official Kubernetes documentation covers — but they don't tell you how often these things break in production.

PersistentVolumeClaims — stateful storage. Databases are hard on Kubernetes. You need to bind storage to specific pods and make sure it survives restarts.

yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

The Six Things Kubernetes Is Actually Good For

After seven years of running this stuff, here's my honest list:

1. Traffic spikes that kill servers

Black Friday. Product launches. DDOS attacks (the legitimate kind from sudden popularity). We had a client whose traffic went from 10K req/s to 150K req/s in 90 seconds. AWS auto-scaling groups couldn't keep up — too slow. Kubernetes HPA with custom metrics scaled from 20 pods to 300 in under 2 minutes.

2. Microservices that talk to each other

If you have 5+ services that need to discover each other, load balance, retry on failure, and handle network partitions, Kubernetes saves you from building all that yourself. Its built-in DNS and service mesh support handle it.

3. Deployment rollback without pain

Bad deployment at 4 PM on a Friday? kubectl rollout undo deployment/my-app. That's it. It reverts to the last known good state. No SSH, no reverting database migrations, no "who deployed what" blame game.

4. Multi-cloud or hybrid cloud without rewriting

We run workloads across AWS, GCP, and on-prem. Kubernetes abstracts the infrastructure. Same YAML deploys everywhere. Google Cloud's definition hits this — it's about portability.

5. CI/CD that actually works end-to-end

When your pipeline builds a container image, pushes it to a registry, and then deploys it to Kubernetes, you get true continuous delivery. No manual "ssh into box and pull latest" nonsense.

6. Resource utilization

Before Kubernetes, your servers ran at 15-20%% CPU utilization because you reserved capacity for peak load. Kubernetes bin-packs containers onto nodes, letting you hit 60-80%% utilization. That's real money saved on cloud bills.

When Kubernetes Is A Mistake

Let me be blunt. Most teams don't need Kubernetes. And I'm not the only one saying this.

A thread on Hacker News put it perfectly: "I Didn't Need Kubernetes, and You Probably Don't Either." The author's point: if you're running a single stateless application, you're paying a complexity tax for no benefit.

Ona's blog post about leaving Kubernetes is even more damning. They're a real company that ran on Kubernetes for years, then migrated off it. Their reasons:

Operational overhead was consuming 40%% of engineering time
Cost of running the control plane was higher than the savings
Their architecture didn't need the abstractions

A Reddit thread asked people to give one reason to adopt Kubernetes. The top answers weren't about features. They were about standardization and consistency.

Here's my rule of thumb:

Don't use Kubernetes if:

You have fewer than 5 services
You have fewer than 3 engineers on call
You're not running containers already
Your traffic is predictable and steady
You're okay with 5-10 minutes of downtime for deployments

Do use Kubernetes if:

You have 10+ services with complex dependencies
You need to scale sub-minute for traffic surges
You're running multiple environments (dev, staging, prod)
You have a dedicated platform/infra team (or are willing to hire one)
Your deployment frequency is multiple times per day

Why Are People Moving Away from Kubernetes?

This is the question I get asked most at conferences and by clients. why are people moving away from kubernetes? It's not a fad. It's a real trend driven by three specific failures.

Complexity isn't free. Setting up a production-grade cluster requires cert-manager, ingress controllers, service meshes, monitoring stacks (Prometheus + Grafana), logging pipelines (Fluentd/Logstash), and secrets management (Vault). That's 6-8 additional systems you now need to maintain. Each one can break in its own special way.

Cost surprises. At SIVARO, we ran a cluster on AWS EKS with 30 nodes. The Kubernetes management fee was negligible. But the unused capacity? The three-node cluster just for the control plane? The load balancers for every single service? That added 30%% to our infra bill compared to a simpler EC2-based setup.

The tooling tax. kubectl is just the start. You need Helm for packaging. Kustomize for config management. ArgoCD for GitOps. Istio or Linkerd for service mesh. Flagger for canary deployments. Every tool solves a real problem, but each one adds another layer of abstraction you have to debug when things go wrong.

Dilshan's Kubernetes Hater's Guide nails the emotional side. People hate Kubernetes because they were sold a promise of simplicity and got complexity. The marketing says "deploy with one command." The reality is: "here's a 47-page YAML file, good luck."

The SIVARO Test: How We Decided Kubernetes Was Right For Us

I'll share exactly how we evaluated this at SIVARO in 2020. We were rebuilding our data pipeline. We had three options:

Option A: AWS ECS + Fargate. Serverless containers. Managed by Amazon. Minimal operational overhead.

Option B: Kubernetes on EKS. Full control. More complexity. Higher ceiling.

Option C: Nomad + Consul + Vault. HashiCorp stack. Simpler than K8s but less ecosystem.

We ran a 3-month pilot with all three. Here's what we found:

ECS was great for the first 10 services. At 15 services, its service discovery model broke down. We couldn't do blue-green deployments without custom scripts. And scaling policies were too coarse.

Kubernetes took 2 weeks to set up properly (we were learning). But once it was running, adding new services took hours instead of days.

Nomad was actually faster to deploy and easier to manage. But its ecosystem was smaller — finding engineers who knew Nomad was hard. And some tools we needed (like a proper service mesh) didn't have mature Nomad integrations.

We chose Kubernetes. Not because it was the best tool — but because it was the most universal tool. Every new hire had experience with it. Every third-party tool (Datadog, New Relic, GitHub Actions) had native K8s support.

That's the real answer to what exactly is kubernetes used for — it's used as a standard abstraction for the entire engineering organization. It's not about the technology. It's about the ecosystem.

Five Years of Production Lessons

I'll give you the unfiltered lessons, the ones you won't read in the docs.

Lesson 1: Start with a managed service. Running your own control plane is masochism. Use EKS (AWS), GKE (GCP), or AKS (Azure). The cloud provider manages the API server, etcd, and scheduler. You manage the worker nodes and applications.

Lesson 2: Don't use stock metrics for autoscaling. CPU-based HPA is useless for most applications. Your app might be waiting on database queries, not CPU cycles. Use custom metrics — request latency, queue depth, or custom application metrics. We use KEDA (Kubernetes Event-Driven Autoscaling) with Prometheus metrics.

Lesson 3: Stateful workloads are a trap. Running MySQL or PostgreSQL on Kubernetes is possible. You'll find blog posts showing how. What those posts don't show is the 3 AM debugging session when a statefulset pod restarts on a different node and can't find its data. For databases, use the cloud provider's managed service (RDS, Cloud SQL). The cost premium is worth the sanity.

Lesson 4: YAML drift is real. You'll have 50 YAML files describing your deployment. Someone will hand-edit a configuration mid-incident. Then the GitOps sync will overwrite it. Then you'll be in a blame loop. Use ArgoCD or Flux for GitOps from day one. Never apply YAML directly with kubectl.

Lesson 5: Networking is where Kubernetes gets weird. Every pod gets its own IP address. That's thousands of IPs. Your VPC might run out. You'll need a CNI plugin (Calico, Cilium, AWS VPC CNI) that manages IP allocation. Cilium with eBPF is what we use now — better performance and security than the alternatives.

Lesson 6: The learning curve is real, but front-loaded. First 3 months are brutal. Months 4-12 are productive. After 18 months, you can't imagine going back to manual deployments.

The Infrastructure That Runs It

Let me give you a real example — the production cluster at SIVARO that processes 200K events/second in real-time for a fraud detection system:

Control plane: EKS managed (AWS handles upgrades)
Worker nodes: 3 node groups — general (m5.large), compute (c5.2xlarge), memory (r5.xlarge)
Storage: EBS gp3 for persistent volumes, S3 for object storage
Networking: Calico for network policies, AWS NLB for external traffic
Monitoring: Prometheus + Grafana on dedicated nodes
Logging: Fluentbit -> OpenSearch
CI/CD: GitHub Actions -> ArgoCD
Service mesh: Istio (started with Linkerd, migrated for better mTLS support) — yes, we have a bias [we're happy to discuss]
Secrets: AWS Secrets Manager + External Secrets Operator

This isn't a toy setup. It handles production traffic, has survived three AWS region outages (partial), and costs about $12K/month in infrastructure. Before Kubernetes, the same workload ran on bare EC2 instances costing $22K/month with worse reliability.

FAQ: What You Actually Need To Know

Is Kubernetes the same as Docker?

No. Docker creates and runs containers. Kubernetes orchestrates containers across multiple machines. You can use Docker without Kubernetes (for local dev or single-server deployments). You can use Kubernetes with other container runtimes (containerd, CRI-O). They solve different problems.

How long does it take to learn Kubernetes?

Realistically? 3-6 months to be productive. 12-18 months to be confident in production. The official docs are good but don't teach you the operational stuff. I recommend:

Kelsey Hightower's "Kubernetes the Hard Way" (you'll understand the internals)
Running a local cluster with kind or minikube for 2-4 weeks
Then deploying a real application to a cloud-managed cluster

What's the minimum team size?

Three people who can share on-call duties. One person maintaining a Kubernetes cluster alone will burn out. The complexity of upgrades, security patches, and incident response demands at least two people who understand the system.

Can Kubernetes save money on cloud bills?

Sometimes. If you're running 50+ servers at 20%% utilization, Kubernetes bin-packing can push utilization to 50-60%%. That's real savings. But if you're running 5 servers, the control plane overhead (even managed) eats into any savings. We saw 30%% cost reduction at scale, but many small teams see cost increases.

Do I need Kubernetes for serverless?

No. AWS Lambda, Google Cloud Functions, and Azure Functions handle scaling and orchestration without Kubernetes. They're simpler and cheaper for event-driven workloads. Use Kubernetes when you need long-running services, stateful applications, or complex networking.

Is Kubernetes dying? (People keep asking this)

No. It's maturing. The hype cycle is past its peak. Adoption continues growing in enterprises. But the narrative has shifted from "Kubernetes for everything" to "Kubernetes where it makes sense." The videos explaining when not to use it are getting more views than the "Kubernetes for beginners" tutorials. That's healthy.

What's replacing Kubernetes?

Nothing yet. Nomad, Docker Swarm, and AWS ECS each have their niches but haven't dethroned K8s. The trend is toward abstracting away Kubernetes — platforms like Render, Railway, and Fly.io that give you similar benefits without managing a cluster. But underneath, they run on... Kubernetes.

The Bottom Line

Here's the answer to what exactly is kubernetes used for that I wish someone had given me in 2018.

Kubernetes is used for running distributed systems at scale. It's a platform for other platforms. It's the operating system for your data center.

But it's not magic. It doesn't make your application scalable — it just makes it possible to scale without rewriting everything. It doesn't fix bad architecture — it amplifies it. And it doesn't simplify your infrastructure — it centralizes the complexity.

The teams that succeed with Kubernetes are the ones that:

Honestly assess whether they need it
Invest in operations tooling from day one
Treat the cluster as a product, not a project
Hire or train for SRE skills

The teams that fail are the ones that treat it as "just another deployment tool" and expect it to fix organizational problems.

At SIVARO, Kubernetes is part of our DNA. We've built data infrastructure on it that handles 200K events per second. But we also maintain a separate system for clients that don't need Kubernetes. We run a simpler, cheaper setup for apps that fit in a single VM.

Your job isn't to adopt Kubernetes. Your job is to solve your actual problem. If that problem is "we have 30 microservices and they keep breaking during deployment," Kubernetes might be your answer. If it's "we want to deploy a single API server," use a $5 VPS and get on with your life.

The technology doesn't care. But your team's velocity does.

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