What Does Kubernetes Actually Do?

Let me tell you a story. At SIVARO, we were building a real-time data pipeline for a financial services client in 2021. We had five microservices, a Kafka cluster, and a PostgreSQL database. We deployed on bare metal, the way I'd done it since 2015. It worked. Then the client said: "We need to handle 10x the traffic next quarter."

I spent two weeks rewriting deployment scripts. My team spent another week fixing the inevitable config drift. By the time we shipped, the traffic spike had already happened. We'd lost the deal.

That's when I understood what Kubernetes actually does — and more importantly, what it doesn't. Kubernetes is an orchestration platform that automates deployment, scaling, and management of containerized applications. But that definition hides more than it reveals. So let's cut through the marketing.

Hundreds of engineers ask me: "what does kubernetes actually do?" Here's my answer.

The Three Core Jobs (That Matter)

Kubernetes does three things that matter in production. Everything else is noise.

1. It Keeps Your Stuff Running

You define a desired state — "run 3 instances of my API server, each with 2GB RAM, listening on port 8080." Kubernetes checks reality against that state. If an instance crashes, it starts a new one. If a node fails, it reschedules the pods elsewhere.

This is the killer feature. Before Kubernetes, I had custom scripts that checked process health with ps aux | grep my-app and sent angry emails. Kubernetes does this right, continuously, at scale.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: sivaro/api:v2.1.0
        resources:
          requests:
            memory: "2Gi"
            cpu: "500m"
        ports:
        - containerPort: 8080

2. It Handles Service Discovery and Networking

Every pod gets its own IP. But pods come and go. Kubernetes gives you Services — stable endpoints that route traffic to the right pods, regardless of where they're running. It also does load balancing, DNS resolution, and can expose services to the internet.

This sounds boring. It's not. At SIVARO, we had a client who spent 3 months building a custom service mesh. Kubernetes solved the same problem in a day. Google Cloud's docs explain this well: abstracting the network is one of Kubernetes' biggest value-adds.

3. It Decouples Your App from Your Infrastructure

You write Kubernetes manifests once. They work on your laptop (via Minikube), in staging (on-prem), and in production (AWS, GCP, Azure). This portability isn't just theoretical — we moved a client's entire stack from on-prem to AWS in 8 hours. No code changes. Just new kubeconfig files.

The official Kubernetes overview calls this "container-centric management." I call it "not rewriting your deployment scripts when you switch clouds."

What Kubernetes Is NOT

Let me kill some myths, because I see these every week.

Kubernetes is not CI/CD. People ask "is kubernetes ci or cd?" It's neither. Kubernetes is a runtime environment. You can plug in CI/CD tools (ArgoCD, Flux, Jenkins, GitHub Actions), but Kubernetes itself doesn't build, test, or deploy your code. It runs what you give it. Red Hat's explanation is clear: Kubernetes orchestrates containers, not pipelines.

Kubernetes is not a silver bullet. If you have one app running on one server, Kubernetes adds complexity for zero benefit. I've seen startups spin up 5-node clusters for a Rails monolith that runs fine on a $20 VPS. That's not engineering — that's resume padding. The Hacker News thread "I Didn't Need Kubernetes" is full of people who learned this the hard way.

Kubernetes is not simple. Anyone who tells you otherwise sells Kubernetes consulting. The learning curve is steep. Networking, storage, RBAC, secrets management — each of these is a mini-education. The Kubernetes Haters Guide lists 17 valid pain points, and I've hit 14 of them.

So "What Exactly Is Kubernetes Used For?"

Real answers from real production systems:

Stateless web services. APIs, web apps, frontends. Kubernetes handles scaling (up and down based on CPU or custom metrics), rolling updates (zero-downtime deploys), and canary deployments.

Data processing pipelines. At SIVARO, we run Spark jobs on Kubernetes. Dynamic resource allocation means we don't pay for idle clusters. Batch jobs, stream processing, ETL — Kubernetes schedules them efficiently.

Microservices. This is the poster child. Kubernetes gives each service its own lifecycle, scaling policy, and resource limits. But be warned: Ona Engineering left Kubernetes partly because the complexity of managing 37 microservices outweighed the benefits.

Development and test environments. Spin up full-stack environments on demand, tear them down when done. We give each developer their own namespace. Isolation without infrastructure overhead.

