You Don’t Need More Nodes, You Need Two NKP Instances

I often find that when we talk about Kubernetes management, we think in terms of scaling up, not scaling smart.
This article comes from real experience designing NKP environments that need to balance cost, performance, and flexibility.

The reality of running Kubernetes everywhere

In theory, Kubernetes is meant to run anywhere, from enterprise-grade datacenters to small development labs or edge clusters.
In practice, however, not every Kubernetes platform is designed to operate efficiently across that entire range.

Nutanix Kubernetes Platform (NKP) provides different editions to address these needs. The Ultimate edition delivers full enterprise capabilities such as advanced governance, lifecycle automation, multi-cluster management, and security integration.
The Starter edition, on the other hand, is a lightweight variant intended for development, testing, or edge use cases.

On paper, it may seem logical to deploy a single Ultimate installation and manage everything from there. But once you start sizing real clusters, it becomes clear that this is rarely practical. In many scenarios, maintaining two NKP management instances can be the most effective way to balance functionality, resources, and usability.

Ultimate vs Starter: key differences

Before diving deeper, it helps to understand what really separates the two editions.
Both share the same Kubernetes foundation, but they target different operational needs and scales.

NKP Starter

NKP Ultimate

This separation makes it clear how each edition fits into different parts of your infrastructure strategy.
Ultimate focuses on scale, compliance, and governance, while Starter delivers agility and resource efficiency.
Together, they enable consistent Kubernetes management across environments of any size.

Minimum resource requirements

The difference between Starter and Ultimate becomes even clearer when you look at the actual hardware requirements.
While both editions share the same Kubernetes foundation, their minimum footprints are drastically different.

NKP Starter (Minimum Configuration)

Management Cluster

Workload Cluster

NKP Starter can run with a single control plane node, making it ideal for labs or compact deployments.
This drastically reduces CPU and memory usage, lowering the infrastructure cost of Kubernetes management.

NKP Ultimate (Minimum Configuration)

Management Cluster

Workload Cluster

NKP Ultimate requires a minimum of seven nodes just for the management plane.
In environments with limited compute capacity, this footprint can quickly become excessive.

These numbers explain why maintaining a single Ultimate installation across all environments is rarely sustainable. Starter allows teams to deploy Kubernetes efficiently even on small clusters, while Ultimate provides the resilience and governance needed for large-scale production.

Understanding the Ultimate edition requirements

The Ultimate edition has strict minimum resource requirements designed to ensure reliability and availability in production.
To function properly, it requires at least three control plane nodes, four worker nodes, and dedicated infrastructure sized for performance and redundancy.

This means that before you deploy any tenant cluster, the management plane itself already consumes significant compute and storage resources.
When this pattern is repeated across multiple environments such as production, pre-production, and development, the overhead grows quickly.

If your goal is to standardize Kubernetes across all environments, including test and sandbox clusters, the Ultimate footprint can become excessive. It is simply too large for smaller or experimental setups, leading to unnecessary consumption of CPU, memory, and storage.

Where Starter makes sense

The Starter edition provides a more flexible and efficient approach for non-production environments.
It allows you to run the NKP management plane with a single control plane node and a minimal number of workers, making it ideal when resources are limited or cost optimization is a priority.

Starter is particularly valuable in development environments, where using seven nodes (three control planes and four workers) would be unnecessarily expensive and complex for small projects.
It’s also ideal for testing and staging clusters, where uptime and redundancy are not critical but fast deployment and low overhead are.

In training, demos, or proof-of-concept environments, Starter enables quick provisioning and teardown of clusters, reducing operational friction.
And in edge or remote sites, where hardware resources are scarce and simplicity is essential, it brings consistency without the weight of full enterprise features.

One of its main advantages is that Starter does not require a paid NCI (Nutanix Cloud Infrastructure) license, making it cost-effective to deploy in smaller environments.
It provides the same Kubernetes experience and API consistency as Ultimate, but with a much lighter operational footprint.

By pairing Ultimate and Starter, you create a structure that adapts to both large-scale production workloads and compact development setups. This approach ensures standardization where it matters, without forcing heavy infrastructure where it is not needed.

A pragmatic dual-installation model

Consider a common scenario.
Your NKP Ultimate instance is deployed in the production datacenter and manages all mission-critical clusters. It integrates with corporate IAM, enterprise storage, monitoring, and backup. It’s the authoritative control plane for workloads that must meet performance and compliance requirements.

Your NKP Starter instance, instead, runs in a smaller or isolated environment. It is used to test new operators, validate ClusterClass templates, or simulate upgrades before rolling them out in production. In some cases, it can even host training clusters for internal teams, lightweight production workloads at the edge, or proof-of-concept environments for customers.

This separation provides flexibility without compromising security. Each environment has a clear purpose and operates within the limits of its own resource budget.

Operational benefits

Resource optimization
Avoid oversizing development or edge environments just to satisfy Ultimate’s high availability model. Starter keeps infrastructure lean and efficient.

Faster experimentation
Developers can iterate quickly, creating and deleting clusters without waiting for a large management plane to stabilize. This accelerates feedback cycles and simplifies automation testing.

Production stability
By isolating experimental changes in the Starter instance, you prevent configuration drift or accidental disruptions in production.

Safer upgrades
New NKP versions can first be tested on Starter, then replicated on Ultimate once validated.

Flexible licensing
Starter avoids additional licensing costs while Ultimate supports enterprise entitlements through NCI.

Bridging the gap between Starter and Ultimate

Although the two installations are separate, they can be connected in several ways to maintain a consistent operational model.

Both instances can integrate with the same OIDC provider (for example Microsoft Entra ID or LDAP), ensuring consistent user roles and RBAC policies. Using GitOps, they can also share configuration repositories, pulling cluster definitions and manifests from the same version-controlled source.
Metrics and logs from Starter-managed clusters can be sent to the same Prometheus or Loki backend used by the production environment.

This approach allows teams to treat Starter as a testing ground or a lightweight production control plane, mirroring the operational model used in Ultimate.

Design considerations

When implementing a dual NKP model, consistency is key.
Define clear environment boundaries and automate configuration promotion with GitOps or Terraform pipelines. Even if Starter is lightweight, it should still be monitored and managed.
Applying consistent naming conventions, namespaces, and resource labels across both environments makes promotion between them predictable and clean.

Treat the Starter instance as a managed environment, not as a disposable sandbox. This ensures predictability and continuity across the cluster lifecycle.

Why one size does not fit all

A single NKP edition cannot efficiently serve every purpose.
Ultimate is built for enterprise workloads that require governance, scalability, and resilience.
Starter, instead, is a complementary edition that brings flexibility and agility to smaller environments.

Used together, they form a balanced strategy. Starter can run lightweight production workloads, while Ultimate provides a full-scale, compliant platform for critical systems.

This dual-installation approach reflects a mature understanding of real-world infrastructure. It balances the ideal goal of standardization with the practical realities of cost, performance, and scale.

Final thoughts

Modern infrastructure design is about adaptability.
Balancing the need for stability in production with the need for flexibility in development is what enables efficient, scalable operations.

Running both NKP Ultimate and NKP Starter provides the best of both worlds.
Ultimate ensures compliance, governance, and high availability for production.
Starter supports experimentation, edge use cases, and lightweight production clusters without wasting resources.

I believe the best architectures are the ones that stay simple where they can, and powerful where they must.
That’s exactly what this dual NKP setup achieves.