# Managing Workloads

> Source: https://parallelworks.com/docs/kubernetes/managing-workloads

# Managing Workloads

The Workloads view provides a unified interface for monitoring and managing Kubernetes workloads across all your connected clusters. You can create new workloads with a guided builder, inspect resource status, view detailed metadata, edit configurations, restart, and delete workloads directly from the platform.

## Navigating the Workloads View

Access the workloads view by navigating to **Kubernetes > Workloads** in the sidebar. The page displays a filterable, sortable table of all workloads across your connected clusters.

## Supported Workload Types

The platform supports the following Kubernetes workload types:

| Type | Description |
|------|-------------|
| **Deployment** | Manages stateless application replicas with rolling updates |
| **StatefulSet** | Manages stateful applications with persistent storage and ordered deployment |
| **DaemonSet** | Ensures a pod runs on all (or selected) nodes in a cluster |
| **Job** | Runs a task to completion with a specified number of completions |
| **CronJob** | Schedules Jobs to run on a recurring cron-based schedule |
| **Pod** | The smallest deployable unit in Kubernetes |
| **ReplicaSet** | Maintains a stable set of replica pods (typically managed by a Deployment) |

## Creating Workloads

Click **Add workload** on the Workloads page to open the guided workload builder. The builder lets you deploy a containerized workload without writing a manifest by hand — the form generates the Kubernetes YAML for you, with a live preview alongside.

### Execution Types

Choose how the workload should run:

| Type | Behavior |
|------|----------|
| **Deployment** | Long-running service that restarts automatically (default) |
| **StatefulSet** | Long-running service with stable identity and storage |
| **Job** | Runs once to completion |
| **CronJob** | Runs on a recurring schedule |
| **Pod** | A single bare pod |

### Configuration

The form adapts to the selected execution type:

- **Common** — Name (lowercase letters, numbers, and hyphens), target cluster, and namespace
- **Deployment / StatefulSet** — Number of replicas
- **CronJob** — Cron schedule expression (e.g., `*/5 * * * *`)
- **Job** — Completions, parallelism, and backoff limit
- **Pod** — Restart policy (`Always`, `OnFailure`, or `Never`)

For each container, you can set the image, command and arguments, CPU and memory requests and limits (e.g., `250m`, `512Mi`), container ports, environment variables, and volume mounts. Volumes can be backed by a PersistentVolumeClaim or an `emptyDir`.

### YAML Preview and Overrides

The right-hand panel shows the manifest generated from your form inputs as you type. If you need settings the form does not cover, click **Edit YAML** to switch to a manual editing mode and adjust the manifest directly before submitting. The manifest is validated before the workload is created.

## List View

The workloads list view presents all workloads in a sortable table. Click any column header to sort by that field.

### Filtering

The filter bar at the top of the table provides several ways to narrow down the displayed workloads:

- **Cluster** -- Select one or more clusters to show workloads from only those clusters. When no cluster is selected, workloads from all connected clusters are shown.
- **Namespace** -- Filter by one or more Kubernetes namespaces.
- **Type** -- Filter by workload type (Deployment, StatefulSet, DaemonSet, Job, CronJob, Pod).
- **Status** -- Filter by workload status (Running, Pending, Failed, Unknown, Completed).
- **Search** -- Type a name to filter workloads by name. The search is case-insensitive and matches partial names.

Use the **Clear all** button to reset all active filters at once.

### Table Columns

Each row in the workloads table displays the following information:

| Column | Description |
|--------|-------------|
| **Name** | The workload name. Click to open the detail view. |
| **Status** | A color-coded status indicator showing the current state of the workload. |
| **Type** | The workload type (Deployment, StatefulSet, etc.). |
| **Cluster** | The cluster where the workload is running (hidden when filtering by a single cluster). |
| **Namespace** | The Kubernetes namespace the workload belongs to. |
| **Pods** | The number of ready pods versus total pods (e.g., `3/3`). |
| **Created** | When the workload was created. |

### Status Indicators

Workload status is shown with a color-coded icon:

- **Ok / Running** -- The workload is healthy and all expected pods are ready.
- **Pending** -- The workload is starting up or waiting for resources.
- **Failed** -- The workload has encountered an error.
- **Completed** -- The workload (Job) has finished successfully.
- **Unknown** -- The status could not be determined.

## Detail View

Click on any workload name in the list to open its detail view. The detail page shows comprehensive information about the selected resource.

### Resource Metadata

The top panel displays key metadata fields that vary by workload type:

**Common fields across all types:**
- Name, Namespace, Resource Version, and Creation Timestamp

**Deployment-specific fields:**
- Replica counts: updated, ready, available, and unavailable

**StatefulSet-specific fields:**
- Desired replicas, observed generation, associated service name, and persistent volume claim specifications

