Nutanix Kubernetes Platform (NKP) | Part 1: Architecture & Key Concepts

Running Kubernetes in production is hard. Running it at scale, across multiple environments, while keeping up with EU regulations like NIS2 and DORA? That's a different challenge entirely.

This is Part 1 of a series where we go from zero to a fully operational NKP environment. We'll cover the architecture, the key concepts, and what makes NKP stand out from vanilla Kubernetes or platforms like OpenShift and Rancher.

What Is NKP?#

NKP is a Kubernetes management platform built on pure upstream, CNCF-conformant Kubernetes. It's not a fork. It's standard K8s with a curated stack of services on top that handle the hard parts of running clusters in production.

The platform came out of Nutanix's acquisition of D2iQ (formerly Mesosphere) in 2023. It brings together two main components:

• Konvoy: the Kubernetes distribution itself, shipping with CIS-hardened node images
• Kommander: the management layer that provides the UI, GitOps, multi-tenancy, observability, and an application catalog

Together, they cover the full lifecycle: deploying clusters (Day 0), configuring them (Day 1), and operating them long-term (Day 2).

The diagram above gives you a sense of the breadth. Instead of gluing all these tools together yourself, NKP ships them pre-configured and lifecycle-managed. Cilium for networking, Prometheus and Grafana for monitoring, Velero for backups, Dex for authentication... it's all there, ready to go.

Architecture Overview#

NKP uses a hub-and-spoke model. At the center sits a management cluster that takes care of everything else.

The Management Cluster#

Think of the management cluster as the control tower. It's a self-managed Kubernetes cluster that runs all the platform controllers and services:

Cluster API (CAPI): What Makes It Work#

Under the hood, NKP relies on the Kubernetes Cluster API to manage cluster lifecycles. CAPI lets you define clusters as Kubernetes resources in YAML. You apply them, and controllers handle the rest.

On Nutanix infrastructure, CAPI talks to Prism Central through CAPX (the Cluster API Provider for Nutanix). CAPX handles the infrastructure side: creating VMs, setting up networking, and attaching storage. On top of that, CAREN (Cluster API Runtime Extension for Nutanix) adds Nutanix-specific logic like OS image selection and cluster configuration defaults.

Once your management cluster is running, you can verify both controllers are healthy:

# Check the CAPX infrastructure provider
kubectl get pods -n capx-system

# Check the CAREN runtime extensions
kubectl get pods -n caren-system

Here's how the bootstrap process works in practice:

1. You run the nkp CLI on a jump host. It spins up a temporary KinD (Kubernetes in Docker) cluster
2. This bootstrap cluster runs CAPI controllers that create the management cluster VMs on Nutanix AHV
3. Once the management cluster is up, the CAPI controllers pivot over to it
4. The bootstrap cluster gets deleted. The management cluster is now self-managing
5. From this point on, it creates and manages all your workload clusters

docker logs konvoy-capi-bootstrapper-control-plane

Three Types of Clusters#

NKP works with three cluster types, each with a different purpose.

Managed clusters get the full treatment. NKP controls their lifecycle through CAPI, deploys platform services like monitoring and logging, and enforces your policies.

Attached clusters are different. These are Kubernetes clusters you already run somewhere else (could be EKS, GKE, or a plain kubeadm setup). You connect them to NKP so you can see them in the same dashboard and apply the same governance rules. NKP doesn't touch their infrastructure.

Lifecycle Management#

Creating, scaling, upgrading, and deleting clusters are all done through YAML or the CLI. No clicking through wizards, everything is scriptable and repeatable.

Creating a Cluster#

You define a workload cluster using a ClusterClass topology. Here's a simplified example:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: production-wkl-01
  namespace: production-workspace
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["192.168.0.0/16"]
    services:
      cidrBlocks: ["10.96.0.0/12"]
  topology:
    class: nkp-nutanix-v2.17.1
    version: v1.34.3
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: default-worker
          name: md-general
          replicas: 3

Apply it with kubectl apply and CAPI takes it from there. It creates the VMs on AHV, bootstraps the OS, runs kubeadm, deploys the CNI and CSI drivers, and rolls out all your platform services.

Scaling#

Want more nodes? The nkp CLI handles it:

