--- title: "Apply and manage Pod rightsizing for K8s Jobs with CLI - deprecated" slug: "deprecated-apply-and-manage-pod-rightsizing-for-k8s-jobs-with-cli" updated: 2026-01-08T15:39:30Z published: 2026-01-08T15:39:30Z canonical: "docs.zesty.co/deprecated-apply-and-manage-pod-rightsizing-for-k8s-jobs-with-cli" --- > ## 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 K8s Jobs with CLI - deprecated This topic describes how to apply Pod rightsizing to Kubernetes Jobs using the `JobPilotConfig` (JPC) system. You define JPC configurations in YAML and apply them to your cluster with `kubectl`. To apply and manage Pod rightsizing on other workload types, see [Apply and manage Pod rightsizing with CLI](/v1/docs/apply-and-manage-pod-rightsizing-with-cli). Kubernetes does not group Jobs under a single workload identity. Because each Job run creates its own Pod with an independent lifecycle, Kompass uses label selectors in the `JobPilotConfig` to collect related Jobs under a single Job group. A Job group represents all Jobs that share the same labels, allowing Kompass to analyze their behavior collectively and generate accurate rightsizing recommendations. ### Workload selection components #### Label-based selection (`appSelector.labels`) The `appSelector.labels` field defines label-based rules for selecting Jobs to include in the Job group. ```plaintext appSelector:  labels:    matchLabels:      : ``` **Behavior** - Includes all Jobs that match the specified labels. - Treats all Jobs in the group as instances of the same workload for optimization purposes. **Label selector caution** Job grouping depends entirely on labels. If label selectors are too broad, they may group unrelated Jobs together. If they are too narrow, they may exclude Jobs from the group. ### Priority configuration You can assign a priority to a JPC to determine which configuration manages a Job when multiple JPCs match the same Job. The JPC with the higher priority (lower numeric value) takes precedence and manages the matching Jobs. Priority values start at 0 (highest priority). ### Optimization strategy configuration The optimization strategy defines how Kompass calculates CPU and memory recommendations for containers within the Job group. #### Default strategy Reduces CPU or memory to the lowest safe level for maximum savings. Appropriate for most Jobs. - **CPU**: P95 on container usage over lookback period + configured buffer - **Memory**: P99 on container usage over lookback period + configured buffer #### Conservative strategy Reduces CPU or memory moderately for moderate savings. Appropriate for sensitive or stateful Jobs. - **CPU**: P99 on container usage over lookback period + configured buffer - **Memory**: P100 on container usage over lookback period + configured buffer For more information about optimization strategies, see [Pod rightsizing workload optimization](/v1/docs/pod-rightsizing-workload-optimization). ### How Pod rightsizing applies to Jobs Pod rightsizing for Jobs works differently than for long-running workloads because Jobs have a defined lifecycle with a start and end. Kompass applies rightsizing changes only after a Job completes. Changes never interrupt running Jobs, ensuring zero disruption to your batch workloads. When a Job in the group runs again, it uses the new optimized resource requests. ### Rollback protection If a Job experiences CPU throttling or out-of-memory (OOM) events with the optimized resource requests, Kompass automatically rolls back the optimization for the next Job run. The rollback sets the resource request to the maximum observed usage plus the configured buffer. This value is capped by the container's limit (if set). You can disable rollback for a Job group using the `ignoreCPUThrottlingEvent` and `ignoreOOMEvent` parameters. ### Configuration template > [!NOTE] > Not all fields are configurable. Everything above the `metadata` section is predefined and should not be changed. > > Values inside `<>` are user-specified placeholders. ```plaintext ... metadata:  name: <> spec:  appSelector:    labels:      matchLabels:        <>  cooldownPeriod: <>  dataCoverage: <>  ignoreCPUThrottlingEvent: <>  ignoreOOMEvent: <>  lookbackPeriod: <>  managed: <>  metrics:    cpu:      buffer: <>      metricStrategy: <>    memory:      buffer: <>      metricStrategy: <>  minimumImpact: <>  priority: <> ``` ### Parameter reference All parameters in the `JobPilotConfig` are mandatory. | **Parameter** | **Description** | **Value** | | --- | --- | --- | | `metadata.name` | Logical name for the Job group. Replace the default value. | String | | `appSelector.labels.matchLabels` | Label used to add Jobs to this Job group. Replace the default values. | `key: value` | | `spec.cooldownPeriod` | Minimum time between consecutive Pod rightsizing changes. Longer periods promote greater stability. | Duration, in minutes | | `spec.dataCoverage` | Minimum portion of the lookback period required before Kompass generates Pod rightsizing recommendations. For example, if the lookback period is 24 hours and this value is 0.1, recommendations are generated only after 144 minutes of data (10% of 24 hours) is collected. | Percentage, expressed as a decimal | | `spec.ignoreCPUThrottlingEvent` | Specifies whether to ignore CPU throttle rollback behavior. We recommend setting this to false (don't ignore CPU throttle events). | `true` \| `false` | | `spec.ignoreOOMEvent` | Specifies whether to ignore out-of-memory (OOM) rollback behavior. We recommend setting this to false (don't ignore OOM events). | `true` \| `false` | | `spec.lookbackPeriod` | Amount of historical job run data that Kompass uses to generate recommendations. | Duration in hours (h) or minutes (m) | | `spec.managed` | Specifies whether to manage all Jobs in the Job group with Pod rightsizing. | `true` \| `false` | | `metrics.cpu.buffer` | Additional CPU buffer to add to the recommended amount. | Percentage, expressed as a decimal | | `metrics.cpu.metricStrategy` | Specifies which CPU optimization strategy to apply. | `default` \| `conservative` | | `metrics.memory.buffer` | Additional memory buffer to add to the recommended amount. | Percentage, expressed as a decimal | | `metrics.memory.metricStrategy` | Specifies which memory optimization strategy to apply. | `default` \| `conservative` | | `spec.minimumImpact` | Minimum percentage difference required for Kompass to apply a Pod rightsizing recommendation. Higher values increase stability (but may reduce optimization effectiveness). | Percentage, expressed as a decimal | | `spec.priority` | Priority of this `JobPilotConfig`. If a workload matches multiple JPC files, the file with the higher priority manages the workload. | Integer start at 0 (highest priority) | ### Deploy the Pod rightsizing for Jobs configuration **Prerequisites** Pod rightsizing is enabled on the cluster. For more information, see [Enable Pod rightsizing](/v1/docs/enable-pod-rightsizing). **To deploy the JobPilotConfig**: 1. Save the configuration to a YAML file and apply it to your cluster: `kubectl apply -f jpc.yaml -n <namespace>` Replace `<namespace>` with the namespace where your Jobs run. 2. (Optional) Verify that the JPC resource was created: `kubectl get jpc` Kompass activates Pod rightsizing for all matched Jobs within approximately one hour. You can inspect or update the configuration using standard `kubectl describe`, `kubectl apply`, or `kubectl delete `commands. ### Remove Pod rightsizing from a Job group After Pod rightsizing is active on a Job group, you can remove the optimization. Removal takes effect within an hour. **To remove Pod rightsizing from a Job group:** Delete the `JobPilotConfig` resource: `kubectl delete jpc <jpc-name> -n <namespace>` **Where**: - `<jpc-name>` is the name of your `JobPilotConfig` - `<namespace>` is the namespace where it was deployed ### Change the current optimization strategy After Pod rightsizing is active on a Job group, you can change the current optimization strategy. Changes take effect within an hour. **To change an optimization strategy**: 1. Edit the JobPilotConfig: `kubectl edit jpc <jpc-name> -n <namespace>` 2. Update the `metrics.cpu.metricStrategy` and/or `metrics.memory.metricStrategy` fields to your preferred strategy (`default `or `conservative`). 3. Save the changes. Kompass applies the new strategy within approximately one hour. ### Troubleshooting - **No recommendations appear**: The Job may not have enough runs to satisfy `lookbackPeriod `and `dataCoverage`. - **Job runs infrequently**: Consider adjusting the `lookbackPeriod`. - **Job group not visible:** Verify that the labels in `matchLabels` match the Job manifest.