AI workload deployment

Capuris AI schedules analysis work across registered compute nodes. Keep the host build reproducible: pin software versions, record GPU-driver compatibility, and validate a small workload before adding production data.

Prepare an AI host

Begin with a supported Linux release, sufficient CPU and memory, approved storage, synchronized time, and network access to Capuris services and package sources. For GPU work, confirm the supported NVIDIA driver, CUDA, and cuDNN combination before installing Python packages.

Create an isolated environment instead of modifying the system Python:

conda create --name capuris-ai python=3.10
conda activate capuris-ai

Install only the libraries required by the workload. A representative data-science environment may include pandas, scikit-learn, matplotlib, a supported deep-learning framework, and GPU packages that match the host driver.

conda install pandas scikit-learn matplotlib
python -m pip install nvidia

These commands are examples, not a compatibility matrix. Use the package versions approved for your Capuris AI release. Direct CUDA or cuDNN installation should be a deliberate fallback when the environment package cannot satisfy the supported stack.

Validate the environment:

1. Confirm the interpreter and package versions.
2. Confirm that the GPU is visible when the workload requires it.
3. Run a small CPU test and a small GPU test.
4. Record the environment definition or lock file.
5. Recreate it on a clean host before using it as a standard image.

Register a worker agent

Install the approved Capuris worker package and configure the controller or bootstrap address, node identity, credentials, and advertised resources. Start the agent, then verify in the management interface that it is connected, healthy, and reporting the expected CPU, memory, GPU, and storage.

If a worker does not connect, check DNS, time, routing, firewall policy, certificate trust, credentials, and service logs. Do not register the same persistent identity on two live nodes.

Use labels to describe scheduling characteristics such as site, GPU type, storage access, or data sensitivity. Keep labels stable and document their meaning.

Organize workloads

The list view is best for exact status, age, namespace, and resource details. The tree view is best for seeing ownership and relationships among controllers, pods, and services.

Namespaces separate workloads and policy. Before deployment, select the correct namespace and confirm its connection, quotas, secrets, storage, and network policy.

Choose the controller based on state and placement needs, not simply familiarity. A stateful analytics component should not be converted to a Deployment without a data and identity plan.

Read workload status

The details view exposes desired and available replicas, placement, restarts, resource use, events, and component-specific statistics. When a workload remains pending, check resource requests, node labels, taints, quotas, storage claims, and image access. When it restarts, inspect events and the previous container log before redeploying.

Balance cluster load

Scheduling works best when requests describe real workload needs.

• Set CPU and memory requests from measured runs.
• Apply limits cautiously; a low memory limit can turn pressure into repeated termination.
• Request GPU resources explicitly.
• Use affinity only when locality is required.
• Use anti-affinity or topology spread for resilience.
• Reserve headroom for system services and burst activity.
• Monitor queue time, node saturation, failed placement, and data-transfer cost.

Moving a job to an idle node may be slower when its input data is remote. Balance compute, storage locality, and network transfer together.

Define a workload manifest

Keep manifests in version control and review them like application code. A minimal manifest should declare identity, namespace, image, command, resource requests, labels, configuration, secrets references, storage, and restart behavior.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: packet-analysis
  namespace: analytics
spec:
  replicas: 1
  selector:
    matchLabels:
      app: packet-analysis
  template:
    metadata:
      labels:
        app: packet-analysis
    spec:
      containers:
        - name: analyzer
          image: <APPROVED_IMAGE>
          resources:
            requests:
              cpu: "2"
              memory: "4Gi"

Replace the placeholder with an image from the approved registry and pin an immutable version or digest.

Apply and remove workloads

Before Apply, review the target namespace and manifest diff. After Apply, watch events until the desired replicas are ready, then validate the application output with a small known dataset.

Delete removes the selected workload object and may remove dependent pods. Persistent volumes, external data, and services can have separate lifecycles. Confirm retention and ownership before deletion, and verify the result instead of assuming that every resource was cleaned up.

For cluster infrastructure and analytics administration, see Insight administration and deployment.