GPU Container architecture
How a GPU Container Job runs on your cluster, from the job starting to the shell you open on it.
A GPU Container Job runs your workload inside a KubeVirt virtual machine instance (VMI) on a single node. The VMI claims one or more whole GPUs through passthrough. You open an interactive shell into it and use it like a remote machine.
The following diagram shows how a job request reaches your cluster, and the separate path your shell takes into the VMI. A node can hold many pods, each running a different job.
How a job starts
When you submit a job from cosmicac-ui or cosmicac-cli, cosmicac-app-node authenticates the request and forwards it to cosmicac-wrk-ork. The orchestrator allocates the GPUs the job needs on one node, then hands the job to cosmicac-wrk-server-k8s-nvidia. That worker creates the job's Kubernetes resources through your cluster's API server, and Kubernetes creates a pod holding the VMI. cosmicac-wrk-agent-instance runs inside that VMI.
How a shell connects
Once the VMI is running, cosmicac-cli connects directly to cosmicac-wrk-agent-instance over hyperswarm-ssh, part of the Holepunch peer-to-peer stack. cosmicac-app-node isn't part of that connection, so the interactive session doesn't depend on the control path that submitted the job.
Next steps
- GPU Container Job for what the job is and when to use one
- Connect to a GPU Container Job
- Architecture for the components and how CosmicAC reaches your cluster