**DaemonSet-specific fields:**
- Pod counts: desired, current, ready, available, and unavailable
- Update strategy type

**Job-specific fields:**
- Parallelism, completions, backoff limit, active/ready/succeeded pod counts, start and completion times
- Job conditions table showing message, reason, type, status, and transition times

**CronJob-specific fields:**
- Cron schedule expression, last schedule time, concurrency policy, and starting deadline
- Job template specification with parallelism and completion settings

**Pod-specific fields:**
- Phase, host IP, pod IP, start time, and labels
- Container statuses table with name, ready state, restart count, image, and started state

**ReplicaSet-specific fields:**
- Owner references (API version, kind, name, UID, controller, block owner deletion)
- Desired, current, and ready replica counts

### Pod Template

For Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs, the detail view includes a **Pod Template** section showing:

- Labels applied to pods
- Termination grace period
- Restart policy
- Init containers (if any)
- Containers
- Volumes

### Pod List

For workload types that manage pods (Deployments, StatefulSets, DaemonSets, ReplicaSets, and Jobs), the detail view includes a table of associated pods with columns for:

| Column | Description |
|--------|-------------|
| **Name** | Pod name (links to the pod detail view) |
| **Status** | Current pod phase (Running, Pending, etc.) |
| **Ready** | Ready containers vs. total containers (e.g., `1/1`) |
| **Restarts** | Total restart count across all containers |
| **Age** | Time since the pod was created |

### ReplicaSet History

For **Deployments**, the detail view includes a ReplicaSet history table showing all associated ReplicaSets sorted by revision number:

| Column | Description |
|--------|-------------|
| **Revision** | Deployment revision number (links to the ReplicaSet detail view) |
| **Name** | ReplicaSet name |
| **Desired** | Desired replica count |
| **Current** | Current replica count |
| **Ready** | Number of ready replicas |
| **Age** | Time since the ReplicaSet was created |

### Viewing JSON and YAML

The detail view provides both a structured view and a raw representation of the resource:

- The structured view displays the resource metadata and status in a readable format.
- Click **View / Edit YAML** to open a side drawer containing the full YAML representation of the resource.
- Use the **Copy** button in the YAML drawer to copy the resource definition to your clipboard.

## Editing Resources

You can edit any workload resource directly from the platform:

1. Navigate to the workload detail view.
2. Click **View / Edit YAML** to open the YAML editor drawer.
3. Modify the YAML in the built-in editor.
4. Click **Update resource** to apply the changes.

The platform sends the updated YAML to the Kubernetes API, which validates and applies the changes. If the update fails (for example, due to a validation error), an error message is displayed.

:::warning Full Replacement
Editing a resource YAML replaces the entire resource specification. Make sure you understand the impact of your changes before applying them.
:::

:::tip Rolling Updates
For Deployments, editing the pod template spec triggers a rolling update by default, creating a new ReplicaSet while scaling down the old one.
:::

## Restarting Workloads

Deployments, StatefulSets, and DaemonSets have a **Restart** action on their detail page. Restarting performs a Kubernetes rolling restart: pods are replaced gradually so the workload stays available throughout. Use this to pick up updated ConfigMaps, Secrets, or images without editing the workload spec.

## Opening a Shell in a Pod

On a pod's detail page, click **Execute Shell** to open an interactive terminal session inside a running container. If the pod has multiple containers, you are prompted to choose which container to connect to. The session runs `kubectl exec` against the pod using your own federated credentials, so your access matches your [namespace permissions](/docs/kubernetes/namespaces).

## Deleting Workloads

To delete a workload, use the delete action on the workload detail page and confirm in the dialog. The confirmation shows the workload type and how many pods will be affected.

Deletion cascades: removing a workload also removes the resources it manages. For example, deleting a Deployment deletes its ReplicaSets and Pods. Pods are given a **30-second grace period** to shut down — they receive a `SIGTERM` signal and can perform cleanup tasks such as draining connections or saving state before being terminated.

:::warning StatefulSets and Data
Deleting a StatefulSet that manages persistent volumes may result in data loss. Review the workload's storage before deleting.
:::

:::warning Protected Namespace
Deleting workloads in the `kube-system` namespace is not permitted. This protects critical system components from accidental removal.
:::

:::info Supported Types
Supported workload types for deletion: Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, CronJob, and Pod.
:::

## Observability

The workload detail view includes an **Observability** panel with real-time metrics charts for:

- **CPU** usage over time
- **Memory** usage over time (in GB)
- **Storage** usage over time (in GiB)

You can select a time range of **1 Hour**, **3 Hours**, or **8 Hours** using the dropdown in the panel header. Metrics refresh automatically.

For more details on metrics, see [Workload Metrics](/docs/kubernetes/workload-metrics).