Still Seeing Karbon in Prism Central?

Migrating from the legacy Nutanix Kubernetes Engine to Nutanix Kubernetes Platform is usually a clean transition. Workloads move to a modern architecture and day-to-day operations shift to the platform that Nutanix actively develops. Yet administrators often discover that Prism Central still exposes traces of Karbon long after NKE has been retired. The issue is cosmetic. Nothing breaks. But the UI no longer reflects how the environment is designed and can create confusion in automation-heavy deployments.

This article explains why these artifacts remain, how to recognise them, and what the supported cleanup workflow looks like. You do not need internal scripts to understand the process. The goal is clarity and correctness before engaging Nutanix Support for the final removal.

Why Karbon Artifacts Remain After an NKP Migration

NKE integrated deeply with Prism Central. Beyond provisioning Kubernetes clusters, it registered internal services, UI modules, container images, Calm catalog entries, and metadata structures. This registration model does not unwind automatically when you migrate to NKP. The system intentionally retains historical structures because removing them incorrectly could compromise internal services.

As a result, even when NKE is no longer used, Prism Central may preserve components originally tied to the Karbon lifecycle.

Recognising the Leftovers

The clearest indication that Karbon is still present appears in the top navigation bar of Prism Central. The Kubernetes Management entry may remain visible even though no NKE clusters exist. Opening it often reveals the operating system images previously used to deploy nodes. These images are no longer linked to the NKP workflow but Prism Central continues to list them because the Karbon application was never formally decommissioned.

Everything continues to operate normally. The environment is simply not as clean as it should be.

Why Manual Cleanup Is Not Recommended

Karbon stored its state across multiple subsystems. Some elements live in metadata catalogs, others in Genesis-managed services, others in Calm’s internal database. Removing them manually risks creating inconsistencies that surface later during upgrades or catalog refreshes. Prism Central expects Karbon to be disabled in a controlled sequence that triggers internal checks and state transitions.

This is why direct removal is discouraged and why Nutanix provides guided tools for completing this workflow safely.

Preparing for the Cleanup

Before requesting the final cleanup, validate the environment. Ensure that no NKE clusters or workers remain registered, no Calm applications created by Karbon are active, and no workflows reference older metadata. Confirm that NKP operates fully on its own components and networking paths.
This avoids ambiguity and ensures that support can perform the cleanup without unwanted side effects.

How the NKE Cleanup Workflow Actually Works

The cleanup procedure used by Nutanix Support follows a deliberate sequence. Each phase targets a specific layer of Prism Central where Karbon left structures behind. Understanding this workflow helps clarify why the operation cannot be performed safely without internal tooling.

The process begins by identifying all Prism Central nodes and validating cluster health. Once the environment is confirmed stable, Karbon’s internal services are disabled. This step uses a support-guided tool that interacts directly with the internal service orchestration layer. Its purpose is to instruct Prism Central that Karbon’s UI and core engine should no longer be considered active services.

After disabling the services, support validates the updated state and confirms that the service registry reflects the change. The next step is the removal of Karbon service locks. These locks were created to sequence operations and ensure consistency during Karbon workflows. Prism Central prevents administrators from removing system files directly, but support is able to clear these locks safely when needed.

Once the platform services and locks are removed, attention shifts to container images that were part of the Karbon runtime. The Karbon UI and Karbon core images are deleted to prevent any attempt by Prism Central to restart modules that are no longer relevant. This reduces the internal footprint of NKE and eliminates deprecated code paths.

With the platform-level elements removed, the workflow moves to Calm. Karbon previously registered a “Kubernetes Management” application and an associated blueprint. Support uses the Calm domain manager to identify the application, mark it as deleted, update its metadata in the search index, and remove the blueprint. This ensures that Calm no longer displays Karbon in the service catalog.

The final step updates the account metadata used by Prism Central to present built-in capabilities. Karbon had registered itself as one of these capabilities. The cleanup updates the account configuration so that Prism Central recognises that Kubernetes Management is fully disabled. This is the step that removes the Karbon UI entry from the top navigation bar and ensures a consistent NKP-only experience.

Once all actions are complete, support performs a final validation to ensure that services remain disabled, the UI is clean, container images are removed, locks are cleared, Calm entries are gone, and internal state matches the intended design. At this point, the environment is fully decommissioned from NKE with no residual effects.

What You Should Expect After the Cleanup

Once the cleanup finishes, Prism Central reflects the new architecture. Karbon disappears entirely from the UI. The system no longer holds metadata or catalog entries linked to NKE. NKP stands as the only Kubernetes lifecycle solution exposed to the administrator.
The result is a cleaner, more predictable management plane and a more reliable foundation for future upgrades.

When to Engage Nutanix Support

If Karbon still appears after migrating to NKP, or if you encounter residual metadata related to NKE clusters, it is the right time to open a support case. Support validates the environment and performs the cleanup using tools designed for this purpose. Even though the issue is cosmetic, a consistent configuration ensures smoother lifecycle operations and keeps Prism Central aligned with your architecture.

Final Thoughts

Migrating from NKE to NKP is a natural evolution, but Prism Central may retain historical artifacts that do not belong in the new design. Understanding why they remain and how they are removed helps maintain clarity and operational consistency. With a bit of preparation and a guided cleanup, your environment becomes fully NKP-only, with a management plane that matches the platform you actually run.