Multi-cluster Local Development with Helmfile
Multi-cluster Local Development with Helmfile
Install the NVCF self-hosted control plane on one local k3d cluster and the NVCA operator on a separately registered compute cluster, all driven by the documented Helmfile workflow.
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:
Topology
Cross-cluster traffic from the compute cluster uses the same service-DNS
hostnames as the local stack values. During topology bootstrap,
tools/ncp-local-cluster/scripts/configure-control-plane-endpoints.sh
creates compute-cluster alias Services and Endpoints for those names, and the
Endpoints point at the control-plane k3d load balancer:
http://api.sis.svc.cluster.local:8080http://reval.nvcf.svc.cluster.local:8080nats://nats.nats-system.svc.cluster.local:4222http://ess-api.ess.svc.cluster.local:8080http://invocation.nvcf.svc.cluster.local:8080api.nvcf.svc.cluster.local:9090
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 9 and 10 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 multi-cluster topology
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
single-cluster topology running:
Step 2: Author the multi-cluster Helmfile environment files
The values-driven Helmfile path has no control-plane profile; the operator must author topology-correct URLs in the environment files. Use the multi-cluster fixtures for this flow:
Substitute your NGC org and team:
The multi-cluster fixture intentionally uses service-DNS hostnames such as
api.sis.svc.cluster.local and invocation.nvcf.svc.cluster.local. In this
split topology those names resolve on the compute cluster because Step 1
created alias Services and Endpoints that forward to the control-plane load
balancer. Do not replace these values with topology-specific .test
hostnames.
Step 3: Author the secrets file
Step 4: Set kubectl context to the control-plane cluster
Helmfile install runs against the ambient kubectl context. Switch to the control-plane cluster so the install lands there:
Step 5: Pre-create the image pull secret in NVCF namespaces (cp cluster)
Step 6: Install the control plane
The 18 standard helm releases land on k3d-ncp-local-cp (see the
single-cluster Helmfile page for the full release list).
Step 7: Switch kubectl context to the compute cluster (CRITICAL)
This single context switch is the most error-prone step in the multi-cluster
flow. The next step’s nvcf-cli cluster register (run internally by
make register-cluster) auto-discovers the target cluster’s OIDC issuer
and JWKS by running a probe Job in the CURRENT kubectl context. If you skip
the switch, the control-plane cluster’s JWKS gets registered as the compute
cluster’s identity, and the compute agent’s PSAT tokens 401 against ICMS at
runtime.
Step 8: Pre-create the image pull secret on the compute cluster
Step 9: Register the compute cluster
make register-cluster runs nvcf-cli init internally before
cluster register, so this flow does not need a separate init step.
The target writes the registration handoff file to
deploy/stacks/nvcf-compute-plane/registration/ncp-local-compute-1-register-values.yaml.
The template, install, and apply targets copy that file into
deploy/stacks/nvcf-compute-plane/out/ before running Helmfile.
Step 10: Install the NVCA operator on the compute cluster
This uses the compute-plane local-bdd.yaml file created in Step 2.
Step 11: Verify
The NVCFBackend resource is created on the compute cluster, not the control-plane cluster. Use the compute cluster context for all verification:
Confirm the control-plane API is reachable (from the host):
Teardown
Remove the helm releases on both clusters but keep the topology (stack-only):
Or destroy the whole topology: