External Access to Containers | NVIDIA Run:ai Documentation

Researchers may need to access containers remotely during workload execution. Common use cases include:

Running a Jupyter Notebook inside the container
Connecting PyCharm for remote Python development
Viewing machine learning visualizations using TensorBoard

To enable this access, you must expose the relevant container ports.

Exposing Container Ports

Accessing the containers remotely requires exposing container ports. In Docker, ports are exposed by declaring them when launching the container. NVIDIA Run:ai provides similar functionality within a Kubernetes environment.

Since Kubernetes abstracts the container’s physical location, exposing ports is more complex. Kubernetes supports multiple methods for exposing container ports. For more details, refer to the Kubernetes services and networking documentation.

Method	Description	NVIDIA Run:ai Support
Port Forwarding	Simple port forwarding allows access to the container via local and/or remote port.	Supported natively via Kubernetes
NodePort	Exposes the service on each Node’s IP at a static port (the NodePort). You’ll be able to contact the NodePort service from outside the cluster by requesting `<NODE-IP>:<NODE-PORT>` regardless of which node the container actually resides in.	Supported
LoadBalancer	Exposes the service externally using a cloud provider’s load balancer.	Supported

Access to the Running Workload’s Container

Many tools used by researchers, such as Jupyter, TensorBoard, or VSCode, require remote access to the running workload’s container. In NVIDIA Run:ai, this access is provided through dynamically generated URLs. NVIDIA Run:ai supports two routing models for exposing workloads:

Host-based routing (default)
Path-based routing

Host-Based Routing

By default, NVIDIA Run:ai uses host-based routing to expose workload URLs using subdomains. This allows all workloads to run at the root path, avoiding file path issues and ensuring proper application behavior.

https://project-name-workload-name.<CLUSTER_URL>/

Host-based routing is enabled by default for both Guided Installation and Manual Helm.

For Manual Helm, you still need to configure the required Ingress resource. See Host-Based Routing (Ingress Resource).

Path-Based Routing

Path-based routing uses the Cluster URL provided to dynamically create SSL-secured URLs in the following format:

https://<CLUSTER_URL>/project-name/workload-name

To use path-based routing:

Guided Installation

Manual Helm

Set cluster.workloadRouting: path in your config.yaml - see cluster:

cluster:
  workloadRouting: path

While path-based routing works with applications such as Jupyter Notebooks, it may not be compatible with other applications. Some applications assume they are running at the root file system, so hardcoded file paths and settings within the container may become invalid when running at a path other than the root. For example, if an application expects to access /etc/config.json but is served at /project-name/workspace-name, the file will not be found. This can cause the container to fail or not function as intended.

Note

For existing clusters, changing the routing model affects how workload URLs are generated. Administrators should plan this transition accordingly.

OpenShift Route TLS Termination

On OpenShift, NVIDIA Run:ai exposes a workload’s URL through a Route object. By default, the Route uses edge termination: TLS terminates at the OpenShift Router, and traffic to the pod inside the cluster is plain HTTP.

To terminate TLS inside the pod itself and preserve end-to-end encryption from the client to the workload, set the Route termination policy to passthrough:

Helm

runaiconfig

clusterConfig:
  anyworkload-controller:
    openshiftRouteConfiguration:
      terminationPolicy: passthrough # edge (default) | passthrough

This setting applies cluster-wide to every Route object NVIDIA Run:ai creates, across all workload types.

Prerequisite

With passthrough termination, NVIDIA Run:ai does not provision or manage a TLS certificate for the pod. You must terminate TLS inside the container yourself, for example, using your own certificate mounted as a Kubernetes secret and a web server or sidecar that you own and maintain.

Impact on existing workloads

This setting applies to every Route NVIDIA Run:ai creates, including Routes for workloads that are already running. Switching to passthrough on a cluster where existing workloads serve plain HTTP makes those workloads unreachable until each one terminates TLS inside the pod. Plan this as a cluster-wide change rather than a change scoped to the single workload that requires end-to-end encryption.