Kubernetes: What is it, When to use it, and why?

Kubernetes feels like one of those tools people prescribe like it's a vitamin. "You should really be taking K8s." Cool. For what problem? If you don't actually have that problem, Kubernetes will hand you a pile of new ones on top of your old ones.

I like Kubernetes. I also like chainsaws. Same deal: use it for trees, not bagels.

What Kubernetes actually is

Kubernetes is a container scheduler. You give it containers and machines (nodes), and it figures out where things run. Then it keeps doing that job while the world is on fire.

Day‑to‑day, that looks like:

• Scheduling containers onto nodes based on CPU, RAM, and the rules you set.
• Restarting containers that crash, assuming your app can restart without falling apart.
• Scaling workloads up and down, either manually or with autoscalers.
• Routing traffic to the right place using service discovery and load balancing.
• Rolling out updates without you SSH'ing into boxes like it's 2009.

If you've only ever run a couple containers on a single VM, Kubernetes can feel like showing up to a lemonade stand with a forklift.

The stack of abstractions

Kubernetes runs containers, but it wraps them in a pile of objects first. These are the ones you'll trip over early:

• Pod: the smallest unit. Usually one container, sometimes a few that have to live together.
• Deployment: "keep N copies of this pod running, and update it safely."
• Service: stable networking for a set of pods. Pods come and go; the Service sticks around.
• Ingress: HTTP routing into the cluster, typically paired with an Ingress Controller.
• ConfigMap / Secret: configuration and sensitive config, with all the usual caveats.
• Namespace: a way to partition a cluster, and also a way to confuse yourself later.

Each abstraction solves a real problem. The cost is that debugging now means asking: "Is this a code problem, a container problem, a networking problem, or a YAML problem?"

Spoiler: it's usually YAML.

When Kubernetes makes sense

Kubernetes earns its keep when you have real operational complexity:

• Dozens of services that need consistent, repeatable deployment patterns.
• High‑availability requirements across multiple nodes or availability zones.
• Multiple teams shipping features independently, without stepping on each other's toes.
• Spiky traffic where autoscaling actually saves you money instead of hot‑wiring.
• Someone who can actually own the platform (even if it's one tired person).

I've done consulting where my job was "make the software work" while the company was busy setting money on fire in creative ways. In that kind of chaos, Kubernetes can be a relief. Deploys are repeatable, rollouts are predictable, and a bad change has a fence around its blast radius.

When Kubernetes is overkill

If you have:

• One small SaaS.
• One API and one worker.
• A side project you actually want to finish within the same year.

…then Kubernetes is too much.

You'll spend time learning cluster networking, ingress behavior, storage classes, RBAC, and why your pods are stuck in CrashLoopBackOff because your health check is wrong by one character. Meanwhile, your users just want the login page to load.

For small setups, you can get most of the benefits with managed platforms:

• Cloud Run – simple, scales nicely, and you mostly don't touch infrastructure.
• Fly.io – good dev experience for a handful of small apps.
• ECS / Fargate – less ceremony than K8s, but still sits on AWS.
• Lightsail – cheap and boring, which is a compliment in this context.

Boring infrastructure is underrated. Boring ships products. Interesting ships incident reports.

AI makes Kubernetes easier and riskier

Yes, AI can write Kubernetes manifests. The dangerous part is speed. AI can spit out a full Deployment, Service, Ingress rules, and a Helm chart in two minutes. It can also produce a production outage in two minutes. Same speed, different outcome.

If you run Kubernetes in production, you still need to understand a few non‑negotiables.

Probes (how you lie to yourself)

• Liveness probe tells Kubernetes whether to restart the container.
• Readiness probe tells Kubernetes whether to send traffic to it.

Mix these up and you'll roll out an app that looks "healthy" while it's returning 500s, or "dead" while it's serving traffic perfectly. Kubernetes will be very confident either way.

Resource limits (how you get mystery failures)

If you don't set CPU and memory requests and limits, the scheduler guesses. Guessing is fun until your node is full and the kernel starts killing processes like it's playing whack‑a‑mole.

Failure modes (how you debug when shit hits the fan)

You should be comfortable with:

kubectl get pods
kubectl describe pod <name>
kubectl logs <name> --previous
kubectl get events --sort-by=.metadata.creationTimestamp

If those commands feel like magic incantations, you're not ready. I've watched people deploy to Kubernetes without knowing kubectl logs existed. Like driving a car without knowing where the brake pedal is. Works fine until it doesn't, and when it doesn't, it's spectacular.

Quick gut‑check table

The honest takeaway

Kubernetes is great if you're running a small city of services. If you're running a food truck, it's a weird choice.

Use it because you need to wrangle lots of services without losing your mind. Not because it's trendy. Kubernetes is useful, but it's not a personality trait.

-Sethers