nkp scale nodepools md-general \
  --cluster-name=production-wkl-01 \
  --replicas=5

You can also set up autoscaling with annotations on your MachineDeployment:

metadata:
  annotations:
    cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size: "3"
    cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size: "10"

Upgrading#

Kubernetes version upgrades are rolling. You point to a new node image that contains the target K8s version, and CAPI replaces nodes one at a time (or in batches if you prefer):

nkp upgrade cluster nutanix \
  --cluster-name production-wkl-01 \
  --vm-image nkp-rocky-9.7-release-cis-1.34.3-20260504011927.qcow2

No downtime. Workloads get drained and rescheduled as each node is replaced. The node images are built with NIB (Nutanix Image Builder, which replaced the older KIB in NKP 2.17+) and contain a specific Kubernetes version, OS patches, and CIS hardening.

Fleet Management and Multi-Tenancy#

When you have multiple teams sharing the platform, you need proper isolation. NKP handles this with a hierarchy of workspaces and projects.

Workspaces#

Workspaces are the top-level boundary. They usually map to teams or environments:

• production for live workloads with strict access controls
• staging for pre-production testing
• development for developer sandboxes

Each workspace gets its own namespace on the management cluster, its own RBAC policies, and can contain multiple clusters.

Projects#

Projects sit inside workspaces. They give you namespace-level isolation within your workload clusters. This is where you scope your actual applications.

RBAC#

NKP uses a 3-layer RBAC model:

Hybrid and Multi-Cloud#

NKP isn't locked to Nutanix AHV. You can manage workload clusters across several infrastructure providers from the same management cluster.

The workflow stays the same regardless of provider. A cluster on AWS and a cluster on AHV look identical from a management perspective. Same monitoring, same policies, same GitOps pipeline.

Air-Gapped Deployment#

For regulated industries like banking, government, or healthcare, internet access might not be available. Or it might not be acceptable from a security standpoint. NKP fully supports air-gapped (disconnected) deployments.

The process looks like this:

1. Download the NKP air-gapped bundle (~15 GB) on a machine with internet
2. Transfer it to the isolated network (USB drive, secure file transfer, etc.)
3. Deploy directly from the bundle, or push the container images to an internal registry first. NKP can deploy Harbor as your internal registry if you don't already have one
4. Run the same nkp CLI commands, pointed at your local artifacts instead of Docker Hub

Why This Matters in the EU#

With NIS2 and DORA now in effect, organizations in critical infrastructure and financial services need to show they control their software supply chain. Air-gapped deployment gives you:

• No runtime dependencies on external registries
• Full control over which container images enter your environment
• An audit trail for every artifact
• Compliance with data sovereignty requirements

Platform Services#

NKP ships with a full stack of services, all managed through Flux CD. Here's what you get out of the box:

Networking#

Observability#

Security#

Storage and Backup#

Licensing#

NKP comes in four tiers:

How Does It Compare?#

NKP's key strengths are upstream K8s without fork risk, Cilium as the default CNI on AHV, CAPI for portable cluster definitions, and seamless integration with the Nutanix storage and networking stack.

What's Next#

In the next parts of this series, we get hands-on:

• Part 2: Prerequisites and internet-connected deployment. Setting up the jump host, configuring Prism Central, and deploying your first management cluster.
• Part 3: Air-gapped deployment. Registry mirror and bundle methods for regulated environments.
• Part 4: Day 2 configuration. Authentication with Dex and LDAP, RBAC setup, storage backends, monitoring.
• Part 5: Workload clusters and applications. Creating clusters, deploying apps, GitOps workflows.
• Part 6: Operations. Monitoring, backup, upgrades, and troubleshooting.

Every part includes real commands and output from our ITCS Lab running NKP 2.17.1 on Nutanix AHV.

Summary#

NKP takes the complexity out of running Kubernetes at scale. Its architecture, built around CAPI for cluster lifecycle and Flux CD for GitOps, gives you repeatable and auditable infrastructure management.

For organizations in the EU dealing with NIS2 and DORA requirements, the air-gapped deployment, hardened node images, and built-in security scanning cover a lot of ground.

We've deployed NKP across multiple client environments in Luxembourg, the EU, and beyond, from single-cluster labs to multi-team production setups. This series captures what we've learned along the way.