Why NKP Feels Different When You Run It as an MSP

Nutanix Kubernetes Platform works well when the same team owns both the platform and the applications running on top of it.

In most enterprise deployments, the organization that operates Kubernetes is also responsible for the workloads. Upgrade decisions are internal, trade-offs are explicit, and accountability is clear.

This assumption breaks down as soon as NKP is operated as a managed service.

As an MSP, you are responsible for the platform lifecycle, but you do not control the application lifecycle of your customers. You inherit software you did not design, vendors you do not choose, and certification constraints you cannot negotiate. At the same time, you are still expected to keep the platform secure, supported, and compliant.

The same dynamic appears inside large enterprises.

Platform teams often operate Kubernetes as an internal service, while business units or application teams behave like independent tenants. Each BU has its own roadmap, vendors, and priorities, and none of them align perfectly with platform upgrade cycles.

From a lifecycle perspective, the problem is identical. Control and responsibility are split across organizational boundaries.

This is where Kubernetes lifecycle management turns into a customer management problem.

The promise of workspaces and projects

NKP offers a solid multi-tenancy model based on workspaces and projects.

Workspaces provide tenant isolation, identity separation, and clear RBAC boundaries.
Projects allow further segmentation of access, configuration, and application deployment.

From an access control and governance perspective, this model works well. You can safely host multiple customers on the same platform while keeping visibility and control centralized.

What workspaces do not provide is lifecycle isolation.

The Kubernetes version is still a property of the cluster. Every tenant attached to that cluster is implicitly tied to the same upgrade cadence, regardless of their individual readiness.

Where MSP reality diverges from the enterprise model

In an MSP context, upgrades are rarely blocked by the platform itself.

They are blocked by customers.

Some customers run actively maintained applications. Others run software that is barely touched after go-live. Some vendors certify their products quickly. Others lag behind upstream Kubernetes for months.

With NKP, the N-1 support model means that you can only retain a single previous Kubernetes version during an upgrade cycle. Skipping more than one release is not supported.

Operationally, this has a very concrete effect.

If a customer is not ready to move when the platform needs to move, the upgrade stops. In practice, one tenant can block the platform lifecycle for all the others.

Security fixes, platform improvements, and even supportability are delayed for everyone.

At scale, this becomes unmanageable. Proliferating clusters to work around lifecycle conflicts quickly shifts the problem from governance to cost and operational overhead.

Why this feels different compared to Public Cloud

This is the comparison customers often make, implicitly or explicitly.

In managed Kubernetes services provided by hyperscalers, older Kubernetes versions are tolerated for longer periods. Customers are given deprecation timelines, warnings, and clear end-of-support dates. Eventually, the version becomes unsupported, but the upgrade is not immediately forced.

It is not unusual to see workloads running three Kubernetes versions behind the latest release, while still being formally supported for a defined period.

This model works because the provider controls the entire platform and absorbs the operational complexity.

As an MSP running NKP, you do not have that leverage.

You are not offering Kubernetes as a global service with infinite scale and standardized SLAs. You are offering a managed platform where lifecycle decisions have a direct operational impact on your team.

Trying to replicate hyperscaler behavior without hyperscaler control leads to friction and unrealistic expectations.

The real problem is not versioning, it is responsibility

The core issue is not that NKP enforces an N-1 support model.

The issue is that N-1 assumes aligned responsibility.

When customers expect to keep applications on older Kubernetes versions indefinitely, while the MSP is expected to keep the platform secure and supported, responsibility is misaligned.

From an operational standpoint, this creates constant negotiation.

Every upgrade becomes a discussion.
Every security advisory becomes a risk assessment call.
Every exception adds long-term operational debt.

Why workspaces are not enough for lifecycle management

Workspaces isolate access. They do not isolate time.

They cannot allow one customer to remain on an older Kubernetes version while others move forward on the same cluster. They cannot decouple platform lifecycle from workload lifecycle.

This is not a limitation of implementation. It is a design choice.

NKP assumes that platform and workloads evolve together. That assumption is valid in enterprise environments. It is fragile in MSP and multi-BU environments.

The only sustainable approach today is contractual

Given the current platform model, the solution cannot be purely technical.

It must be operational and contractual.

Kubernetes lifecycle management has to be explicitly defined as part of the managed service. Customers must be informed that platform upgrades are continuous, scheduled, and mandatory within defined time windows.

A practical model looks like this.

• Kubernetes upgrades are performed regularly by the MSP
• Customers are notified in advance with clear timelines
• Compatibility testing is the customer’s responsibility
• Failure to upgrade within the agreed window results in loss of support

This approach does not force upgrades arbitrarily. It formalizes them.

It aligns responsibility with control.

Once this boundary is explicit, the platform becomes manageable again. Without it, even a well-designed Kubernetes platform turns into a source of constant operational tension.

Closing thoughts

NKP is a strong platform, but it reflects an enterprise-centric lifecycle model.

When you run it as an MSP, or as an internal platform shared across autonomous business units, the hard part is not multi-tenancy. It is managing expectations around change.

Workspaces solve isolation.
They do not solve lifecycle autonomy.

Until that gap is addressed at a platform level, the only viable place to solve it is at the contract boundary.