NKP Architecture and Cluster Lifecycle
NCP-CN treats NKP as a Cluster API-driven platform, not a single Kubernetes distribution. Questions probe how the management cluster differs from workload clusters, which provider does what, and the order of lifecycle operations.
Two tiers, one control plane
- The NKP management cluster runs Kommander (UI, centralized auth, policy, observability) and the Cluster API controllers. It does not exist to run your applications.
- Workload clusters are declarative objects: a Cluster plus infrastructure and control-plane machines. The provider - CAPX for AHV, CAPA for AWS, CAPV for vSphere, CAPZ for Azure - reconciles real infrastructure.
- Konvoy bootstraps each cluster with kubeadm and a curated addon set: Calico CNI, MetalLB, the Nutanix CSI driver, and a Prometheus/Grafana/Loki stack.
Lifecycle rules worth memorizing
- A node pool is a MachineDeployment. Scale by editing replicas; upgrade by changing the Kubernetes version in the cluster spec, which triggers a rolling replacement.
- Upgrade the management cluster before workload clusters - it owns the CAPI controllers and must understand the newer API.
- Disconnected sites need an internal registry, mirrored images, and the air-gapped install path.
- Deletion removes the CAPI object first; lingering provider finalizers mean infrastructure was not cleaned up.
Worked example
A 1.28→1.29 workload upgrade stalls with machines stuck in Draining. Reason it out: the management cluster is healthy, so look at the node - a PodDisruptionBudget with minAvailable equal to replicas blocks eviction, and the MachineDeployment rollout waits. Fix the PDB, and the rollout completes.
Traps
Equating NKP with NKE/Karbon; assuming tenant apps run on the management cluster; upgrading workload clusters first and hitting API skew; forgetting that a down management cluster stops all lifecycle reconciliation.