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, orNever)
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:
- Navigate to the workload detail view.
- Click View / Edit YAML to open the YAML editor drawer.
- Modify the YAML in the built-in editor.
- 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.
Full Replacement
Editing a resource YAML replaces the entire resource specification. Make sure you understand the impact of your changes before applying them.
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.
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.
StatefulSets and Data
Deleting a StatefulSet that manages persistent volumes may result in data loss. Review the workload's storage before deleting.
Protected Namespace
Deleting workloads in the kube-system namespace is not permitted. This protects critical system components from accidental removal.
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.