Unlearning VMs: One Infrastructure Guy's Kubernetes Journey

I passed the Nutanix Certified Professional - Cloud Native exam this past week. But that test wasn't a finish line. It's the starting point of what I'm treating as a yearlong journey. Getting here meant many hours deep in my lab, building and rebuilding clusters, deploying NKP over and over until the pieces finally clicked. Ten years as a Nutanix Technology Champion, countless infrastructure projects, more clusters than I can count, and I still walked into that exam feeling like a beginner again.

That was the point.

Why Now

Part of this was practical: Nutanix requires the NCP-CN certification for our partnership level at eGroup. But that requirement aligned perfectly with my 2026 goals.

NKP (Nutanix Kubernetes Platform) isn't a side project. It's an evolution from the NKE platform, with Nutanix focusing even more on bridging the cloud native difficulties organizations face, both locally and across different clouds. It's foundational to where the platform is headed, especially with Enterprise AI workloads coming into focus. I've spent my career helping customers modernize infrastructure. I can't do that credibly if I'm watching Kubernetes from the sidelines.

So I stopped watching and started learning.

The Mental Model Problem

Here's what nobody tells you when you come from a virtualization background: the hard part isn't the technology. It's the thinking.

I've spent years building infrastructure that's meant to be persistent. VMs that run for months or years. Carefully planned migrations. Change management windows. The whole discipline is about stability and predictability.

Kubernetes doesn't care about any of that.

Pods are ephemeral by design. They get killed and recreated constantly. The system assumes failure and routes around it. You don't SSH into a container to fix something. You delete it and let the platform spin up a fresh one.

And then there's the twist: persistent volume claims (PVCs) let you attach storage that survives pod restarts. So containers are ephemeral, except when they're not. Confusing? Sure. But it's starting to make sense. The ephemerality is the default, and persistence is something you explicitly opt into when the workload demands it.

This goes against every instinct I've developed. When something breaks, I want to troubleshoot it, not throw it away. But that's exactly the muscle memory I need to unlearn.

What's Starting to Click

Not everything feels foreign. One thing working in my favor is a comfort level with Linux and command line operations. I was fortunate early in my career to be exposed to a wide variety of Unix platforms, and that foundation still pays dividends. Kubernetes lives in the CLI. kubectl, helm, and the endless YAML files all feel more approachable when you're not also fighting the terminal itself.

A few other concepts are beginning to make sense when I map them to what I already know:

Declarative vs. Imperative: Instead of clicking through wizards or running scripts that do things step-by-step, you describe the end state you want and let Kubernetes figure out how to get there. It's like the difference between giving someone turn-by-turn directions versus just telling them the destination.

Namespaces as Boundaries: Think of these like resource pools or folders, but with teeth. They provide actual isolation, not just organization.

Services and Networking: This is where my brain still hurts. The abstraction layer between pods and how traffic actually reaches them is elegant once you see it, but getting there took some staring at diagrams.

Making It Real

Studying for a cert only gets you so far. I learn by building things that break.

But here's where I'm stuck: traditional infrastructure follows a "build it and they will come" model. You stand up your hypervisor, you deploy your platform, and applications eventually land on it. The infrastructure exists first, and workloads follow.

Kubernetes feels like the opposite. The containers are already here. The applications exist. Now you need to build the thing that runs them. It's not "build it and they will come." It's "they're here, now build it to meet them."

That inversion is messing with my head. In the traditional infrastructure world, I could spin up a cluster and learn by exploring the platform itself. With Kubernetes, I feel like I need a workload to chase, something to deploy, before the platform makes sense. The infrastructure doesn't exist in isolation the same way.

I'm still figuring out what that workload looks like for me. Something with enough complexity to force real learning, but not so ambitious that I stall out.

I have to give credit where it's due. The Nutanix documentation for NKP is outstanding and served as my primary reference throughout the certification process. I also want to call out fellow NTC Jonas Högman, whose NKP blog series was invaluable in getting my own environment up and running. Having someone walk through the practical setup details made a real difference.

What's Still Fuzzy

I'm not going to pretend I've got this figured out. A few things that still feel foreign:

• Helm charts: I understand the concept (package management for K8s), but writing them from scratch feels like learning a new language on top of an already new language.
• Persistent storage: The irony isn't lost on me. I come from a world where storage is everything, and now I'm in a world where statelessness is the goal. Figuring out when and how to use persistent volumes is still a work in progress.
• Troubleshooting: My instincts are all wrong. I want to dig into logs and fix things in place. I'm slowly learning to think in terms of events, describe states, and let the platform do its job.

The Road Ahead

This is the beginning, not the destination. NKP is the foundation, but the real goal is understanding how Kubernetes enables the next wave of workloads, particularly what Nutanix is building with Enterprise AI.

You can't run GPU-accelerated inference workloads, model serving, or AI pipelines without a solid grasp of container orchestration. The infrastructure layer I've spent years mastering is still there, but it's becoming the floor, not the ceiling.

For those of you in similar positions, infrastructure veterans watching the Kubernetes wave and wondering if it's time to jump in, my advice is simple: stop wondering. The learning curve is real, but so is the relevance. Get certified, build something small, break it, fix it, repeat.

I'll share more as I go. Not as an expert, just as someone figuring it out in real time. I can't wait to dive deeper into not only Kubernetes, but NKP, Nutanix Enterprise AI, and wherever this journey takes me this year.

Have thoughts or going through a similar journey? I'd love to hear from you. Connect with me on LinkedIn or drop me a note at mike@mikedent.io.