Ephemeral workloads grouping

Leverage advanced PerfectScale grouping to streamline your optimization process even for highly dynamic environments

The PerfectScale grouping configuration is a powerful tool that enables the aggregation of redundant workloads exhibiting similar patterns. By preventing overload through batches of identical information, it enables you to focus on what matters, thereby streamlining analysis processes.

Custom grouping is a rule that aggregates multiple workloads into a single entity (for example, all GitLab runners are aggregated into a single entity—the GitLab workload), merging their data (resource usage, limits, requests, etc.).

This feature is especially convenient when using Spark, GitLab, Airflow or any other operators that produce short-lived, small workloads that often reflect just a single pod in the cluster, or when automating the ungrouped workloads.

Grouping by labels

This grouping approach is specifically helpful for automating dynamic, short-lived workloads. Learn more about how to automate ephemeral workloads here.

To group the workloads, two predefined labels should be added to this workload:

Key	Value	Description
perfectscale.io/workload-grouping-workload-name	custom-workload-name	Specifies the target workload name
perfectscale.io/workload-grouping-workload-type	custom-workload-type	Specifies the target workload type

For the perfectscale.io/workload-grouping-workload-type label, the value must be a custom workload type. Do not use an existing Kubernetes workload type such as Deployment, StatefulSet, DaemonSet, CronJob, and Job this conflicts with PerfectScale’s workload grouping automation logic.

Labels perfectscale.io/workload-grouping-workload-name and perfectscale.io/workload-grouping-workload-type are required to configure automation for ephemeral workloads. After applying the labels, a new workload will appear in PerfectScale. However, automation will only reduce resources after sufficient data has been collected.

To ensure PerfectScale considers all revisions, including those not made by Automation, and to drive better results, you can optionally specify the following labels:

Key	Value	Description
perfectscale.io/workload-grouping-honor-spec	true false (default)	Allows PerfectScale to consider the resource changes in the original spec and changes to current resources. When to use? Set to true if: You are manually changing spec resources (set by the customer in the parent object) and want PerfectScale to respect those changes. ❗Note: To ensure predictable automation behavior, use this label with the value true only when all workloads in the group have equal resources. You want every manual resource change revision to appear in the Revisions Timeline.
perfectscale.io/workload-grouping-honor-image	true false (default)	Allows PerfectScale to consider the image name in the calculated hash. When to use? Set to true if: If you want to see the deployment history in the timeline when the application version (image) changes. ❗Note: Each update will create a new revision in the Revisions Timeline, which may result in a large number of entries.

For label-grouped workloads, PerfectScale ignores Automation CR settings that limit recommendations based on the current resource spec. In this case, these fields under automation.containers.<name>.operational.restrictions are not applied:

cpuManagement.request.increaseEnabled: false
cpuManagement.request.decreaseEnabled: false 
memoryManagement.request.increaseEnabled: false 
memoryManagement.request.decreaseEnabled: false 
memoryManagement.limit.increaseEnabled: false
memoryManagement.limit.decreaseEnabled: false

These fields are not applied because label-grouped workloads often run multiple revisions with different specs. Having a single spec for such workloads would may lead to inaccurate recommendations. Instead, PerfectScale derives recommendations from aggregated usage data across all revisions.

What still works:

Absolute bounds are always respected, regardless of grouping:

• cpuManagement.request.minimumCores / maximumCores

• memoryManagement.request.minimumGiB / maximumGiB

• memoryManagement.limit.minimumGiB / maximumGiB

How to restore spec-relative behavior:

If you need spec-relative restrictions for a specific grouped workload, add this label:

perfectscale.io/workload-grouping-honor-spec: true

If you enable automation for a custom workload type, the WorkloadLabelsSelector in a cluster or namespace configuration will not be applied. All workloads of that custom type will be automated despite the label's configuration.

Cross-namespace grouping

This feature is supported in autoscaler version 1.0.43 and later.

In environments with dynamic namespace structure, it can be difficult to apply consistent automation policies across related workloads. PerfectScale addresses this by enabling centralized automation for workloads across multiple namespaces using labels.

To group and automate such workloads, you need to proceed with a few simple steps:

1. Create a target namespace (the grouping destination).

2. Apply grouping labels to relevant workloads, including perfectscale.io/workload-grouping-workload-namespace with the target namespace value.

3. In the target namespace, define a namespace or workload-level automation configuration.

4. Once done, PerfectScale groups workloads from different namespaces under the target namespace and applies the configured automation.

This label is optional. If the label is not set, workloads remain grouped within their original namespace.

Key	Value	Description
perfectscale.io/workload-grouping-workload-namespace	custom-namespace-name	Specifies the target namespace for cross-namespace grouping.

When this label is set, workloads from multiple namespaces are grouped under the specified target namespace. Automation configured in the target namespace is applied to all grouped workloads, regardless of their original namespace.

When perfectscale.io/workload-grouping-workload-namespace is specified, automation configs from original workload namespaces will not be considered. In order to override the configuration, you need a namespace or workload-level config in the targeted namespace.

How this works in practice

Pod Example:

apiVersion: v1
kind: Pod
metadata:
  name: pod-name
  namespace: {original-namespace}
  labels:
    perfectscale.io/workload-grouping-workload-name: {target-name}
    perfectscale.io/workload-grouping-workload-type: {target-type}
    perfectscale.io/workload-grouping-workload-namespace: {target-namespace}

Original namespace configuration:

apiVersion: perfectscale.io/v1
kind: NamespaceAutomationConfig
metadata:
  name: original-namespace-config
  namespace: {original-namespace}
spec:
  automation:
    operational:
      restrictions:
         ...

Target namespace configuration:

apiVersion: perfectscale.io/v1
kind: NamespaceAutomationConfig
metadata:
  name: target-namespace-config
  namespace: {target-namespace}
spec:
  automation:
    operational:
      restrictions:
         ...

When target namespace label perfectscale.io/workload-grouping-workload-namespace: {target-namespace} is specified, automation configs from the {original-namespace} namespace(s) will not be considered. Only the configs from {target-namespace} will be applied to such workloads.