Nutanix Konnector Finally Makes Kubernetes Make Sense in Prism Central

A couple of days ago, while browsing the Nutanix Support Portal, I noticed something new in the Downloads section. A product name I had never seen before, simply labeled Nutanix Konnector (NK).

At that moment, there were no actual downloads available. No bundles, no charts, no guides. Just a placeholder entry with a short description. Enough to spark curiosity, but not enough to understand what it was meant to be.

Nutanix Konnector (NK) is a multi-cluster management service for Kubernetes workloads built natively into Prism Central. It helps to connect and manage Kubernetes infrastructure in Prism Central, providing observability and infrastructure governance for all clusters running a variety of Kubernetes distributions.

That description immediately stood out. Prism Central has always been strong at managing Nutanix infrastructure, but Kubernetes has historically lived slightly on the side, especially outside of NKP. Seeing Kubernetes positioned as something built natively into Prism Central suggested a deliberate shift.

Today, the picture is clearer. The downloads have appeared, together with the official guide and the release information. What initially looked like a quiet placeholder has now turned into a fully documented service, making it possible to connect the dots and understand what Nutanix Konnector really is, how it works, and why it exists.

For readers looking for the official technical reference, Nutanix has published the complete Nutanix Konnector v1.0 documentation on the Support Portal.

Kubernetes in Prism Central before Konnector

Kubernetes was not new to Prism Central.

When Karbon was still part of the platform, it introduced its own Kubernetes Management entry in the Prism Central dropdown menu. That experience was tightly coupled to clusters created and fully managed by Karbon. Prism Central owned everything. Creation, lifecycle, and deletion.

At the same time, Prism Central already exposed a Kubernetes Clusters section in the left side Infrastructure menu. That view allowed administrators to onboard existing Kubernetes clusters for observability, without taking ownership of their lifecycle.

Two entry points. Two mental models.

One tied to Karbon and NKP.
The other generic, observational, and largely undocumented.

This duality matters, because Nutanix Konnector does not introduce a new concept. It formalizes and clarifies something that was already there.

What Nutanix Konnector really is

Nutanix Konnector is not a Kubernetes management platform. It is not a replacement for NKP, OpenShift, or EKS Anywhere.

It is a Prism Central service whose primary goal is to automate the onboarding of Kubernetes clusters and make them visible, observable, and governable within the Prism Central control plane.

Internally, Nutanix describes Konnector as a lightweight, containerized bridge between Kubernetes clusters and Prism Central. That definition matters, because it explains the design choices behind the product.

With Konnector, Kubernetes becomes a first class infrastructure object again, without Prism Central owning the cluster.

The architecture behind Konnector

Nutanix Konnector is composed of two clearly separated components.

The Konnector service

The Konnector service runs natively inside Prism Central. Starting with Prism Central 7.5, it is enabled by default and requires no additional installation.

It acts as the control plane. It maintains the inventory of onboarded Kubernetes clusters, processes telemetry and heartbeat data, and exposes Kubernetes clusters inside the Prism Central UI.

Prism Central never connects directly to Kubernetes APIs.

The Konnector agent

The Konnector agent runs inside each Kubernetes cluster that needs to be onboarded. It is deployed using Helm and operates entirely within the cluster context.

The agent is responsible for:

• registering the cluster with Prism Central
• sending continuous metadata, metrics, and heartbeat updates
• handling lifecycle cleanup during offboarding

If the agent is gone, Prism Central has no cluster. Everything starts and ends there.

This is not an implementation detail. It is the design.

The onboarding flow in practice

From an operational perspective, onboarding follows a simple but slightly counterintuitive flow.

First, Prism Central already includes the Konnector service. There is nothing to install there.

Second, a lifecycle bundle called lcm_karbon_3.0.tgz must be uploaded to Prism Central. This is where confusion usually starts.

After uploading the bundle, nothing happens. No upgrade is proposed. No task is triggered. This behavior is expected.

The bundle does not install or upgrade any component. It registers legacy Kubernetes lifecycle metadata inside Prism Central that Konnector still depends on. The name is historical. The function is not.

Only after that do you deploy the Konnector agent on the Kubernetes cluster using Helm. Once the agent registers successfully, the cluster appears under Infrastructure > Compute > Kubernetes Clusters in Prism Central.

At that point, Kubernetes visibility becomes real.

The legacy Karbon bundle explained

The presence of the lcm_karbon_3.0 bundle makes sense once you look at history.

That bundle was originally designed to upgrade the Karbon application, which existed as a managed Prism Central app up to version 7.3. On Prism Central 7.5, Karbon is gone, but parts of the Kubernetes lifecycle framework remain.

Today, the bundle survives as a legacy artifact that satisfies internal dependencies. It no longer installs anything, and it no longer represents Karbon coming back.

Konnector is not Karbon, even if the bundle name suggests otherwise.

Supported Kubernetes distributions

Nutanix Konnector is deliberately platform agnostic.

All clusters are treated in the same way. They are onboarded, not created. They remain fully managed by their native tooling. Prism Central provides visibility, inventory, and governance context.

At the time of the 1.0 release, the following platforms are supported:

• Nutanix Kubernetes Platform
  Supported starting from NKP 2.16.1. Earlier 2.16 builds are not supported.
• Red Hat OpenShift Container Platform
  Version 4.16.
• Amazon EKS Anywhere
  Version v1.33.1.

Both air gapped and non air gapped environments are supported. The onboarding mechanism is identical across distributions. The same agent, the same flow, the same operational model.

For the full compatibility matrix, deployment steps, and upgrade procedures, refer to the official Nutanix Konnector v1.0 documentation.

Why giving this a name matters

Prism Central already had Kubernetes observability. What it lacked was a clear abstraction and a supported lifecycle.

By naming this capability Nutanix Konnector and decoupling it from NKP and Karbon, Nutanix is acknowledging a simple reality. Kubernetes environments are heterogeneous.

Konnector does not try to normalize how clusters are built. It normalizes how they are seen.

That is the real value of this release.

Final thoughts

Nutanix Konnector is not something you install because it is new. It is something you enable when Prism Central is your control plane and Kubernetes is no longer confined to a single platform.

It removes historical ambiguity, clarifies responsibilities, and quietly lays the foundation for treating Kubernetes as infrastructure again, without owning it.

Sometimes, the most important changes are the ones that simply make things make sense.