Polyaxon v3 is coming →
Crusoe Cloud

Validate Crusoe Managed Kubernetes with Polyaxon

Crusoe Managed Kubernetes uses a shared-responsibility model. Crusoe operates the underlying cloud and control plane, while your platform team still makes explicit choices for node pools, access, add-ons, storage use, workload policy, and some network configuration.

Outcome

A Crusoe capacity class connected to Polyaxon and validated through the same queue, namespace, GPU, and storage path production workloads use.

Start the guideConnect a compute cluster to Polyaxon

Infrastructure responsibilities

Crusoe operates the foundation

Crusoe manages the cloud infrastructure and Kubernetes control plane within its documented service boundary.

Your platform team owns application policy

Node-pool configuration, cluster access, add-ons, storage usage, workload security, and lifecycle choices remain shared or customer-owned responsibilities.

Polyaxon connects the compute cluster

Installing Polyaxon Agent (compute cluster) connects this Kubernetes cluster to the control plane. Its queues and presets apply placement, connections, permissions, and lifecycle controls.

Prerequisites

  • A Crusoe Managed Kubernetes cluster with the required GPU node pool and NVIDIA components.
  • Reviewed cluster access, network, storage class, registry, DNS, and workload identity configuration.
  • The cluster connected to Polyaxon by installing Polyaxon Agent (compute cluster), with namespace permissions and a queue or preset selecting that node pool.

Validate the infrastructure

  1. 1

    Exercise the Crusoe node pool

    Submit a small GPU and storage check through the same queue and namespace that will carry production workloads.

    version: 1.1kind: componentname: gpu-readinessrun:  kind: job  container:    image: nvidia/cuda:12.8.1-base-ubuntu22.04    command: ["bash", "-lc"]    args: ["nvidia-smi"]    resources:      limits:        nvidia.com/gpu: "1"

    Keep Crusoe placement in the selected queue or preset. This published CUDA image checks GPU visibility only; pin a tag or digest compatible with your driver. Test storage and multi-node networking with separate workload-specific checks.

  2. 2

    Submit the operation

    Run the component through the target Polyaxon project, queue, preset, and approval path.

    polyaxon run -f crusoe-readiness.yaml -q agent-name/queue-name
  3. 3

    Validate the operational path

    Confirm placement, device access, storage, secrets, logs, and artifacts before enabling the pool for training or inference.

    polyaxon ops dashboard

Production checklist

Record the owner for each item in Crusoe's shared-responsibility model before production rollout.
Keep cluster, node-pool, add-on, compute-cluster connection, queue, and preset configuration in version control.
Revalidate GPU, storage, identity, DNS, and network behavior after cluster or node-pool changes.
Decide whether scaling is managed through fixed node pools or an AutoClusters configuration before setting queue expectations.
Run a collective communication test on the exact nodes and interfaces used by distributed training.

Troubleshooting

The GPU resource is missing

Check node-pool readiness, NVIDIA component status, kubelet capacity, and whether the queue selector and tolerations match the GPU nodes.

The operation cannot mount its volume

Verify the requested storage class, CSI driver state, availability-zone constraints, permissions, and whether the workload expects persistent or local storage.

The connected compute cluster cannot submit or collect logs

Verify the Polyaxon Agent deployment, cluster access, namespace RBAC, network policy, registry credentials, queue routing, and control-plane connectivity.

Sources

Official platform, library, model, and Polyaxon references used by this guide.

Continue

Compare AI platformsExplore GPU orchestration