NCP-CN 6.10 Study Guide · Section 1 of 4
Six objectives, one story: everything that has to exist BEFORE nkp create cluster can succeed. The exam loves this section's air-gapped angle because it is where real enterprise deployments hurt.
The problem: an air-gapped environment cannot pull images from the internet. NKP is delivered as downloadable bundles (container images + charts), and seeding means pushing those bundles into a private registry that lives inside the gap, so every cluster component can pull from it instead of from public registries.
Workflow shape: download the NKP air-gapped bundle on a connected machine → transfer it across the gap (the classic sneakernet/controlled transfer) → run the NKP CLI push/seed command pointing at your registry URL with credentials → verify images are present → reference that registry in every subsequent install command.
What the seeding command needs (parameters): the bundle location, the destination registry URL, registry username/password (or CA/cert material for TLS), and the registry must be reachable from the bastion AND from all future cluster nodes.
Troubleshooting buckets: authentication failures (bad creds, expired tokens), TLS trust failures (self signed registry cert not trusted by the pushing host or by nodes), network reachability (DNS, firewall, proxy), and storage exhaustion on the registry (bundles are large).
NKP builds Kubernetes with Kubernetes (CAPI, Guide 00 §7). The bootstrap cluster is a temporary, local, kind based cluster the NKP CLI spins up on your bastion/installer machine. Its only job: run the CAPI controllers that create the real management cluster on the target infrastructure. Once the management cluster is up, CAPI state pivots (moves) into it, and the bootstrap cluster is deleted.
Purpose questions answer: "why does NKP need Docker/a container runtime on the install host?" Because the bootstrap cluster runs there. Parameter questions: the kubeconfig of the bootstrap cluster can be written out (--kubeconfig style output) so you can inspect it while it works; air-gapped bootstrap needs the registry mirror flags so even the bootstrap images come from your seeded registry.
Troubleshooting buckets: the install host lacks resources or a working container runtime, the bootstrap cluster cannot reach the target infrastructure APIs (Prism Central credentials/URL wrong, network), or air-gapped image pulls fail (registry mirror not configured, untrusted CA).
| Tier | Aimed at | Headline capabilities |
|---|---|---|
| NKP Starter | Getting started, single cluster basics | Core Kubernetes cluster management on Nutanix; entry feature set |
| NKP Pro | Production single/multi cluster on Nutanix | Adds the production platform application stack (monitoring, logging, backup) for managed clusters |
| NKP Ultimate | Fleet scale + heterogeneous estates | Full multi cluster fleet management: multi tenancy with workspaces/projects, attach EXTERNAL clusters (EKS/AKS/GKE), NKP Insights, the whole Kommander surface |
Alignment heuristic for scenario questions: the moment a scenario says attach an existing EKS/AKS/GKE cluster, multiple teams/tenants, centralized fleet dashboards, or Insights, the answer is Ultimate. Single Nutanix cluster with production observability reads as Pro. Kicking tires reads as Starter. Licenses are obtained through Nutanix licensing/support portal flows and applied in Kommander (add/remove license).
The bastion is the hardened jump machine inside the restricted network from which you run the NKP CLI and the whole install. In air-gapped designs it is usually the only thing that ever touched the outside world's artifacts.
It needs: a supported Linux OS, a container runtime (for the bootstrap cluster), the NKP CLI + tooling, enough CPU/RAM/disk for bootstrap work, and network lines of sight to: Prism Central (to drive infrastructure), the private registry (to push/pull), and the node subnets the clusters will live on. SSH key access to nodes for pre provisioned installs.
Cluster nodes need an OS image with the right Kubernetes payload baked in. Two CLI tools, one idea:
| Tool | What it does |
|---|---|
| KIB · Konvoy Image Builder | Bakes machine images for cluster nodes across providers (Nutanix/AHV, vSphere, AWS, Azure...). Output: a template/AMI/image with containerd, kubelet, and OS hardening preinstalled. Also runs node preparation for pre provisioned hosts. |
| NIB · Nutanix Image Builder | The Nutanix flavored image building path for AHV images specifically (blueprint names both; know NIB = building machine images, KIB = the Konvoy lineage tool, also used to prepare nodes). |
Prereqs/minimums: a base OS from the supported OS list, access to the provider (to upload the image), and for air-gapped image builds: local package repos / override files instead of public ones, because the builder cannot reach upstream repos. Customization happens through override files (e.g., FIPS variants, custom packages, vSphere FIPS CAPI VM templates).
Before building a cluster, gather the provider specific facts. The exam phrases this as "identify parameters associated with building a cluster on a target provider," in three buckets:
| Bucket | Nutanix/AHV examples |
|---|---|
| Networking | Which subnet(s) nodes join, control plane endpoint/VIP, load balancer IP ranges (MetalLB pool), DNS, no overlap with pod/service CIDRs |
| Connectivity | Prism Central URL + credentials, registry reachability, proxy settings if any, SSH keys for node access |
| Storage | Which storage container backs the CSI driver, default StorageClass intent, file vs volumes mode |
General resource floor: NKP publishes minimum CPU/RAM/disk per control plane and worker node, and Pro/Ultimate management clusters have their own larger minimums (Kommander's platform apps are not free). Supported OS list constrains image choice.
Air gap? Seed a registry first. The NKP CLI runs on a bastion, spins a throwaway kind bootstrap cluster, which uses CAPI to build the real management cluster from machine images you baked with KIB/NIB, on a provider whose networking/connectivity/storage parameters you gathered up front, under a license tier matched to the use case. Every objective in this section is a piece of that sentence.
1. Air-gapped install: name the order, registry seeding vs bootstrap cluster vs management cluster.
2. Customer wants to attach two existing EKS clusters and give four teams isolated self service. Which license tier and why?
3. Nodes fail to pull images after a successful seed from the bastion. Two most likely causes?
4. What is on a bastion host that makes the bootstrap cluster possible?
5. What changes about a KIB build when the environment is air-gapped?