Fleet-First Kubernetes: Inside the NKP Management & Managed Cluster Model
- Taylor Norris
- Jul 13
- 5 min read
How Nutanix Kubernetes Platform turns Cluster API into a single control point for dozens of clusters — and the concepts every IT and K8s admin needs before they run nkp create cluster.
One cluster is a project. Twenty clusters across three datacenters, two clouds, and a handful of edge sites is an operations problem. The moment you have more than a single Kubernetes cluster, the hard questions stop being "how do I run a pod" and start being "how do I provision, patch, secure, and observe all of these the same way, without hiring a platform team for each one."
That gap is exactly what the Nutanix Kubernetes Platform (NKP) is built to close. NKP describes itself as a centralized control point for an organization's application infrastructure, built around the open-source Cluster API (CAPI) project. Instead of treating each cluster as a pet, NKP treats your clusters as a fleet: declarative, lifecycle-managed, and governed from one place. This post walks through the mental model: the components, the cluster types, the CAPI machinery underneath, and how you slice the fleet into teams — so the rest of NKP makes sense.
01 Three components: Konvoy, Kommander, and the Image Builder
NKP is composed of three cooperating parts. Knowing which one owns which job saves a lot of confusion later, because almost every NKP task lives in one of them.
Konvoy The cluster lifecycle manager. Konvoy uses Cluster API plus other open-source tooling to provision conformant Kubernetes clusters with networking and storage on Nutanix AHV, vSphere, AWS, Azure, GCP, and pre-provisioned bare metal — in both connected and air-gapped environments. Its cluster manager bundles Cluster API, CSI, CNI, the Cluster Autoscaler, Cert Manager, and load balancers. On Nutanix infrastructure the CNI is Cilium; every other provider uses Calico.
Kommander The fleet management layer. Kommander delivers centralized observability, governance, unified policy, and the NKP UI. It manages platform applications (monitoring, logging, backup, policy, ingress, SSO), and — on the Ultimate tier — attaches external clusters and manages application lifecycle via FluxCD.
Nutanix Image Builder (NIB) Creates Cluster API-compliant machine images preloaded with everything a node needs to join a cluster, including options for GPU and FIPS builds.
The architecture diagram below is worth a slow read. Notice that the Management Cluster runs the managers (Cluster API controllers, FluxCD, Git operators, cert manager, multi-tenancy) and the platform/catalog apps, while the actual workloads live out on the Managed and Attached clusters to the right. Users reach it three ways — CLI, UI, and GitOps.
02 The three cluster types — and why the distinction matters
Almost every decision in NKP keys off what kind of cluster you're talking to. There are three, and they map cleanly onto license tiers.
Cluster type | Who manages its lifecycle | Availability |
Management cluster | Itself — it is self-managed. Also manages other clusters in a multi-cluster setup. | All editions |
Managed cluster ("NKP cluster") | The management cluster owns its infrastructure, lifecycle, and applications. | All editions |
Attached cluster | Created outside NKP (e.g. GKE, EKS, any conformant K8s), then connected so NKP manages its applications only — not its lifecycle. | Ultimate only |
The guidance is explicit: run your workloads on managed and attached clusters, and keep the management cluster for management. The one exception is a single-cluster environment, where everything runs on the one self-managed cluster you stood up.
03 How a management cluster bootstraps itself (the CAPI pivot)
The most elegant — and initially confusing — trick in NKP is how a self-managed cluster comes to exist. Cluster API needs a Kubernetes cluster to run the controllers that create Kubernetes clusters. NKP solves the chicken-and-egg with a temporary bootstrap cluster (a local KIND cluster), then pivots the CAPI resources onto the new cluster so it can manage itself.
Why this matters: A self-managed cluster is simply one where the CAPI resources and controllers that describe it run on the cluster they manage. After the pivot, your management cluster reconciles its own control plane and worker nodes the same declarative way it will reconcile every cluster you create after it.
04 The CAPI primitives you'll actually touch
Because NKP is CAPI all the way down, a little vocabulary goes a long way when you're reading cluster state or planning an upgrade.
Machine — a declarative spec for one node (VM or bare-metal host). Machines are immutable: change anything beyond labels/annotations/status and the controller deletes the host and provisions a fresh one that matches the new spec. Delete a Machine and its infrastructure and node go with it.
MachineDeployment — manages Machines the way a Kubernetes Deployment manages Pods, rolling changes across two MachineSets (old and new) for safe, declarative node rollouts.
MachineHealthCheck (MHC) — detects unhealthy nodes and triggers remediation. The default maxUnhealthy is 40%, tunable for your self-healing appetite.
ClusterResourceSet — a CRD that groups and deploys the components a raw CAPI cluster lacks out of the box (CNI, CSI, and friends) after the Kubernetes API is up.
The payoff of immutability is that there's no configuration drift to chase: a node either matches its declared spec or it's replaced. That's the same philosophy that makes the fleet predictable at scale.
05 Slicing the fleet: Workspaces, Projects, and multi-tenancy
A fleet that you can't subdivide is just a big blast radius. NKP gives you two grouping constructs.
Workspaces
A Workspace is a logical grouping of clusters that share configuration, with certain settings automatically federated to its members. Workspaces let you model the org the way it actually works: by department, product, business unit, or tenant, and let those teams manage their own clusters. Platform applications and defaults are configured at the workspace level.
Projects
A Project lives inside a workspace and handles multi-cluster configuration management: ConfigMaps, Secrets, services, quotas, network policies, continuous deployments, and RBAC, all propagated as federated resources. When you create a Project, NKP creates a federated namespace that is pushed to every cluster matching the Project's labels.
Mental model: Workspace = a set of clusters (a tenant's slice of the fleet). Project = a set of namespaces and config federated across a labeled subset of those clusters.
This is how NKP supports genuine multi-tenancy: central IT or a business unit can share a pool of Kubernetes clusters across several teams, each isolated by namespace and policy, each receiving a consistent configuration from one source of truth.
06 One pane of glass
All of this surfaces in a single dashboard. From here an admin sees the management cluster's health, every managed and attached cluster grouped by workspace, error/warning counts across the fleet, and (on Pro/Ultimate) the AI Navigator assistant in the corner. It's the operational home base that the architecture above exists to power.
Key takeaways
Three components, three jobs: Konvoy does cluster lifecycle, Kommander does fleet management and the UI, NIB builds the node images.
Cluster type drives everything: management (self-managed), managed (NKP owns lifecycle + apps), attached (NKP owns apps only, Ultimate).
It's CAPI underneath: the bootstrap-and-pivot makes the management cluster self-managed; immutable Machines mean no config drift.
Workspaces group clusters; Projects federate namespaces and config across labeled subsets — that's your multi-tenancy and your consistency story.
Additional Links
Comments