NCP-CN 6.10 Study Guide · Section 2 of 4

Manage Building an NKP Cluster

Two objectives, but they carry the architecture of the whole platform: drive cluster creation with the NKP CLI + CAPI, then put Kommander on top and license it. If Section 1 was "before the build," this is the build.

🎯 Objectives 2.1 – 2.2 📅 War plan: Week 1, days 6-7 Versions NKP 2.12 · AOS 6.10 · pc2024.2

2.1Customize and deploy clusters

The front door is the NKP CLI. One command family does the heavy lifting:

# the canonical shape (Nutanix/AHV provider)
nkp create cluster nutanix \
  --cluster-name blueally-prod \
  --endpoint https://prism-central.fqdn:9440 \      # Prism Central
  --kubernetes-service-load-balancer-ip-range 10.0.50.10-10.0.50.29 \
  --control-plane-endpoint-ip 10.0.50.5 \           # the cluster VIP
  --subnets primary-subnet \
  --vm-image nkp-rocky-9.4-release-...              # the KIB/NIB image from 1.5
  # air-gapped adds registry mirror flags pointing at the seeded registry
  # --self-managed pivots CAPI into the new cluster (management cluster builds)
  # --dry-run -o yaml emits manifests instead of building (custom manifest path)

Customization beyond flags = CAPI. When a use case outgrows CLI flags (custom machine sizing per pool, special networking, taints/labels at birth), you generate the manifests (--dry-run -o yaml), edit the CAPI resources, and apply. Know which resource owns what:

You want to change…	CAPI resource to touch
Cluster wide identity, networking CIDRs	`Cluster` (+ provider cluster, e.g. `NutanixCluster`)
Control plane size/count/version	`KubeadmControlPlane`
Worker pool count, machine shape, labels	`MachineDeployment` (one per node pool)
Per VM provider details (CPU, RAM, disk, subnet, image)	Provider machine template (e.g. `NutanixMachineTemplate`)
Node bootstrap/kubeadm config (registries, files, users)	`KubeadmConfigTemplate`

Diagnosing a stuck deployment (exam loves this)

Walk the ownership chain and read conditions/events where it stalls: Cluster → KubeadmControlPlane → MachineDeployment → Machine → NutanixMachine. Practical tools: kubectl get cluster,machines -A, kubectl describe on the first not-Ready object, and clusterctl describe cluster style tree views. Machines stuck in Provisioning usually mean provider side problems (credentials, subnet, image not found); nodes up but NotReady usually means CNI/registry reachability.

Reading a use case for CLI parameters is mostly mapping nouns: "air-gapped" → registry mirror flags + seeded registry; "needs 5 workers with GPUs" → node pool/MachineDeployment sizing flags; "behind a VIP" → control plane endpoint IP; "on this subnet with this image" → --subnets / --vm-image.

2.2Customize and deploy Kommander (and license it)

Kommander is the fleet management layer: the UI/API where workspaces, projects, platform applications, attached clusters, and licensing live. It installs onto the management cluster after the cluster itself is built:

nkp install kommander \
  --installer-config kommander.yaml \   # the custom manifest for Kommander
  --kubeconfig $MGMT_KUBECONFIG
  # air-gapped: add the flag set pointing at the seeded registry

The installer config (custom manifest) is where you: enable/disable individual platform applications (don't deploy the full stack in a small environment), set app overrides (values), configure FIPS mode, and point at custom registries. "Installing Kommander in a Small Environment" is a named blueprint doc: trimming the default app set to fit constrained resources.

Licensing: after Kommander is up, you apply the NKP license (Starter/Pro/Ultimate from objective 1.3) through the Kommander UI or CLI flow; Ultimate unlocks the multi cluster surface (attach external clusters, Insights, multi tenancy).

Diagnosing a Kommander deployment issue

Kommander is Flux/HelmRelease driven under the hood: triage = check the install command output, then the HelmReleases/platform app pods in the kommander namespace, and verify registry reachability (air gap again). Small environment failures are typically resource exhaustion: the default platform app stack needs the Pro/Ultimate management cluster minimums from Guide 01 §1.6.

§Section 2 in one breath

nkp create cluster <provider> with the right flags builds the cluster through CAPI; anything flags cannot express becomes a dry run manifest you edit at the correct CAPI resource and apply; diagnosis walks the Cluster→Machine ownership chain. Then nkp install kommander with an installer config puts the fleet layer on the management cluster, you license it to the right tier, and small environments trim the platform app set.

§Self check

1. You need a worker pool of 8 nodes with extra RAM while the CLI default gives you 4 uniform workers. Which two CAPI resources are involved in expressing that?

2. nkp create cluster nutanix hangs; Machines sit in Provisioning. Where do you look first and why?

3. What is the purpose of --self-managed on a management cluster build?

4. A Customer wants only monitoring, no logging stack, on a resource constrained management cluster. What mechanism delivers that during the Kommander install?

5. Which install step does the license get applied at, and what does Ultimate unlock that Pro does not?