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 and manage Pod rightsizing with CLI.

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

apiVersion: kompass.zesty.co/v1
kind: VirtualWorkload
metadata:
  name: <virtual-workload-group-name>
  namespace: <namespace>
spec:
  labelSelector:
    matchLabels:
      <label-key>: <label-value>
  priority: <unique-integer>
  type: <job-or-scaledjob-or-sparkapplication>

Virtual workload group parameter reference

All parameters in the VirtualWorkload resource are mandatory.

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 Pod rightsizing to workloads - CLI.

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.