Machine learning workloads. Training jobs, model serving, hyperparameter tuning. Kubernetes handles GPU scheduling and resource contention better than most homegrown solutions.

What Kubernetes is NOT used for (despite what vendors claim): databases (run them on dedicated hardware if you value your data), single large applications with no scaling needs (just use docker-compose), or anything that runs fine on 3 servers.

The Infrastructure Abstraction Layer

Think of Kubernetes as an operating system for your data center. Just as Linux abstracts hardware (CPU, memory, disk) from your application, Kubernetes abstracts servers, networks, and storage.

Here's what that means in practice:

bash
# Without Kubernetes: SSH into a server, update config, restart
ssh user@192.168.1.100
sudo systemctl stop myapp
# ... update config files ...
sudo systemctl start myapp

# With Kubernetes: edit the manifest, apply it
kubectl apply -f deployment.yaml
# Kubernetes handles the rest

The difference isn't convenience — it's repeatability. Every kubectl apply gives you the same result. Every SSH session is a snowflake that melts when the server reboots.

When Should You Use Kubernetes? (Honest Version)

Use it when:

You have 3+ services that need to talk to each other
You're deploying multiple times per week
You need to scale services independently
You're running on multiple clouds or moving between them
You have a team that can dedicate time to learning and maintaining it

Don't use it when:

