Running Kubernetes in Nepal: What Nobody Warned Me About

Every Kubernetes tutorial assumes a world that does not match mine. Stable power. Fast, reliable internet. Cloud budgets measured in a currency that does not lose value if you blink. I run Kubernetes from Nepal, and the gap between the tutorial world and my world taught me more about resilience than any certification would.

Power cuts during cluster maintenance

Picture this. You are in the middle of a cluster operation, a node drain, a careful rolling update, the kind of thing where you want full attention and a stable environment. And the power goes out. Not a graceful shutdown. A hard cut. Load shedding has improved over the years in Nepal, but it is not gone, and it does not check your maintenance window before it hits.

Kubernetes is designed to survive nodes dying. It is less prepared for the operator's laptop dying mid-command because the city lost power.

I learned to never run a critical cluster operation without a charged laptop and a backup power plan. Sounds obvious until you have lost a session halfway through a delicate operation and had to reason about what state the cluster was left in while the lights were off.

Internet that drops mid-deploy

The second one. Internet here can drop without warning, sometimes for seconds, sometimes for longer. Now imagine that happening during a deploy, while you are streaming logs, watching a rollout, waiting on a health check. Your connection to the cluster vanishes and you do not know if the operation completed, half-completed, or never started.

This forced good habits on me that engineers with reliable connections never develop. I design operations to be idempotent and resumable. I never assume my session will survive. I check state explicitly rather than trusting that what I saw before the drop is still true. The flaky internet made me a more careful operator, the way scarcity always seems to teach the lessons abundance skips.

The cost of cloud in rupees

This is the quiet, constant pressure. Cloud is priced in dollars. I earn and budget in rupees. Every running node, every load balancer, every gigabyte, is a dollar cost that feels heavier when you convert it. The casual over-provisioning that engineers elsewhere do without thinking, just spin up more, is not casual here. It is a real decision with a real weight.

• I right-size relentlessly because every idle resource is money I can feel.
• I shut down what does not need to run, instead of leaving it on out of laziness.
• I think hard about managed versus self-hosted, because the convenience premium of managed services adds up fast in a weaker currency.

Why I still chose Kubernetes anyway

With all this friction, a fair question is why not pick something simpler. And I considered it. For some projects, simpler is the right call and I use it. But for the multi-tenant SaaS I lead, Kubernetes earned its place. The self-healing, the rolling updates, the declarative state that I can reason about and recover toward, those are exactly the properties you want in an environment that is constantly trying to knock you over.

The same chaos that makes Kubernetes harder to operate here is the chaos that makes its resilience features genuinely valuable. In a perfectly stable environment, a lot of Kubernetes is insurance you rarely claim. In my environment, I claim it. The cluster reschedules around a dead node, recovers toward its declared state, and keeps serving while I deal with whatever the city threw at me this time.

The lesson under the lesson

Running Kubernetes in Nepal taught me that the constraints are not just obstacles. They are a filter that forces you to actually understand your tools instead of cargo-culting a tutorial. I know my cluster more deeply than I would if everything just worked, because here, nothing just works, and understanding is the only thing that keeps it running.