--- title: "Apply and manage Pod rightsizing for batch-like workloads" slug: "apply-and-manage-pod-rightsizing-for-batch-like-workloads" updated: 2026-07-21T10:01:05Z published: 2026-07-21T10:01:05Z canonical: "docs.zesty.co/apply-and-manage-pod-rightsizing-for-batch-like-workloads" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.zesty.co/llms.txt > Use this file to discover all available pages before exploring further. # Apply and manage Pod rightsizing for batch-like workloads This topic describes how to apply and manage Pod rightsizing for batch-like workloads, such as **Jobs**, **SparkApplications**, and **KEDA ScaledJobs**. These workloads run for short periods and terminate, which limits the amount of historical data available per workload instance. As a result, you cannot accurately rightsize individual workloads. By grouping these workloads into **virtual workload groups** (VWG), you can analyze their collective usage patterns and receive accurate rightsizing recommendations. After you group the workloads into a VWG, the VMG is treated as a single, logical workload. You can then apply a Pod rightsizing policy to the VWG, and view and manage that group like any other workload. A virtual workload group (VWG) defines how workloads are selected based on shared characteristics such as labels and represents them as a single logical workload. You define VWG in YAML and apply them to your cluster with kubectl. ### How batch-like grouping works Rightsizing batch-like workloads requires these steps: 1. **Group workloads** with the `VirtualWorkload` resource: This resource identifies which workloads belong together based on labels. The system automatically aggregates metrics across all member workloads to identify shared usage patterns. 2. **Enable rightsizing** with a policy**:** This component enables the actual rightsizing automation for the defined group. For more information, see [Apply MDA optimization with YAML](/v1/docs/apply-mda-optimization-with-yaml). ### Define a virtual workload group in YAML To create a virtual workload group, deploy a `VirtualWorkload `resource to your cluster. Use label selectors to tell Kompass which workloads belong in the group. The `VirtualWorkload `resource has rules that govern its use as well as precedence when there is a conflict. ### Grouping rules - **Automated grouping:** Workloads of the specified type that match the label selector are automatically grouped into the VWG. - **Many-to-one:** Multiple workloads of the same type can belong to a single VWG. - **Single-type constraint:** A VMG cannot manage multiple workload types (for example, you cannot combine SparkApplications and ScaledJobs in one VWG). #### Precedence and conflict resolution A workload may be managed by only one virtual workload group at a time. If a workload matches the label selectors of multiple VWGs, Kompass uses the priority value to determine which VMG manages it. - **Lowest value wins:** A VWG with priority 10 takes precedence over a group with priority 100. - **Unique priorities:** You must assign a unique priority value to each VWG. The system uses a validation webhook to block the creation of VWGs that share the same priority level. ### Configuration example ```yaml apiVersion: kompass.zesty.co/v1 kind: VirtualWorkload metadata:  name:  namespace: spec:  labelSelector:    matchLabels:      :  priority:  type: ``` #### Virtual workload group parameter reference All parameters in the `VirtualWorkload `resource are mandatory. | **Parameter** | **Description** | **Value** | | --- | --- | --- | | `metadata.name` | Logical name for the virtual workload group. | String | | `metadata.namespace` | The namespace scope of the VWG. Only workloads in this namespace are considered for grouping. | String | | `spec.labelSelector` | Kubernetes labels used to identify member workloads. | `matchLabels: <key: value>` | | `spec.priority` | Virtual workload group priority. If a workload matches multiple VWGs, the VWG with the lower numeric value has higher priority. | Integer (Lowest value has highest priority) | | `spec.type` | The workload type included in this VWG. | `job`, `scaledjob`, or `sparkapplication` | ### Deploy the configuration To create your virtual workload group and enable rightsizing, save your configurations to YAML files and apply them to the namespace where your workloads run. **To deploy the files:** `kubectl apply -f <filename>.yaml -n <namespace>` Kompass groups all matched workloads within approximately one hour. You can verify the resources were created by running: `kubectl get virtualworkloads` ### Viewing virtual workload groups in the user interface After workloads are in a VWG, you can see their status and performance in the **Kompass > Workloads** tab. Virtual workload groups are shown as a single entry. The **Type** column shows the virtual workload group name (as defined in the VWG resource) instead of the underlying workload type. Kompass aggregates metrics across all workloads in the VWG using time-weighted calculations to account for differences in workload duration and frequency. Savings and potential savings are calculated using the same method. ### Manage rightsizing You can apply a rightsizing policy for a VWG using the same workflows as for standard workloads, as described in [Apply MDA optimization with YAML](/v1/docs/apply-mda-optimization-with-yaml). You can also remove rightsizing from a virtual workload group in the following way: - **To** **remove rightsizing from a workload group**, you can also delete the VWG resource. If you delete the VWG, the virtual workload group is removed, and any policy applied to it is no longer relevant. If the individual workloads are matched by other policies, those policies will now take over. **To delete the VWG resource**: - Delete the `VirtualWorkloads `resource: `kubectl delete virtualworkloads [vwg-name] -n [namespace]` **Where**: - `[vwg-name]` is the name of your `VirtualWorkload` - `[namespace]` is the namespace where it was deployed ## Troubleshoot batch-like rightsizing If you encounter issues while configuring or enabling rightsizing for your virtual workload groups, check the following common areas: - **Priority conflicts:** If you attempt to create or update a VWG with a priority value already in use, the system will block the request via a validation webhook. Ensure every `VirtualWorkload `has a unique priority integer. - **VWG visibility in the UI:** If a VWG is not visible in the **Workloads** tab, verify that the labels in your `matchLabels `section exactly match the labels in your workload manifests. - **VWG is visible but not rightsizing:** If the group appears in the UI but resources are not being adjusted, ensure that a **Policy** is correctly applied and enabled for that specific `VirtualWorkload`. - **Type mismatch errors:** Kompass logs an error if there is no match between a Pod and the workload type defined in your YAML. Ensure the `spec.type` field correctly identifies the workload (for example, `sparkapplication`). - **Missing metrics:** It can take up to 2 hours after deploying a new `VirtualWorkload `resource for Kompass to group the matched workloads and begin displaying data in the UI.