NCP-CN 6.10 Study Guide · 00 of 04
The exam assumes CKA level knowledge. You do not need CKA depth to pass NCP-CN, but you need every concept on this page cold, because NKP vocabulary is built on top of it. This is the minimum viable Kubernetes, scoped to exactly what the blueprint leans on.
Kubernetes is a desired state machine. You write what you want (YAML manifests), submit it to the API server, and controllers loop forever making reality match. You never tell Kubernetes how, only what.
Control plane: API server (front door), etcd (the database of desired state), scheduler (picks nodes for pods), controller manager (the reconcile loops).
Worker nodes: kubelet (node agent that runs pods), container runtime (containerd), kube-proxy (service networking).
Cluster and MachineDeployment resources into real VMs on AHV. When the exam asks how to diagnose a stuck deployment, the answer shape is "inspect the CAPI resources and find which reconcile is failing."| Object | What it is |
|---|---|
| Pod | Smallest deployable unit: one or more containers sharing network and storage. Ephemeral; you almost never create bare pods. |
| ReplicaSet | Keeps N identical pod replicas running. Managed for you by Deployments. |
| Deployment | THE workload object: declares image + replicas, handles rolling updates and rollback. What you use for stateless apps. |
| StatefulSet | Like a Deployment but with stable identity and per replica storage. Databases, Loki, Prometheus live here. |
| DaemonSet | One pod on every node. Log shippers and node agents (you will meet these in the NKP logging stack). |
| Namespace | Logical partition of a cluster for grouping objects + scoping RBAC and quotas. NKP Projects map onto namespaces. |
Pods die and get new IPs. A Service is a stable virtual IP + DNS name in front of a set of pods (selected by labels).
| Service type | Use |
|---|---|
| ClusterIP | Default. Reachable inside the cluster only. |
| NodePort | Exposes the service on a port of every node. |
| LoadBalancer | Asks the infrastructure for a real load balanced IP. On NKP/AHV this is MetalLB style address pools; in cloud it is the cloud LB. |
Ingress routes HTTP by hostname/path to services through an ingress controller (NKP ships Traefik as a platform app). Gatekeeper (OPA) enforces admission policies; the blueprint names it under security.
Four objects, two scopes. This is mechanical once you see the grid:
| Object | Scope | What it does |
|---|---|---|
| Role | One namespace | A bundle of allowed verbs on resources (get/list pods, create deployments...) |
| ClusterRole | Whole cluster | Same idea, cluster wide (or reusable across namespaces) |
| RoleBinding | One namespace | Grants a Role (or ClusterRole) to a user/group/serviceaccount IN that namespace |
| ClusterRoleBinding | Whole cluster | Grants a ClusterRole everywhere |
Authentication (who are you) is separate from authorization (what may you do). Kubernetes does not store users; identity comes from certificates, tokens, or an OIDC provider. NKP embeds Dex as the OIDC broker that federates LDAP/SAML/OIDC upstreams, and then layers Kommander roles (workspace/project level) on top of cluster roles.
The chain, left to right: a pod mounts a PersistentVolumeClaim (a request: "8Gi, ReadWriteOnce"), the claim binds a PersistentVolume (an actual piece of storage), and a StorageClass is the recipe that dynamically provisions PVs on demand via a CSI driver.
On NKP over Nutanix infrastructure, the Nutanix CSI driver provisions from Nutanix Volumes (block) or Nutanix Files. A default StorageClass (annotated storageclass.kubernetes.io/is-default-class) is what makes PVCs without an explicit class Just Work. VolumeSnapshotClasses define how CSI snapshots are taken, which is what Velero leans on for backup.
Helm is the package manager: a chart is a templated bundle of manifests, installed as a release, customized through values (YAML). NKP's platform applications (Prometheus, Grafana, Loki, Traefik, Gatekeeper, Velero...) are curated charts that Kommander deploys per workspace or per cluster, with your overrides going into values-shaped config. "Customize a platform application deployment" on the exam means: edit its configuration override, the values, at the right scope (global vs cluster).
CAPI's trick: use Kubernetes to create Kubernetes. Cluster definitions are themselves Kubernetes resources, reconciled by providers that talk to infrastructure (Nutanix, AWS, vSphere...).
| CAPI piece | Meaning |
|---|---|
| Bootstrap cluster | A temporary local kind cluster whose only job is to run CAPI controllers long enough to create your real management cluster, then it pivots and is deleted. Objective 1.2. |
| Management cluster | The permanent cluster running CAPI controllers + Kommander; creates and manages workload clusters. |
| Cluster / MachineDeployment / Machine | The CRDs describing a cluster, its node pools, and individual nodes. Scaling a node pool = editing a MachineDeployment. |
| Infrastructure provider | The plugin for the target platform (CAPX for Nutanix/AHV). Determines what parameters a cluster build needs. |
# contexts: which cluster am I talking to (kubeconfig)
kubectl config get-contexts && kubectl config use-context <name>
# the universal triage loop
kubectl get pods -A # what exists, what is crashing
kubectl describe pod <pod> -n <ns> # events: WHY it is failing
kubectl logs <pod> -n <ns> [-c container] [--previous]
# apply desired state / inspect it
kubectl apply -f thing.yaml
kubectl get deploy,svc,pvc -n <ns> -o wide
kubectl get <resource> <name> -o yaml # the full truth
# RBAC sanity check
kubectl auth can-i create deployments -n team-a --as user@blueally.comLab reps (do this, 30 min): brew install kind kubectl, then kind create cluster. Deploy nginx as a Deployment, expose it as a Service, scale it, kill a pod and watch the ReplicaSet replace it, create a PVC against the default StorageClass, run the triage loop on something broken (set a bad image tag). That hour of muscle memory pays for itself across the whole exam. Bonus: a kind cluster is literally what an NKP bootstrap cluster is.
1. A pod needs storage that survives restarts. Name the three objects in the chain and which one a platform admin pre defines.
2. A user can list pods in namespace team-a but nowhere else. Which two RBAC objects make that true?
3. What is the bootstrap cluster for, and what happens to it after the management cluster exists?
4. Scaling a node pool from 3 to 5 workers edits which CAPI resource?
5. Platform apps are customized through what mechanism, and at which two scopes?
Answers are all on this page. If any of these feel shaky, redo that section before Guide 01; everything downstream assumes them.