You have one app with one deployment target
Your team is 3 people and nobody knows YAML
You're running 2 servers and they're not even busy
You think Kubernetes will fix your architecture problems (it won't — it just makes them more visible)

The YouTube video "Do You Actually NEED Kubernetes?" puts it bluntly: if you can't explain why you need Kubernetes without mentioning "scalability" or "orchestration," you probably don't need it.

The Real Cost of Kubernetes (That Nobody Talks About)

Everyone talks about the benefits. Let me talk about the costs.

Cognitive load. Kubernetes has ~50 objects. Each has options. The combination space is infinite. Learning Kubernetes is like learning a new programming language, except the grammar changes every 6 months.

Operational complexity.

yaml
# This looks simple. It's not.
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: MyApp
  ports:
    - name: http
      port: 80
      targetPort: 8080

That LoadBalancer costs you $15-30/month on AWS or GCP. The Ingress controller needs its own configuration. The network policies need testing. The DNS integration needs debugging. Each of these is a separate skill.

Debugging difficulty. When something breaks in Kubernetes, the stack trace spans 5 layers: container runtime -> kubelet -> control plane -> cloud provider -> your app. Good luck.

A Reddit thread on why people use Kubernetes nails it: the main reason is standardization across teams. But standardization comes at a cost — you're standardizing on a system that's complex to operate.

Why People Are Moving Away from Kubernetes

I hear this question constantly: "why are people moving away from kubernetes?" The answer isn't simple.

Some are moving to simpler platforms. Ona Engineering's post explains they switched to a simpler container platform (Fly.io) because their scale didn't justify Kubernetes complexity. This is smart engineering — not a condemnation of Kubernetes.

Some are moving to serverless. AWS Fargate, Google Cloud Run, Azure Container Apps — these give you the benefits of Kubernetes (auto-scaling, self-healing, traffic management) without the operational burden. At SIVARO, we run some workloads on Cloud Run. The tradeoff? Less control, higher per-unit cost, vendor lock-in.

Some are moving to Nomad. HashiCorp's orchestrator is simpler to operate and configure. It doesn't have the ecosystem depth, but for 90%% of use cases, it's enough.

The pattern is clear: Kubernetes is becoming infrastructure for infrastructure. The platforms built on top of Kubernetes (OpenShift, Rancher, EKS, GKE, AKS) are where the value lives. Raw Kubernetes is for platform teams, not application developers.

Practical Kubernetes: What We Actually Do at SIVARO

Let me show you real patterns we use in production.

Resource management is non-negotiable.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: data-processor
spec:
  template:
    spec:
      containers:
      - name: processor
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"

Without requests and limits, a memory leak in one pod can kill your node. We learned this the hard way — a 3AM pager, a dead cluster, and a very angry CTO.

Health checks matter more than you think.

yaml
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10

Readiness probes tell Kubernetes when to send traffic. Liveness probes tell it when to restart. Most outages I've seen in Kubernetes environments were caused by misconfigured probes — either too aggressive (killing pods during startup) or missing entirely (serving traffic to dead pods).

Use Helm. Or Kustomize. Pick one and standardize.

yaml
# Helm values.yaml
replicaCount: 3
image:
  repository: sivaro/api
  tag: v2.1.0
service:
  port: 8080
resources:
  limits:
    cpu: 1
    memory: 1Gi

Templating isn't optional at scale. Raw YAML doesn't compose well. We use Helm with strict values validation. It's not perfect, but it's predictable.

The Kubernetes Ecosystem: What Actually Works

Persistence:

StatefulSets for stateful apps (databases, queues)
PersistentVolumeClaims for storage
StorageClasses to abstract different storage backends
Warning: Running PostgreSQL on Kubernetes is possible but painful. We run it on RDS. The operational overhead of self-managed databases on Kubernetes exceeds the benefits 9 times out of 10.

Networking:

Services (ClusterIP, NodePort, LoadBalancer)
Ingress (nginx-ingress, Traefik, HAProxy)
Network Policies for security
Service Mesh (Istio, Linkerd) — only when you need mTLS, traffic splitting, or deep observability

Observability:

Metrics: Prometheus + Grafana (standard stack, works well)
Logging: Fluentd/Fluentbit -> Elasticsearch/Loki
Tracing: Jaeger or Tempo
Don't build your own — use managed services when possible

The Future: Kubernetes as a Platform Layer

Kubernetes won. It's the Linux of the cloud era. But just as most developers don't interact with the Linux kernel directly, most developers won't interact with Kubernetes directly.

The future is higher-level abstractions. Platforms built on Kubernetes that hide the complexity:

Platform Engineering teams building internal developer platforms
PaaS offerings (Cloud Run, Heroku-style on Kubernetes)
Serverless Kubernetes (Knative, OpenFaaS)
Application abstractions (Kubernete operators for domain-specific needs)

At SIVARO, we're building a data infrastructure platform on Kubernetes. We don't expose pods, deployments, or services to our users. They see pipelines, streams, and datasets. Kubernetes handles the messy parts.

Should You Learn Kubernetes?

Yes, if:

You're building distributed systems
You work on platform or infrastructure teams
You want to understand how modern cloud infrastructure works

No, if:

You just want to deploy a web app
You're a frontend developer who hates YAML
Your entire backend runs on one server

Red Hat's definition is technically correct — "Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services." But the real answer to "what does kubernetes actually do" is: it gives you a standard way to run software in production, at the cost of learning a complex new system.

Make that tradeoff consciously. Don't adopt Kubernetes because it's trendy. Adopt it because your problems match its solutions. And if they don't? Run your app on a $5 VPS and sleep better.

FAQ

Is Kubernetes CI/CD?
No. Kubernetes is a runtime environment for containers. CI/CD pipelines (build, test, deploy) are separate tools that can integrate with Kubernetes. Common patterns: GitOps with ArgoCD, or pipeline triggers that call kubectl apply.

Do I need Kubernetes for microservices?
Not necessarily. You can run microservices with docker-compose, Nomad, or even SSH scripts. Kubernetes helps when you have 10+ services, need independent scaling, or want self-healing.

How much does Kubernetes cost?
The software is free. The operational cost is in infrastructure (control plane nodes, worker nodes, network costs for cloud load balancers) and people (learning curve, debugging time, maintenance). Budget for the latter — it's the larger cost.

Should I use managed Kubernetes (EKS, GKE, AKS) or self-hosted?
Managed, always. Self-hosting Kubernetes is a full-time job plus a crew. Even the hyperscalers struggle to keep their control planes stable.

Can Kubernetes run databases?
Yes, but carefully. StatefulSets handle stateful workloads, but databases on Kubernetes face challenges with storage performance, backup consistency, and failover complexity. Most teams run stateful services outside Kubernetes and connect them via DNS.

What's the minimum viable Kubernetes setup?
A 3-node cluster (1 control plane, 2 workers) for dev/test. Production needs 3 control plane nodes (for quorum) and at least 3 worker nodes. Below this, you're paying complexity tax without reliability benefits.

Why do teams leave Kubernetes?
Two main reasons: their scale doesn't justify the complexity (Ona Engineering's case), or they build abstractions on top of Kubernetes that obscure the need for Kubernetes itself. The second reason is ironic — Kubernetes enabling its own departure.

What should I learn before Kubernetes?
Docker, Linux basics, networking fundamentals (DNS, TCP, load balancing), and YAML. Without these, Kubernetes will feel like throwing knives in the dark.

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