NCP-CN 6.10 Study Guide · Section 4 of 4
Kommander's whole reason to exist: many clusters, many teams, one control plane. Workspaces and projects are the two nouns this section turns on; get their boundary crisp and half the questions answer themselves.
Workspace = the big isolation box. Holds CLUSTERS (deployed or attached), workspace level platform applications, and workspace RBAC. Think business unit, environment tier, or tenant.
Project = a slice INSIDE a workspace. Selects some/all of the workspace's clusters and projects a shared set of NAMESPACES onto them, with project RBAC, quotas/limit ranges, project apps, and GitOps continuous deployment. Think team or application.
Hierarchy: Global → Workspace → Project → (namespaces on clusters). Apps and RBAC can be set at each level and flow downward. Multi tenancy = workspaces per tenant, dedicated login URLs per tenant.
Create/delete workspaces; assign each workload cluster to exactly one workspace; configure the infrastructure provider at workspace level (the credentials/endpoint Kommander uses to deploy clusters there, e.g. a Nutanix/Prism Central provider); set workspace level access control (roles federate to member clusters); deploy workspace applications (enabled per workspace, optionally per cluster). Insights (Ultimate) gives anomaly/health intelligence across the fleet; it has its own license install.
From Kommander (UI or nkp CLI) you deploy managed clusters into a workspace, on whatever infrastructure provider the workspace has configured (Nutanix, vSphere, AWS, even VCD via the UI). The target provider determines the deployment parameters (Guide 01 §1.6) and what is possible. Lifecycle of a managed cluster (upgrade, scale, delete) is fully Kommander's.
Troubleshooting deployment of a workload cluster = Guide 02's CAPI chain walk, but initiated from the management cluster; plus workspace level causes: wrong/expired infrastructure provider credentials, exhausted IP pools, image missing on that provider.
Attach brings an EXISTING cluster (built elsewhere: EKS, AKS, GKE, or any conformant Kubernetes) under Kommander management. Attached ≠ managed:
| Capability | Managed (NKP deployed) | Attached (existing) |
|---|---|---|
| Platform apps, monitoring, RBAC federation | Yes | Yes |
| Lifecycle (upgrade/scale nodes) via Kommander | Yes | No, its own platform owns lifecycle |
Attachment requirements: network reachability from the management cluster (or a tunneled attachment when the cluster is behind NAT/firewall and cannot be reached directly), a kubeconfig with sufficient privilege, cloud specifics for EKS (prepare the cluster, IAM/auth wiring), and a default StorageClass so platform apps that need persistence can provision volumes.
Decommissioning logic: detach an attached cluster (it keeps running, Kommander just stops managing it; platform apps Kommander federated may be left behind/cleaned), delete a managed cluster (the cluster and its provider resources are destroyed; "Delete an NKP Cluster with One Command" or via the Kommander dashboard GUI, including deleting EKS clusters from the UI when they were NKP deployed).
Troubleshooting stuck detach/delete: finalizers holding resources, provider credentials no longer valid (cannot destroy what it cannot reach), or order of operations (delete workload clusters before the management cluster that owns them).
Inside a workspace, a project targets selected clusters, creating the project namespace(s) on each. Project level features the blueprint names:
| Feature | What it gives you |
|---|---|
| Project access control | Roles/bindings scoped to the project's namespaces across its clusters |
| Project applications | Apps deployed to the project's clusters/namespaces |
| Quotas + limit ranges | Resource ceilings per project (CPU/mem/object counts), federated to all member clusters |
| Continuous Deployment (GitOps) | Flux based: point the project at a Git repo and manifests sync to project clusters automatically |
| Federated resources | ConfigMaps/Secrets/etc. stamped identically across the project's clusters |
The curated catalog (monitoring, logging, security, ingress, backup...) Kommander deploys and manages. The blueprint's five knowledge bullets in plain words:
| Bullet | Means |
|---|---|
| Dependencies | Apps require other apps (Grafana needs Prometheus; logging dashboards need Loki). Enabling an app pulls or requires its dependencies; disabling one can break dependents. |
| Customize from the dashboard | Per app configuration overrides (values YAML) edited in the Kommander UI at workspace/cluster level |
| Global vs cluster scope | Configuration set once for everywhere vs overridden for a single cluster; cluster scope wins for that cluster |
| Troubleshoot configurations | HelmRelease/Flux status for the app, values syntax errors, dependency not enabled, resources insufficient |
| CLI control | Enable/disable/modify apps via CLI, not just UI ("Deploy Platform Applications Using CLI") |
Workspaces hold clusters (deployed via the workspace's infrastructure provider, or attached with reachability + kubeconfig + default StorageClass, tunneled when unreachable, Ultimate when external). Projects slice workspaces into namespace level team spaces with RBAC, quotas, apps, federation, and GitOps CD. Platform applications deploy at global/workspace/cluster scope with dependencies, customized via overrides in UI or CLI. Detach releases attached clusters; delete destroys managed ones.
1. Two Customers (tenants) on one NKP estate, each with prod + dev clusters and their own admins. Sketch the workspace/project layout.
2. An attached GKE cluster's logging apps will not start; volumes Pending. First thing you check?
3. What can Kommander do to a managed cluster that it cannot do to an attached one?
4. A team needs a CPU ceiling and Git driven deployments across three clusters in a workspace. Which construct and which two features?
5. Monitoring config must apply fleet wide except one cluster that needs different alert endpoints. How?