Single-cluster Local Development with Helmfile
Single-cluster Local Development with Helmfile
Install the NVCF self-hosted control plane and the NVCA operator on a single local k3d cluster using the documented Helmfile workflow. Useful when you want to drive the install through the same Make targets used in production.
This setup is for local development only. It uses fake GPUs, a single Cassandra replica, and ephemeral storage. Do not use this for production workloads.
Clone the public repository and run the remaining commands from its root:
Prerequisites
Install the following tools:
-
Docker (running)
-
k3d v5.x or later
-
kubectl -
helm>= 3.12 -
helmfile>= 1.1.0, < 1.2.0 -
helm-diffplugin:helm plugin install https://github.com/databus23/helm-diff -
An NGC API key from ngc.nvidia.com with access to the NVCF chart and image registry.
-
The NGC organization and team slugs that hold the chart/image repository you have access to.
-
nvcf-clibuilt from this repo. Steps 7 and 8 passNVCF_CLI=$(pwd)/nvcf-clito the make targets, so the binary must exist on disk before those steps run:
Export the env vars used below:
Step 1: Bring up the local k3d cluster
The single-cluster (ncp-local) and multi-cluster
(ncp-local-cp + ncp-local-compute-N) topologies both claim host
ports 8080/8443/4222 and cannot coexist. The multi-cluster control plane also
claims host ports 9090 and 10081 for worker-facing API gRPC and the stack-owned
grpc-proxy TCP listener. If you already have the
multi-cluster topology running:
Step 2: Author the Helmfile environment file
The single-cluster fixture
tests/bdd/fixtures/self-managed-local-bdd.yaml is the canonical
starting point. Its nvcaOperator.selfManaged.* URLs use in-cluster DNS
(for example http://api.sis.svc.cluster.local:8080), which is correct here
because compute and control plane share the cluster.
Substitute your NGC org and team in for the placeholders:
Across the two files, the substitutions update global.helm.sources.repository
and global.image.repository. The control-plane file also updates
api.env.NVCF_SIDECARS_LLM_ROUTER_CLIENT_IMAGE. Set
global.imagePullSecrets[0].name if your secret name differs from
nvcr-pull-secret. The compute-plane environment provides the NVCA endpoint
settings consumed by its Helmfile.
Step 3: Author the secrets file
The secrets file is gitignored. Keep your NGC key out of the working tree.
Step 4: Pre-create the image pull secret in NVCF namespaces
Step 5: (Optional) Validate the rendered manifests
The command should exit 0 and its output must not contain Error:.
Step 6: Install the control plane
When this succeeds, the following helm releases are deployed:
Step 7: Register the cluster
make register-cluster runs nvcf-cli init internally before
cluster register, so the Helmfile flow does not need a separate init
step (unlike the CLI flow).
The target writes the registration handoff file to
deploy/stacks/nvcf-compute-plane/registration/ncp-local-register-values.yaml.
The template, install, and apply targets copy that file into
deploy/stacks/nvcf-compute-plane/out/ before running Helmfile.
Step 8: Install the NVCA operator
Step 9: Verify
Wait for the NVCA operator to roll out and the backend to become healthy:
Confirm the control-plane API is reachable:
Teardown
Remove the helm releases but keep the cluster (stack-only):
Or destroy the whole cluster: