🚢 I Thought Kubernetes Would Make Deployments Easier

It didn't. It made me better. That's not the same thing.

I still remember the confidence I had the day I decided to learn Kubernetes.

I was tired. Tired of fragile bash scripts that deployed to servers in a specific order that only I understood. Tired of "works on my machine" being an actual answer. Tired of deployment nights that turned into deployment mornings.

Someone told me: "Just use Kubernetes. It handles all of that."

So I did.

Week 1 — The Honeymoon

The docs looked clean. The architecture diagram made sense. Pods. Deployments. Services. Ingress. It was all logical. Elegant, even.

I wrote my first Deployment YAML. Applied it. The pod came up.

This is amazing, I thought. Why doesn't everyone use this?

I told my team. I told my friends. I may have told a stranger at a coffee shop.

I was going to automate everything. No more manual deployments. No more 2am hotfixes. Kubernetes was going to save us.

Week 3 — The First Crack

0/1 nodes are available: 
insufficient memory.

I stared at this message for 45 minutes.

My pod wouldn't schedule. The node had memory. I could see the memory. It was right there in kubectl describe node. But Kubernetes said no.

Turns out I had set resource requests higher than what was actually available after system processes took their share. Kubernetes wasn't being difficult. It was being exact. More exact than I was ready for.

I fixed it. But the confidence was slightly smaller now.

Week 5 — CrashLoopBackOff

NAME              READY   STATUS             RESTARTS   AGE
my-app-7d4f9b    0/1     CrashLoopBackOff   47         2h

47 restarts.

My app had been silently dying and restarting for two hours before I noticed. In the old world, the server would have been obviously down. Here, Kubernetes was heroically trying to resurrect something I had broken, hiding the failure behind optimistic retry logic.

I ran kubectl logs. Empty. I ran kubectl logs --previous. There it was. A startup error I had introduced three deploys ago that only manifested under specific environment variables I hadn't set.

The deployment had looked successful. The pod had looked healthy for a few seconds after each restart. Everything had looked fine until it very much wasn't.

Kubernetes didn't make deployments easier, I thought that evening. It made failures quieter.

Month 2 — The Networking Rabbit Hole

My services couldn't talk to each other.

The pods were running. The services existed. The YAML was correct — I had checked four times. But service A could not reach service B.

Three hours later I discovered I had been calling http://my-service from a pod in a different namespace. The correct address was http://my-service.other-namespace.svc.cluster.local.

A 56-character DNS name.

For two services sitting on the same physical machine.

I sat back and genuinely reconsidered my life choices.

Month 3 — The Incident

Production. 11pm. Everything down.

The deployment had worked perfectly in staging. Identical manifests. Same image. Same environment variables. But in production, under real load, the pods kept dying.

Exit code 137.

OOMKilled. My memory limits were too low for production traffic. I had set them based on staging load, which was approximately 3 users — me, testing, and me again pretending to be someone else.

I updated the limits. Redeployed. Things came back.

I wrote a postmortem at midnight that was mostly just the word "limits" repeated in different fonts.

Month 6 — Something Shifted

I don't know exactly when it happened.

But somewhere between the 15th CrashLoopBackOff and the 3rd networking issue I'd solved, something changed. Kubernetes stopped feeling like an obstacle and started feeling like a language I was slowly becoming fluent in.

The error messages that used to panic me started making sense. Insufficient memory meant check your requests. ImagePullBackOff meant check your registry auth or your tag. Pending meant look at your node selectors and taints. CrashLoopBackOff meant look at the previous logs, not the current ones.

I had built a mental model. And once I had the mental model, Kubernetes stopped fighting me.

The Truth Nobody Tells You

Kubernetes doesn't make deployments easier.

It makes deployments better. Those are completely different things.

Easier means less thinking. Better means more reliability, more observability, more control — but at the cost of upfront complexity that you have to earn your way through.

The bash scripts were easier. scp the file, restart the service, pray. Simple. Fragile. But simple.

Kubernetes asks you to think carefully about resources, health checks, networking, and failure modes before you deploy. It forces you to define what "healthy" means for your app. It makes you consider what happens when your pod dies and comes back on a different node.

That thinking is the work. Kubernetes just makes the thinking mandatory instead of optional.

What I Wish Someone Had Told Me

Start simpler than you think you need to. One node. One namespace. One app. Learn the primitives before you touch Helm, GitOps, service meshes, or anything else.

Read error messages completely. Kubernetes writes detailed, accurate error messages. The answer is almost always in the output — but in a different section than where you're looking.

Resource limits are not optional. Set them from day one. Profile your actual usage. Don't guess. Wrong limits in production is a 2am incident waiting for a calendar invite.

The previous logs are the real logs. When a pod is in CrashLoopBackOff, kubectl logs --previous is the command. Not kubectl logs. The previous one. Always.

Networking is hard on purpose. It's not a bug. It's a deliberate isolation model. Once you understand namespaces, DNS, and service selectors — it clicks and it never unclicks.

Where I Am Now

I run Kubernetes in production at work — GKE clusters, real traffic, real stakes. I run it at home on a 5-node k3s cluster built on Raspberry Pis that I've broken and rebuilt more times than I can count.

Every break taught me something. Every incident made the mental model sharper.

And deployments? They're not easier. But they haven't surprised me in a long time.

That's the real win.

If you're somewhere in the middle of the Kubernetes learning curve right now — the part where it feels harder than what you replaced — I promise that's not a sign you're doing it wrong.

That's just the part before it clicks.

Keep going.

— Satya 👨‍💻 Platform Engineer | Still occasionally surprised by Kubernetes | Writing at blog.rootbysatya.in

💬 Where are you on the Kubernetes journey? Week 1 honeymoon, Month 3 questioning everything, or the other side? Drop it in the comments. Follow RootBySatya for more honest takes on real infrastructure.