> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy and Troubleshoot Workloads

> Select Kubernetes workloads based on how your business runs, submit YAML, and troubleshoot runtime issues through status, details, and Logs.

CKS clusters support running different types of workloads using Pods, Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs. Before deployment, select the workload type based on whether the task needs to run continuously, requires stable identities, node-level replicas, or needs to be scheduled periodically.

## Select Workload Type

| Workload | Applicable Scenario |
| - | - |
| Pod | Validating images, debugging commands, or running temporary tasks. For long-running services, prioritize workloads managed by controllers. |
| Deployment | Runs stateless services and maintains the desired number of Pods through replicas. |
| StatefulSet | Runs stateful services that require stable network identities or persistent storage. |
| DaemonSet | Runs one Pod on each matching node, for example, for log collection, node monitoring, or node-level agents. |
| Job | Runs one-time tasks that exit upon completion. |
| CronJob | Creates and runs Jobs on a scheduled basis. |

## Prepare Workload Runtime Conditions

Based on the workload configuration, first prepare the resources required immediately after submission:

* Ensure that the target namespace has been created.
* If runtime configuration or sensitive information needs to be read, first create a ConfigMap or Secret in the same namespace.
* If data needs to be retained, first create a PVC in the same namespace and ensure that the PVC status is `Bound`.
* If a private image needs to be pulled, prepare the image access credentials required by the workload.
* If GPU, RDMA, Ingress, or other extended capabilities are required, ensure that the corresponding cluster components are installed and operating normally.

## Prepare the Workload YAML

Prepare the YAML based on the selected workload type, and adjust the configuration according to the business image, namespace, resource specifications, environment variables, and storage mount requirements.

**Pod**

Pods are suitable for validating images, debugging commands, or running temporary tasks. For long-running services, use a Deployment, StatefulSet, or DaemonSet for management.

```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: default
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
        - containerPort: 80
```

**Deployment**

A Deployment is suitable for stateless services and can control the number of Pods through the number of replicas.

```yaml theme={null}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80
```

**StatefulSet**

StatefulSets are suitable for stateful services that require stable network identities or persistent storage. The Headless Service in this example provides stable network identities for the StatefulSet.

```yaml theme={null}
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  ports:
    - port: 80
      name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: default
spec:
  serviceName: nginx
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80
              name: web
```

**DaemonSet**

A DaemonSet is suitable for running one Pod on each matching node, for example, for log collection, node monitoring, or node-level agents.

```yaml theme={null}
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: default
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
        - name: fluentd
          image: fluent/fluentd:v1.16
```

**Job**

Jobs are suitable for one-time tasks. After a task is completed, the Pod is retained for a period of time to facilitate viewing its status and Logs.

```yaml theme={null}
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
  namespace: default
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: pi
          image: perl:5.34.0
          command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  backoffLimit: 4
```

**CronJob**

CronJob is suitable for tasks that run on a scheduled basis. Adjust `schedule` as needed.

```yaml theme={null}
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
  namespace: default
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: hello
              image: busybox:1.28
              command:
                - /bin/sh
                - -c
                - date; echo Hello from the Kubernetes cluster
```

## Submit Workload

1. Log in to the [GPU Cloud console](https://console.scitix.ai/gpu-cloud/home) and go to the **Clusters** page.

2. Click the name of the target cluster to access the cluster workspace.

3. In the left navigation pane, go to the **Workloads** page.

4. Switch to the tab corresponding to the selected workload type.

5. Use the creation entry provided on the page, select a namespace, enter the prepared YAML, and then submit to create.

6. Return to the relevant tab and verify that the newly created resource is displayed.

## Confirm Workload Status

1. On the **Workloads** page, switch to the tab for the corresponding resource.

2. Search for the target resource as needed.

3. Confirm the workload status. When checking Pods, focus on the node, namespace, container readiness, and restart count.

If the workload is not running as expected, check the Pod logs, resource details, and events in the following order.

## Troubleshoot Workloads That Are Not Running Properly

### View Pod Logs

1. On the **Pods** tab, locate the target pod.

2. In the **Actions** column, click **Log**.

3. View the Pod logs.

To filter logs by time range, keyword, or field, go to the **Logs** page. For more information, see [Querying and Analyzing Logs](https://docs.scitix.ai/gpu-cloud/log/query-logs.md).

### View Resource Details and Events

1. On the corresponding resource tab, locate the target workload.

2. In the **Actions** column, click **View**.

3. View resource configuration, status, events, and other information.

If a Pod remains in `Pending` status for an extended period or restarts frequently, check the node status, PVC binding status, Logs, and Monitor metrics to identify the cause.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.