Interacting with Workloads Using the Cluster API
Use the Cluster API for live, cluster-scoped operations on running workloads: checking cluster/workload status, streaming and downloading logs, executing commands, attaching to containers, and forwarding ports. For creating or managing workloads across a tenant, use the Control plane API.
The API is exposed per cluster at https://<cluster-fqdn>/cluster-api/. The interactive endpoints (exec, attach, port-forward, and both logs modes) use WebSocket; status, logs/download, and the cluster status endpoint use standard HTTPS. All endpoints require a bearer token (JWT), refer to How to authenticate to the API.
Before You Start
The Cluster API runs on each NVIDIA Run:ai cluster, not on the control plane. Before making a call, you need:
- The cluster FQDN - Each cluster exposes the API at
https://<cluster-fqdn>/cluster-api/. Find the FQDN in the NVIDIA Run:ai UI under Clusters → your cluster → Connection details, or from your platform admin. - Network reachability to the cluster - The Cluster API endpoint must be reachable from the machine making the call. If your cluster is behind a VPN or private network, you must be on that network.
- A bearer token (JWT) with the right permissions - All endpoints require a JWT. The token must be associated with a user or application that has permission to access the project and workload in question. Refer to How to authenticate to the API for how to obtain a token.
- Valid project and workload identifiers - Most endpoints require the project name, workload type, workload framework, and workload name in the path. The identifiers must match an existing, running workload in that project. Refer to Common path parameters below.
Common Path Parameters
Most endpoints take the same four path parameters. They are documented once here and referenced by each endpoint below.
CRD to Path Parameter Mapping
The cluster-api resolves the path parameters to an NVIDIA Run:ai V2 CRD inside the project namespace (runai-{project}). Use the table below to pick the right workloadType, workloadFramework, and workloadName for your workload.
Tip
For finding the right name:
- For NVIDIA Run:ai-native workloads (workspace / training / distributed / inference): the name in the UI matches the
workloadNamedirectly. - For third-party CRDs: run
kubectl get externalworkloads -n runai-{project}to list the auto-generatedew-…names, or look at the workload entry in the NVIDIA Run:ai UI.
Note
GET /cluster-api/status is cluster-scoped and does not take these parameters. All other endpoints are project- and workload-scoped.
Request and Response Conventions
Base URL
Replace <cluster-fqdn> with your cluster’s FQDN in every example:
Throughout this guide, examples use $CLUSTER for the FQDN and $TOKEN for the bearer token:
Authentication
Every request must include the bearer token in the Authorization header:
For WebSocket endpoints (exec, attach, port-forward, logs), the same header is sent during the WebSocket upgrade handshake.
Content Types
- JSON endpoints return
application/json. - The
logs/downloadendpoint returnsapplication/octet-stream. - WebSocket log frames carry log-line payloads as binary messages.
Connection Behavior
The following endpoints use WebSocket connections and have different semantics from standard REST endpoints:
logs(both one-shot andfollow=truemodes)execattachport-forward
WebSocket examples in this guide use websocat. Install with cargo install websocat or brew install websocat. Equivalent calls work from any WebSocket-capable client (Python websockets, Node ws, Go gorilla/websocket).
Upgrade Flow
Clients issue a GET request with the standard WebSocket upgrade headers (Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Key, Sec-WebSocket-Version: 13). The bearer token is passed in Authorization on the handshake request.
On success, the server responds with 101 Switching Protocols. On authentication failure, the server responds with 401 before upgrading.
Keep-Alive and Timeouts
- The server sends periodic ping frames every 30 seconds. Clients must respond with pong frames to keep the connection alive.
- Idle connections (no traffic for 5 minutes) are closed by the server.
- Long-running sessions (
exec,attach) have no maximum duration as long as pings are acknowledged.
Termination
The connection closes when:
- The client closes the WebSocket.
- The target pod or container terminates.
- The bearer token expires (server closes with code
1008). - Idle timeout is reached.
Clients should handle abrupt disconnection and reconnect if needed. No replay is provided: on reconnect, only new log lines or output are delivered.
Errors
All endpoints return standard HTTP status codes. Error responses have the following JSON shape:
Common Error Codes
For WebSocket endpoints, authentication and permission errors are returned on the HTTP handshake (before upgrade). Errors during an active stream are reported through WebSocket close codes:
Endpoints
Cluster Status
Returns the cluster status as a JSON object, including the version and the state of features within the cluster.
Example
Response:
Workload Status
Returns the workload status as a JSON object with a status field carrying the workload phase.
Path Parameters: projectName, workloadType, workloadFramework, workloadName, refer to Common path parameters for values and the CRD-mapping table.
Example
Response:
Logs
Read the logs of a container in a pod. If the pod has multiple containers, the container is auto-selected if the container name is not provided.
The logs endpoint is WebSocket-only, in both one-shot and follow modes. Plain HTTPS GET returns HTTP 426 Upgrade Required. Each log line is delivered as a binary WebSocket message. In one-shot mode (follow=false or omitted), the server closes the connection with code 1000 after delivering the requested range; in follow mode, the connection stays open and new lines are pushed as they arrive.
Path Parameters: projectName, workloadType, workloadFramework, workloadName, refer to Common path parameters.
Query Parameters
Example (one-shot)
Example (follow / stream)
Logs Download
Download the logs for a container in a pod as a file. If the pod has multiple containers, the container is auto-selected if the container name is not provided.
Path Parameters: projectName, workloadType, workloadFramework, workloadName, refer to Common path parameters.
Query Parameters
Example
Attach
Attach to a container in a pod.
Tip
Attaching to a container whose primary process is already consuming stdio (for example, an actively-running training job) can fail with 503. Use exec to start a new shell in the same container instead.
Path Parameters: projectName, workloadType, workloadFramework, workloadName, refer to Common path parameters.
Query Parameters
Example
Port Forward
Port forward to the specified pod in the given workload.
To forward more than one port, repeat the port query key (for example ?port=8090&port=8080). Comma-separated lists are not accepted.
Path Parameters: projectName, workloadType, workloadFramework, workloadName, refer to Common path parameters.
Query Parameters
Example (single port)
Example (multiple ports)
Exec
Execute a command in a container.
The command can be passed in two equivalent forms:
- as the
commandquery parameter (URL-encoded base64 of a JSON argv array), or - as the
CommandHTTP header on the WebSocket upgrade (raw base64 of a JSON argv array, no URL-encoding needed).
For example, ["/bin/bash"] base64-encodes to WyIvYmluL2Jhc2giXQ==.
Path Parameters: projectName, workloadType, workloadFramework, workloadName, refer to Common path parameters.
Query Parameters
Example (Command header)
Example (query parameter)
Fetch Workload Object
Note
The following endpoints require cluster v2.26 or later.
These endpoints return a point-in-time snapshot of the Kubernetes object for a workload, one of its child elements, or one of its pods, as read directly from the Kubernetes API server. The response includes the full spec, status, and metadata; metadata.managedFields and the last-applied-configuration annotation are stripped. Use these endpoints for inspection and debugging — for example, to see why a component is degraded or to confirm the exact spec your workload produced after reconciliation.
These endpoints use the v2 path structure, which identifies workloads by UUID rather than by project name and workload type. Obtain the workloadId, elementId, and podId values from the Control Plane API.
Get Workload Object
Returns the Kubernetes custom resource of the top-level workload element.
Path Parameters
Example
Response:
Get Element Object
Returns the Kubernetes object for a specific child element within a workload.
Path Parameters
Example
Response:
Get Pod Object
Returns the Kubernetes Pod object for a specific pod within a workload.
Path Parameters
Example
Response: