Open-source alternative to Nutanix Kubernetes Platform

Open-source alternative to Nutanix Kubernetes Platform: the short answer

If a Nutanix renewal now prices NKP per physical core or vCPU on worker nodes, the short answer is that upstream Kubernetes is Apache 2.0 licensed and can run on Harvester, Proxmox VE or bare metal, with no per-core license for the cluster software itself. The trade is clear: you give up the NKP license fee and the vendor's integrated lifecycle tooling, and you take on cluster upgrades, storage, backups, monitoring and support work in return. Nutanix's licensing page states that control plane nodes do not need NKP licenses, so the licensed footprint is the worker nodes. Confirm the exact count of worker nodes and vCPUs in your renewal quote before comparing it with your own staffing.

Whether this trade makes sense depends mostly on the hardware you already run. If the estate is on Nutanix hosts, Harvester is the closest fit because it is hyperconverged, built on Kubernetes and KubeVirt, and uses Longhorn for block storage on the same nodes. If you run Proxmox VE clusters, you can place a Kubernetes control plane and workers on VMs there and add your own storage and ingress. If you have neither, bare metal with kubeadm is the most direct route, but it puts the most operational work on your team. Ask your vendor and your own platform engineers which of these three paths your skills and hardware support.

Start with three checks before deciding. First, confirm the NKP licensing basis in your contract, including whether any worker nodes run on public cloud, where vCPUs are the unit. Second, check the Kubernetes version you need, because the project supports only its three most recent minor releases, so a cluster on an older version will need upgrades on a schedule you can keep. Third, decide who owns etcd backups, certificate rotation and Secrets encryption at rest, since those are your responsibilities once the vendor's platform is removed. Any cost comparison should count these recurring tasks alongside the one-time migration work.

Which NKP capabilities map to upstream Kubernetes components

This table maps the main NKP capability areas to upstream Kubernetes components and open-source add-ons, with coverage notes and gaps for each. Read the right-hand column first, because it shows where the reader must confirm what their own NKP entitlement includes before deciding what to replace. The main takeaway is that upstream Kubernetes covers the core runtime, but lifecycle tooling, storage, monitoring and management layers must be assembled and supported separately.

NKP capability area	Upstream open-source option	Coverage notes and gaps
Cluster lifecycle	kubeadm for create, join and upgrade; Cluster API for declarative management	kubeadm covers bootstrapping and HA topologies, but day-two tasks such as fleet upgrades and node replacement need your own runbooks or tooling. Confirm which lifecycle features your NKP license includes.
Control plane high availability	Stacked or external etcd with at least three control plane nodes behind a TCP load balancer on port 6443	Upstream documents the topology, but you build and operate the load balancer and etcd backups. etcd should run with an odd member count, and the Kubernetes documentation recommends a five-member cluster in production.
Networking	A CNI plugin such as Calico, Cilium or Flannel, plus an ingress controller or Gateway API implementation	Upstream does not ship a default CNI. Choose one, then validate network policy behavior and MTU against your hardware. Confirm which networking components NKP bundles and whether they are supported separately.
Storage	Longhorn on Harvester for distributed block storage; CSI drivers for external arrays	Harvester bundles Longhorn, but Longhorn carries an additional usage-based entitlement under SUSE support terms. On bare metal or Proxmox VE, you select and operate a CSI driver and storage backend yourself.
Identity and authentication	Kubernetes authentication through X.509 certificates, OpenID Connect tokens, webhook token authentication or an authenticating proxy	Kubernetes does not manage human users as API objects, so an external identity provider and OIDC configuration are required. Confirm how NKP integrates identity and whether that integration is in your entitlement.
Secrets	Encryption at rest for etcd, least-privilege RBAC, and the Secrets Store CSI Driver for external stores	Secrets are stored unencrypted in etcd by default, so encryption at rest must be configured deliberately. Plan key rotation and backup of encryption keys as part of operations.
Monitoring and logging	Prometheus, Grafana and an alerting stack, as bundled with Harvester	Harvester's documented stack includes Grafana and Prometheus for monitoring and logging. Upstream Kubernetes does not supply dashboards or long-term retention, so define retention and alerting ownership yourself.
Management UI and multi-cluster management	Rancher for managing Harvester and guest clusters together, or a self-hosted dashboard	Harvester's README describes Rancher integration. Rancher Manager and guest Kubernetes each need their own entitlement under SUSE terms, so confirm the NKP equivalent in your contract.
VM and container co-location	KubeVirt on Kubernetes, managed through Harvester or Forklift for migrations	KubeVirt live migration requires shared ReadWriteMany storage for VMs using PersistentVolumeClaims. Bridge pod network binding blocks migration, so confirm your VM network design early.

Which open-source Kubernetes platform fits which estate

NKP buyers usually run Kubernetes on Nutanix hardware, so the replacement depends on whether they still need VMs beside containers. The three paths below differ in how many layers they add, which skills they assume and who carries the support burden.

Harvester for VMs and Kubernetes together

Harvester combines Kubernetes, KubeVirt for VMs, and Longhorn storage on the same nodes, which is closest to the hyperconverged model NKP sits beside. It fits teams that run VMs such as legacy databases next to containerized workloads. Production use assumes x86_64 CPUs with hardware-assisted virtualization, 16 cores or more, 64 GB of memory or more, 500 GB or more of disk, and 10 Gbps networking. Confirm that your reused Nutanix nodes meet those minimums before planning.

Proxmox VE with Kubernetes guest VMs

Teams already running Proxmox VE can place a Kubernetes cluster in guest VMs and keep the hypervisor layer they already operate. The trade-off is that you run the cluster lifecycle yourself on top of Proxmox, including node upgrades, etcd backups and certificate rotation. Proxmox VE subscriptions are per occupied CPU socket, so the support cost does not grow with cluster size. Check that your staff can operate both the hypervisor and the Kubernetes control plane.

kubeadm on bare metal

Running kubeadm directly on bare metal removes the hypervisor layer entirely and gives the most direct path to upstream Kubernetes. It suits teams with strong Linux and Kubernetes skills and workloads that do not need VMs. A production control plane needs at least three control plane nodes behind a TCP load balancer on port 6443, and etcd needs a tested backup and restore plan. You also own patching, storage and node provisioning, so budget staff time for those tasks.

Storage and network planning

Storage choices decide how much of NKP's hyperconverged behavior you keep. Longhorn on Harvester provides distributed block storage on the same nodes, while Proxmox and bare metal designs usually need Ceph or an external array chosen separately. KubeVirt live migration requires shared ReadWriteMany access for VM disks on PersistentVolumeClaims, so verify storage classes before you commit to VM workloads. Ask each vendor to confirm the access modes its storage supports.

Support and entitlement boundaries

Open-source releases carry no vendor support by default, so the support model is part of the choice. SUSE sells Harvester support as SUSE Virtualization, but that entitlement covers bundled components only, and Longhorn usage and Rancher or guest Kubernetes need separate entitlements. Proxmox offers subscriptions per socket, and Kubernetes distributions often come from third parties. Ask for the written support scope and who answers a production incident before choosing a path.

Running Kubernetes alongside the rest of the Nutanix estate

Most teams cannot move every AHV workload and every cluster at once. During a hybrid period, existing NKP clusters keep running on Nutanix while new upstream Kubernetes clusters are built on another platform, and the two estates share networking, identity and backup. The main risk is operating two control planes and two sets of certificates, upgrade calendars and monitoring at the same time, so the team should decide early which platform owns each cluster.

Cluster ownership: Record which clusters stay on NKP, which move, and which new workloads start on the target platform.
Control plane placement: Keep at least three control plane nodes for any cluster that will hold production state, and place them on separate hosts. The kubeadm high availability guide describes stacked and external etcd topologies with a TCP load balancer on port 6443.
etcd backups: Schedule etcdctl snapshot save on each cluster, store snapshots off the cluster, and test restores with etcdutl before any cutover.
Version skew: Follow the Kubernetes version skew policy, upgrading kube-apiserver one minor version at a time and keeping kubelets within three minor versions.
Shared services: Confirm which identity, secrets and monitoring services both estates will use during the overlap.

Confirm with your Nutanix account team how the NKP license terms apply to clusters that are shut down or migrated in stages.

How cluster lifecycle, upgrades and etcd backups change without NKP

Moving off NKP means the team owns the control plane lifecycle that the platform otherwise handles. Upstream Kubernetes is built with kubeadm, and the kubeadm high availability guide describes two topologies: a stacked control plane with etcd on the same nodes, or an external etcd cluster. Either way, plan for at least three control plane nodes behind a TCP load balancer that fronts kube-apiserver on port 6443. Decide early which topology you will run, because it changes how many machines you provision, how you patch them, and how failures are isolated. Confirm the load balancer design with your network team before any cluster is built. Upgrades follow the version skew policy, and the sequence is strict. kube-apiserver must be upgraded one minor version at a time and before kube-controller-manager, kube-scheduler and kubelets. Kubelets may run up to three minor versions behind the API server, which gives you a window but not a free pass. Kubernetes ships about three minor releases a year on a roughly 14-week cycle, and each minor receives about one year of patch support. As of September 2026 the supported minors are 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Build a calendar that tracks these dates, and budget a recurring upgrade cycle for each minor you run.

etcd is the part most likely to be underestimated. Kubernetes documentation recommends an odd number of etcd members, with five members in production, and requires a backup plan for etcd data. Take snapshots with etcdctl snapshot save on a schedule, store them off the cluster, and test restores with etcdutl in a non-production environment before you need them. Secrets are stored unencrypted in etcd by default, so the backup set is also sensitive data that needs encryption and access control. Ask your platform team to document who can restore etcd, how long a restore takes in your environment, and what happens to workloads during that window. These answers belong in the runbook before go-live, not after the first incident.

How to move NKP workloads to upstream Kubernetes

This sequence moves NKP workloads onto upstream Kubernetes in stages, so each stage is tested on a non-production cluster before production traffic, data or VMs are moved.

Inventory clusters, workloads and entitlements
Your platform or infrastructure team lists every NKP cluster, its worker nodes, the physical cores or vCPUs they use, and the Kubernetes version each runs. Record the workloads on each cluster, the persistent volumes they depend on, any VMs running through KubeVirt or the Nutanix stack, and the external services they call. Confirm with Nutanix which subscription terms and support entitlements apply, and when they end. The step is done when you have a signed-off inventory and a dated list of decisions on what stays, moves or is retired.
Build a non-production cluster on the chosen platform
Choose the target, such as Harvester, Proxmox VE with a Kubernetes layer, or bare metal running kubeadm, and check its hardware against your reused nodes. For a kubeadm build, the high availability guide describes a stacked or external etcd topology with at least three control plane nodes and a TCP load balancer in front of kube-apiserver. Confirm the Kubernetes minor version you will run and its support window on the Kubernetes releases page. The step is done when the staging cluster passes your conformance and health checks and your team can perform an upgrade on it.
Migrate stateless workloads first
Redeploy stateless workloads to the new cluster from the same manifests, Helm charts or GitOps repository you already use, and point ingress and DNS at them in a controlled order. Review image pull access through your registry, pod security settings and the RBAC bindings your applications depend on. Run both environments in parallel for the services that can tolerate it. The step is done when each stateless service has passed functional tests on the new cluster and its traffic can be shifted back to NKP without a rebuild.
Rebuild persistent data through backup and restore
Stateful workloads are usually the slowest part. Identify each volume, its storage class on NKP, and its consistency requirements, then choose a backup path that runs on the target, such as Velero for Kubernetes resources and volume data. Restore into the staging cluster and verify application-level data, not just that the pod starts. Confirm that the storage on the target meets the write performance your databases need. The step is done when a restore has been tested for each stateful service and the team has recorded the results.
Move virtual machines with the import paths
If NKP manages VMs through KubeVirt or the underlying Nutanix stack, move them with the import path that matches the target. Harvester's vm-import-controller add-on must be enabled first, and Forklift can migrate VMs to KubeVirt from VMware, OVA, EC2, Hyper-V, oVirt and OpenStack sources. Confirm the source format you can export from Nutanix and whether live migration will require shared ReadWriteMany storage for those VMs. The step is done when each VM boots on the target, its network and disks match the original, and its guest tools have been updated.
Cut over production traffic in phases
Schedule the production cutover with the application owners, using the order and rollback points you tested in staging. Move traffic service by service, watch error rates and latency for each one, and keep the NKP cluster available until the new environment has run through a full business cycle. Confirm your monitoring, logging and alerting on the new cluster before the switch. The step is done when production traffic runs on the new cluster, rollback has been tested, and the owners have signed off on each service.
Decommission NKP and close the subscription
Once the new environment has carried production traffic without a rollback, drain the NKP worker nodes, remove the cluster, and retain the final backups and configuration exports under your retention policy. Confirm with Nutanix when the subscription ends and whether any support obligations remain, and reclaim the hardware for the new platform or for other use. Update your configuration management, runbooks and asset records. The step is done when NKP no longer runs in production, the licenses are released, and the documentation reflects the new platform.

What buyers ask before moving off NKP

What does moving off Nutanix Kubernetes Platform cost?

The cost is the sum of several components, and the licence is only one of them. NKP is licensed per physical core on bare metal or NCI, or per vCPU on VMs including public cloud, and licences apply to worker nodes only. Upstream Kubernetes is Apache 2.0 licensed, so the software itself carries no fee. The recurring costs you need to price are:

Support contracts from whichever vendor you choose, such as SUSE for Harvester or a commercial Kubernetes distribution.
Staff time for upgrades, etcd backups, monitoring and security patching.
Hardware, storage and network capacity, including any capacity you add.

One-time costs include design, migration, testing and cutover. Ask any implementation partner for a fixed-scope quote that lists node count, cluster count, storage design, number of workloads and integrations, and what is excluded.

How long does a migration off NKP take?

Duration depends on scope, not on the platform alone. The main drivers are the number of clusters, how many applications run on each, whether stateful workloads need data moved, how much of the Nutanix layer (NKP, Prism, Flow policies, Files or Objects) must be replaced, and how many change windows the business allows. Migrating stateless services is usually quicker than moving databases, which require replication and verified restores. Your provider should agree a written timeline after a discovery phase that inventories clusters, workloads and dependencies. Treat any duration quoted before that inventory as a placeholder.

Can our in-house team run upstream Kubernetes without NKP?

Your team can run it if it has the skills and time to operate the control plane, etcd, networking, storage and upgrades. Kubernetes releases roughly three times per year, and the project maintains only the three most recent minor versions, so an upgrade calendar is mandatory. Plan for a highly available control plane of at least three nodes behind a TCP load balancer on port 6443, an etcd backup routine using etcdctl snapshot save with tested restores, and encryption at rest for Secrets, which Kubernetes does not enable by default. Be honest with yourself about on-call coverage. If the team cannot staff that rota, budget for a support or managed retainer from a vendor or implementation partner.

Who supports upstream Kubernetes after the migration?

Upstream Kubernetes is an open project, so there is no single vendor contract for the core. Support comes from the distribution or platform you choose and from the people you hire. The CNCF Certified Kubernetes conformance program checks that distributions support the required Kubernetes APIs, and the CNCF page states there are over 90 Certified Kubernetes offerings, so ask any vendor whether its distribution is conformant. Ask each candidate which versions it supports, its patch window, its response terms and whether it covers the guest cluster as well as the hypervisor layer.

What does SUSE's support matrix say about Harvester entitlements?

SUSE's support matrix says a Harvester support entitlement covers the components bundled with the appliance, including the host OS, Longhorn storage, the cloud provider and CSI driver and the Terraform provider. Longhorn carries an additional usage-based entitlement, and Rancher Manager or the guest Kubernetes needs a separate entitlement. The matrix lists v1.8.0 as a Community release and v1.8.1 and v1.8.2 as Prime releases, with end of maintenance on December 29, 2026 and end of life on December 29, 2027. Confirm with SUSE which Harvester version you will deploy, which entitlements a quote includes and whether the Prime or Community tier applies to your production use.

What happens to our Nutanix licence at renewal?

The licence runs as a term subscription, and NKP is priced per physical core or vCPU on worker nodes. Nutanix sells NCI as 1 to 5 year terms, so the cleanest exit is to plan the cutover around the renewal date. Before that date, confirm with Nutanix in writing what happens to support, updates and access to NKP at expiry, how many worker nodes and cores are counted, and whether you can run a reduced term while migration completes. Overlapping licences during a parallel run are a cost to model. Do not let the renewal date set the migration schedule without a tested rollback path.

What does DeployOpen cover in an NKP migration?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Kubernetes and virtualization layers covered here. Engagements are normally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Security testing of the new platform and compliance readiness work, where you need evidence for an assessment, can be part of the same scope. DeployOpen does not issue audit reports or certifications, and independent auditors and certification bodies do that work. Ongoing support and upgrades are available as retainers. Quotes follow from the written scope.

What hardware do we need for Harvester in production?

The Harvester README sets production minimums of x86_64 CPUs with hardware-assisted virtualization and 16 cores or more, 64 GB of memory or more, 500 GB or more of disk with at least 5,000 random IOPS per SSD or NVMe disk, and 10 Gbps networking. Laptops and nested virtualization are not officially supported. Compare these figures against any Nutanix nodes you plan to reuse, because older hardware often fails the storage IOPS or network requirement. Confirm the exact requirements for your chosen Harvester version in its documentation before buying or repurposing hardware.

What the cost components are compared with NKP licensing

NKP is licensed per physical core on bare metal or NCI, or per vCPU on virtual machines including public cloud, and the license applies to worker nodes only. Control plane nodes do not need licenses. That single rule changes the arithmetic: a cluster with three control plane nodes and a large worker pool pays only for the worker capacity. In the open-source route, upstream Kubernetes carries no license fee under Apache 2.0, so the recurring cost moves to the people who run the cluster, the hardware, any vendor support you buy, and the storage layer. Ask your Nutanix account team for the core count and vCPU counting rules in writing, and compare them against the worker node sizing you actually plan to run.

The one-time work includes platform design (topology, etcd layout, load balancing, storage and network choices), migration of existing workloads, testing of upgrades and failure scenarios, documentation, and training for the engineers who will operate the cluster. Most of that effort is front-loaded and hard to price without a written scope. Recurring work includes patching the host OS and Kubernetes, which must follow a roughly 14-week release cycle with the three-version support window, backups of etcd and VM disks, monitoring, on-call coverage, and security hardening. Support is the largest variable. If you buy SUSE Virtualization, the Harvester support entitlement covers the bundled components, but Longhorn carries an additional usage-based entitlement and Rancher Manager or guest Kubernetes needs its own entitlement. Confirm each of these with SUSE before you compare totals.

The total changes with worker node count and size, how many clusters you run, whether you need vendor support or can rely on internal skills, the number of VMs that will move under KubeVirt, the hardware you reuse, and how much storage and scratch capacity you provision. Ask any provider for a quote that separates license or subscription fees, support entitlements, implementation services, training, and recurring operations, and state which items are one-time and which recur each year. DeployOpen prepares these comparisons from a written scope, and it does not publish prices.

How DeployOpen scopes and delivers a Kubernetes platform replacement

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Kubernetes clusters, virtualization hosts and storage behind a Nutanix Kubernetes Platform replacement. Engagements start with a written, fixed scope so that cluster design, tooling, testing and handover terms are agreed before any work begins.

How we scope

Inventory the NKP clusters, worker node counts, workloads and the hardware they run on before proposing a design.
Agree in writing which components are in scope, such as Harvester or Proxmox VE hosts, kubeadm control planes, etcd backups and ingress.
Confirm which Kubernetes minor version, lifecycle tooling and support model the platform will target, including who answers for each layer.

How we build

Deploy upstream Kubernetes with a highly available control plane, external load balancing and an etcd backup plan agreed up front.
Configure encryption at rest for Secrets, least-privilege RBAC, authentication integration and Pod Security Standards settings.
Test cluster upgrades, node failure, live migration of KubeVirt VMs and restores from backup before any production cutover.

How we hand over

Document architecture, runbooks for upgrades and etcd restores, and the version skew rules your operators must follow.
Provide configuration and hardening evidence that your internal or external auditors can review, without us issuing any audit report.
Walk your platform, security and operations teams through the running environment and agree what remains in their hands.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
Ask any provider which Kubernetes releases they patch, how long, and who handles Harvester, Longhorn or Rancher entitlements.
Retainer scope should name the Kubernetes minor versions covered, the response paths for incidents and the testing cadence.

Open-source alternative to Nutanix Kubernetes Platform