> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kubex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuration Reference

This document maps the current Helm chart values to the resources created by the chart and to the CRD-based runtime model.

## How to Use This Reference

* Use [Getting Started](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/getting-started.md) for the install sequence
* Use [Tuning Guide](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/tuning-guide.md) for slow-cluster and degraded-environment tuning patterns
* Use this document to understand which values are required and which CRs Helm creates
* Use [Policy Configuration](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/policy-configuration.md) for detailed strategy and scope examples
* See [Multi-Policy Container Rightsizing](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/multi-policy-container-rightsizing.md) for how container-scoped policies of the same kind contribute to a workload
* Use [Cluster Automation Strategies](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/cluster-automation-strategies.md) and [Cluster Proactive Policies](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/cluster-proactive-policies.md) for cluster-scoped CRD field references

***

## Resources Created by This Chart

### Core Components

| Resource Type | Purpose |
| - | - |
| `Deployment` | Runs the controller manager and gateway sidecar |
| `Service` | Exposes metrics and webhook endpoints |
| `ServiceMonitor` | Optional Prometheus scrape target for the metrics Service |
| `MutatingWebhookConfiguration` | Registers pod mutation webhook; fail-open via `failurePolicy: Ignore` |
| `ValidatingWebhookConfiguration` | Registers validation webhooks; default fail-open because `webhook.failurePolicy` defaults to `Ignore`, but this is configurable |
| `Secret` | Stores gateway credentials and TLS material when `createSecrets=true` |

### Generated Custom Resources

| Resource Type | When Created | Purpose |
| - | - | - |
| `GlobalConfiguration` | `globalConfiguration.enabled=true` | Cluster-wide controller settings |
| `ClusterAutomationStrategy` | `policy.policies` defined | Cluster strategies generated by Helm |
| `ClusterProactivePolicy` | `scope` defined | Cluster-scoped proactive policies generated by Helm |

### Common CR status

Every Kubex custom resource exposes these status fields:

| Field | Meaning |
| - | - |
| `status.outcome` | `Success` or `Failure`. An omitted value means reconciliation is still in progress. |
| `status.reason` | Human-readable detail about the current result. Proposal sync forwards it as the proposal message. |
| `status.observedGeneration` | The resource generation that produced the result. Proposal sync waits for this to match `metadata.generation`. |

Proposal-managed resources map to `IN_PROGRESS` while `outcome` is missing or stale, `APPLIED` for current `Success`, and `FAILED` for current `Failure`. Decode, validation, ownership, and Kubernetes apply errors report `FAILED` immediately.

### CR outcome rules

Controllers evaluate the resource configuration, not the presence of work at the moment of reconciliation. A valid policy with no matching workloads, namespaces, nodes, or current action can still report `Success`.

| Resource kinds | Success | Failure |
| - | - | - |
| `AutomationStrategy`, `ClusterAutomationStrategy` | The admitted generation is available to consumers | Creation or validation errors are reported by the proposal API when no CR exists |
| `StaticPolicy`, `ClusterStaticPolicy`, `ProactivePolicy`, `ClusterProactivePolicy`, `GpuReactivePolicy`, `ClusterGpuReactivePolicy` | Scope and strategy resolve and policy reconciliation completes | Invalid scope or unresolved strategy |
| `PodAffinityPolicy`, `ContainerArgsPolicy` | Scope is valid and policy reconciliation completes | Invalid scope or runtime setup failure |
| `RollbackPolicy`, `ClusterRollbackPolicy` | The generation is accepted and registered | Reconciliation failure |
| `PolicyEvaluation` | The singleton is ready to process pod events | Required setup failure |
| `GlobalConfiguration` | Required reload, rescan, and health setup completes | A required operation fails |
| `ClusterCompactionPolicy` | Validation and scheduler or descheduler setup completes | Invalid configuration or runtime setup failure |
| `GpuConsolidationPolicy` | An evaluation completes, including no matching nodes or no candidate | Listing, planning, or eviction fails |
| `ObjectPatch`, `ClusterObjectPatch` | The target reaches the requested state | Terminal error, drift, or missing target after application |

### Notes

* Helm-managed policy generation creates `ClusterAutomationStrategy` resources
* Helm-managed scope generation creates `ClusterProactivePolicy` resources
* `AutomationStrategy`, `ProactivePolicy`, `StaticPolicy`, `ClusterStaticPolicy`, `PodAffinityPolicy`, `ContainerArgsPolicy`, `ClusterAutomationStrategy`, and `ClusterProactivePolicy` can all be managed manually outside Helm
* `StaticPolicy` and `ClusterStaticPolicy` are supported by the controller, but this chart does not currently generate them from values
* `PodAffinityPolicy` is also managed outside Helm; see [Policy Configuration](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/policy-configuration.md#podaffinitypolicy-behavior) for behavior details and the eviction-loop warning for `spec.affinity.checkCurrentNodeSatisfiesAffinity`
* `ContainerArgsPolicy` is managed outside Helm; see [Policy Configuration](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/policy-configuration.md#containerargspolicy-behavior) for argument operations, replacement behavior, and KAI precedence

***

## Required Values

| Key | Description |
| - | - |
| `kubex.url.host` | Kubex hostname, for example `example.kubex.ai` |
| `kubex.url.scheme` | Scheme used when deriving `DENSIFY_BASE_URL` from `kubex.url.host` |
| `kubex.clusterName` | Cluster identifier presented to Kubex |
| `kubexCredentials.username` | Required when `createSecrets=true` |
| `kubexCredentials.epassword` | Required when `createSecrets=true` |
| `gateway.configSecretName` | Required when `createSecrets=false` |

## External Credential Secret

If you want to manage the Kubex credential secret outside Helm, disable Helm secret creation and point the gateway sidecar at a pre-created secret:

```yaml theme={null}
createSecrets: false

gateway:
  configSecretName: kubex-gateway-config
```

Use `gateway.configSecretName` to reference the Secret name. This is the only chart value used to locate an externally managed gateway secret when `createSecrets=false`.

The Secret must:

* exist in the same namespace as the Helm release
* use the exact key names shown below
* keep the legacy `DENSIFY_BASE_URL` key because the current gateway image still expects it

Example:

```yaml theme={null}
apiVersion: v1
kind: Secret
metadata:
  name: kubex-gateway-config
  namespace: kubex
type: Opaque
stringData:
  username: "<kubex-username>"
  epassword: "<kubex-encrypted-password>"
  url: "<instance>.kubex.ai"
  DENSIFY_BASE_URL: "https://<instance>.kubex.ai"
```

Keep `kubex.url.host` set in your values file so the release configuration still documents the target Kubex instance, even when the secret is managed outside Helm.

For non-TLS upstream endpoints, set `kubex.url.scheme` to `http`.

Note: `kubexCredentials.userSecretName` is currently not consumed by this chart. When `createSecrets=false`, set `gateway.configSecretName` instead.

## Secondary/DR Cluster Mode

Secondary/DR mode is intended for active/passive disaster-recovery deployments where the passive cluster should follow the same sizing guidance as the active cluster.

Use Secondary/DR mode only when:

* the deployment consists of an active/passive cluster pair
* the passive cluster should consume the same sizing recommendations as the active cluster
* workloads in both clusters have the same topology, including namespaces, workload types, workload names, and container names
* the passive cluster is expected to apply recommendations locally, while the recommendations themselves are generated from the active cluster

Do not use Secondary/DR mode when the two clusters are managing different workloads, use different naming, or have drifted topology. In those cases, the passive cluster should run with its own recommendations instead.

Use these values to enable the feature:

```yaml theme={null}
secondaryCluster:
  enabled: true
  primaryClusterName: primary-cluster
```

`secondaryCluster.enabled` defaults to `false`. `secondaryCluster.primaryClusterName` is required when secondary mode is enabled.

## Core Operational Values

| Key | Default | Description |
| - | - | - |
| `replicaCount` | `1` | Controller replica count |
| `image.repository` | `densify/automation-controller` | Controller image |
| `image.tag` | `1.3.0` | Controller image tag; also injected as `IMAGE_TAG` for heartbeat payloads |
| `imagePullSecrets` | `[]` | Secrets applied to the controller Deployment and cleanup Job pod specs |
| `gateway.image.repository` | `densify/automation-gateway` | Gateway sidecar image |
| `createSecrets` | `true` | Create required gateway and TLS secrets |
| `webhook.enabled` | `true` | Enable webhook components |
| `webhook.timeoutSeconds` | `10` | Admission webhook timeout in seconds |
| `webhook.failurePolicy` | `Ignore` | Failure policy for validating webhooks; default is fail-open, but operators can change it |
| `webhook.podMutation.namePrefix` | `zzz-` | Prefix added to the late mutating webhook object and webhook entry names; set `""` to remove prefix. Prefix may contain lowercase letters, digits, and hyphens, and must start with a letter or digit. **Warning:** changing this renames webhook objects on upgrade, and Helm applies that as delete-then-create, leaving brief window where pod mutation webhook is absent. |
| `webhook.podMutation.additionalWebhook.enabled` | `false` | Register an additional early Pod mutation webhook so Kubex can restore selected resources after intervening mutators. |
| `webhook.podMutation.additionalWebhook.namePrefix` | `000-` | Prefix added to the additional mutating webhook object and webhook entry name. Uses the same validation as `namePrefix`. |
| `webhook.certManager.enabled` | `false` | Use cert-manager instead of self-signed TLS |
| `selfSignedCert.validity` | `3650` | Self-signed certificate validity in days |
| `controllerManager.globalConfigReconcileInterval` | `1m` | Base reconcile cadence for global config controller |
| `controllerManager.leaderElection.leaseDuration` | `15s` | Leader election lease duration; increase this on slow API servers |
| `controllerManager.leaderElection.renewDeadline` | `10s` | Leader election renew deadline; must stay below `leaseDuration` |
| `controllerManager.leaderElection.retryPeriod` | `2s` | Leader election retry interval; must stay below `renewDeadline` |
| `controllerManager.metricsBindAddress` | `:8080` | Metrics bind address used by the controller manager |
| `controllerManager.podAdmissionWebhookKubeAPIQPS` | `-1` | QPS limit for the pod admission webhook Kubernetes client; use `0` for client-go default `5 QPS`, or a negative value to disable client-side rate limiting |
| `controllerManager.podAdmissionWebhookKubeAPIBurst` | `0` | Burst limit for the pod admission webhook Kubernetes client; `0` leaves burst at client-go default when webhook client rate limiting is active. With default `controllerManager.podAdmissionWebhookKubeAPIQPS: -1`, client-side rate limiting is disabled, so Burst is not practical cap |
| `kubex.requestTimeout` | `30s` | Kubex API request timeout |
| `secondaryCluster.enabled` | `false` | Enable secondary/DR mode for recommendation consumption from a primary cluster |
| `secondaryCluster.primaryClusterName` | `""` | Primary Kubex cluster name used to fetch recommendations when secondary mode is enabled |
| `podSecurityContext` | chart default | Pod-level security context for the controller Deployment; defaults to `65534` for `runAsUser`, `runAsGroup`, and `fsGroup`, plus `runAsNonRoot=true` and `seccompProfile.type=RuntimeDefault` |
| `openshift.enabled` | `false` | Enable arbitrary-UID-compatible security contexts for the controller, cleanup job, and controller-created compaction workloads without changing the default Kubernetes path |
| `openshift.fsGroup` | `null` | Optional `fsGroup` applied when `openshift.enabled=true`; omit it to let OpenShift assign permitted IDs |
| `compactionScheduler.enabled` | `true` | Render the shared scheduler ServiceAccount and RBAC used by the controller-created compaction scheduler |
| `compactionDescheduler.enabled` | `true` | Render the shared descheduler ServiceAccount and RBAC used by controller-created per-policy deschedulers |
| `compactionScheduler.image.tag` | `""` | Explicit scheduler tag; empty derives the tag from the cluster Kubernetes version |
| `compactionScheduler.image.digest` | `""` | Optional immutable scheduler digest; takes precedence over `tag` |
| `compactionScheduler.image.pullPolicy` | `IfNotPresent` | Pull policy for the controller-created scheduler Pod |
| `compactionScheduler.podSecurityContext` | `{}` | Pod security context propagated to the controller-created scheduler; OpenShift mode adds `runAsNonRoot` and RuntimeDefault seccomp |
| `compactionScheduler.securityContext` | chart default | Container security context propagated to the controller-created scheduler |
| `compactionDescheduler.image.digest` | `""` | Optional immutable descheduler digest; takes precedence over `tag` |
| `compactionDescheduler.podSecurityContext` | `{}` | Pod security context propagated to controller-created descheduler Jobs; OpenShift mode adds restricted-compatible defaults |
| `compactionDescheduler.securityContext` | `{}` | Container security context propagated to controller-created descheduler Jobs; OpenShift mode drops capabilities and disables privilege escalation |
| `metrics.serviceMonitor.enabled` | `false` | Create a Prometheus Operator `ServiceMonitor` for the metrics Service |
| `metrics.port` | `8080` | Service port for the metrics Service |
| `metrics.serviceMonitor.namespaceSelector` | `[]` | Namespace names to watch from the ServiceMonitor; empty means all namespaces |
| `metrics.serviceMonitor.scheme` | `http` | Scrape scheme for the controller metrics endpoint; HTTP pairs with `--metrics-secure=false` in the manager args |
| `metrics.serviceMonitor.scrapeTimeout` | `""` | Optional scrape timeout; must be less than or equal to `metrics.serviceMonitor.interval` when set |
| `gateway.securityContext` | chart default | Gateway sidecar container security context |
| `cleanup.podSecurityContext` | `{}` | Optional pod security context for the pre-delete cleanup job |
| `cleanup.securityContext` | chart default | Container security context for the pre-delete cleanup job |
| `cleanup.resources` | requests `cpu: 10m`, `memory: 32Mi`; limits `memory: 64Mi` | Resource requests and limits for the pre-delete cleanup job |

### Additional Early Pod Mutation

Most installations do not need the additional webhook and should leave it disabled. Enable it when another mutating webhook must see Kubex-updated resource requests or limits to make its admission decision. The early Kubex registration exposes those updates before other mutators run, while the normal late registration restores Kubex-selected resources if an intervening webhook changes them:

```yaml theme={null}
webhook:
  podMutation:
    additionalWebhook:
      enabled: true
      namePrefix: 000-
```

The early registration uses `additionalWebhook.namePrefix` and the normal late registration uses `namePrefix`. Keep defaults `000-` and `zzz-` for intended early and late placement. Both registrations call the same idempotent handler with `failurePolicy: Ignore`.

Webhook ordering is best-effort. Kubernetes does not define mutating webhook order as a stable API contract, so this setting must not be used when exact ordering is required. Enabling it roughly doubles Pod admission traffic, including dry-run health-probe Pods; size webhook capacity accordingly.

## High Availability and Replica Scaling

### Leader Election Behavior

The controller uses leader election by default (`controllerManager.leaderElection.enabled=true`), which ensures only one replica actively reconciles resources at any given time:

* **Active reconciliation**: Only the leader pod reconciles policy and workload resources, applies recommendations, and executes resource mutations
* **Webhook load balancing**: All replicas (leader and standby) serve admission webhook requests through the webhook Service, distributing webhook traffic across all pods
* **Automatic failover**: If the leader pod crashes, is evicted, or becomes unresponsive, another replica automatically acquires the leader lease and takes over reconciliation within the lease duration window (default 15 seconds)
* **Coordination mechanism**: Leader election uses `coordination.k8s.io/leases` resources in the controller namespace to coordinate active/standby roles

### When to Increase Replicas

Consider increasing `replicaCount` beyond the default of `1` in these scenarios:

#### 1. High Availability Requirements

**Recommended: `replicaCount: 2`**

* Production clusters where automation must remain available during node maintenance, pod evictions, or rolling updates
* Environments with strict uptime SLAs where a brief reconciliation pause during controller restarts is unacceptable
* Clusters where the controller deployment may be subject to pod disruption budgets or preemption

**Trade-off**: Additional memory and CPU overhead for standby replicas that are not actively reconciling.

#### 2. High Webhook Request Volume

**Recommended: Scale based on webhook latency and pod creation rate**

* Clusters with high pod creation rates where webhook request volume exceeds a single pod's capacity
* Environments where webhook timeout errors appear under load (`webhook.timeoutSeconds` default is 10 seconds)
* Large clusters with frequent deployments, job executions, or autoscaling events that trigger many admission requests concurrently

**How to evaluate**:

* Monitor webhook latency via the controller `/metrics` endpoint (default `:8080/metrics`)
* Check controller logs for webhook timeouts or slow request warnings
* If webhook requests are queueing or timing out, increase replicas to distribute load

**Trade-off**: Webhook requests are distributed across all replicas, so scaling provides linear improvements in webhook throughput.

#### 3. Zero-Downtime During Updates

**Recommended: `replicaCount: 2` minimum**

* During Helm upgrades or image updates, multiple replicas ensure webhook availability remains uninterrupted while pods are being replaced
* Leader election allows standby replicas to immediately take over reconciliation when the active pod terminates
* Avoids admission webhook downtime that could block pod creation cluster-wide if the webhook `failurePolicy` is set to `Fail`

### When NOT to Increase Replicas

**Do not increase replicas to**:

* Speed up policy reconciliation (only one replica reconciles at a time due to leader election)
* Process more workloads in parallel (the leader election model serializes reconciliation)
* Reduce reconciliation latency (tune `--max-concurrent-reconciles` instead; see below)

### Scaling Alternatives for Reconciliation Throughput

If reconciliation throughput is insufficient with a single active leader:

* **Increase concurrent reconcilers**: Set `controllerManager.extraArgs: ["--max-concurrent-reconciles=20"]` to increase per-controller worker count (default is 10). This allows the leader to process more reconcile requests in parallel.
* **Tune API client rate limits**: Adjust `--kube-api-qps` and `--kube-api-burst` via `controllerManager.extraArgs` if you observe client-side throttling in logs (messages like "Waited before sending request").
* **Review policy scope**: Broad selectors or frequent policy changes can create reconciliation bursts; prefer narrow selectors and explicit workload type filters in `scope[].podLabels` and `policy.policies.<name>.allowedPodOwners`.

### Example: High-Availability Production Configuration

```yaml theme={null}
replicaCount: 2

controllerManager:
  leaderElection:
    enabled: true
  extraArgs:
    - --max-concurrent-reconciles=15

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    memory: 1Gi
```

For tuning leader election parameters (`leaseDuration`, `renewDeadline`, `retryPeriod`) and other performance settings, refer to the [Tuning Guide](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/tuning-guide.md) and monitor your cluster's behavior under load.

### Monitoring Replica Health

When running multiple replicas, verify leader election and webhook distribution:

```bash theme={null}
# Check which pod holds the leader lease
kubectl get lease -n kubex

# Verify all replicas are ready
kubectl get pods -n kubex -l control-plane=controller-manager

# Monitor webhook request distribution
kubectl logs -n kubex -l control-plane=controller-manager -c manager --tail=100 | grep webhook
```

## OpenShift Notes

* Installing this chart still requires cluster-scoped permissions because it creates `ClusterRole`, `ClusterRoleBinding`, and admission webhook resources
* If you deploy on OpenShift, enable `openshift.enabled=true` to omit the controller's fixed UID/GID defaults and apply restricted-friendly contexts to the cleanup job and controller-created scheduler/descheduler Pods
* OpenShift mode is designed for the built-in `restricted-v2` SCC and does not require `anyuid` or a custom SCC; set `openshift.fsGroup` only when your storage class or cluster policy requires a fixed group
* `imagePullSecrets` are propagated to controller-created scheduler and descheduler Pods for mirrored or private registries
* The OpenShift compatibility switch is opt-in so standard Kubernetes installs keep the existing defaults

## Global Configuration Values

These render into the default `GlobalConfiguration` resource:

Use [Global Configuration Reference](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/global-configuration.md) for the CR field descriptions and behavior notes behind these values.

| Key | Default | Description |
| - | - | - |
| `globalConfiguration.recommendationReloadInterval` | `1h` | Recommendation refresh cadence |
| `globalConfiguration.rescanInterval` | `6h` | Pod rescan cadence |
| `globalConfiguration.mutationLogInterval` | `5m` | Mutation log send cadence |
| `globalConfiguration.snapshotInterval` | `30m` | Policy snapshot upload cadence |
| `globalConfiguration.heartbeatInterval` | `5m` | Controller heartbeat upload cadence |
| `globalConfiguration.proposalSyncInterval` | `1m` | Proposal synchronization cadence |
| `globalConfiguration.proposalSyncEnabled` | `true` | Proposal sync is enabled by default. Set to `false` to disable it; disabled proposal sync deletes proposal-managed resources |
| `globalConfiguration.kubexAPIRequestTimeout` | `60s` | Timeout for Kubex API requests. Also sets the gateway sidecar `API_REQUEST_TIMEOUT` env var at Helm install/upgrade time; live CR edits do not update the sidecar. |
| `globalConfiguration.webhookOwnerResolutionRetryTimeout` | `1s` | Pod webhook owner-resolution retry budget |
| `globalConfiguration.automationEnabled` | `true` | Global enable/disable switch |
| `globalConfiguration.multiPolicyContainerRightsizingEnabled` | `false` | Use separate recommendation keys so same-kind resource policies can contribute per container/resource. See [Multi-Policy Container Rightsizing](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/multi-policy-container-rightsizing.md). |
| `globalConfiguration.suppressFetchRecommendations` | `false` | Testing-only fetch suppression |
| `globalConfiguration.respectKubexAutomation` | `true` | Respect recommendation-level disablement |
| `globalConfiguration.protectedNamespacePatterns` | `["kube-*","openshift-*","gmp-*"]` | Namespace patterns protected from automation |
| `globalConfiguration.webhookHealth.failureThreshold` | `2` | Failures before webhook is marked unhealthy |
| `globalConfiguration.webhookHealth.successThreshold` | `3` | Successes before webhook is marked healthy |
| `globalConfiguration.webhookHealth.transitionCheckInterval` | `10s` | Probe interval during state transitions |
| `globalConfiguration.webhookProbe.image` | `""` (inherits controller image) | Container image used by the dry-run webhook probe Pod |
| `globalConfiguration.webhookProbe.labels` | `{}` | Additional labels applied to the dry-run webhook probe Pod |
| `globalConfiguration.webhookProbe.annotations` | `{}` | Additional annotations applied to the dry-run webhook probe Pod |
| `globalConfiguration.webhookProbe.resources` | `{}` | Resource requests and limits for the dry-run webhook probe container |
| `globalConfiguration.webhookProbe.podSecurityContext` | `{"runAsNonRoot":true,"seccompProfile":{"type":"RuntimeDefault"}}` | Pod security context for the dry-run webhook probe Pod |
| `globalConfiguration.webhookProbe.securityContext` | `{"allowPrivilegeEscalation":false,"readOnlyRootFilesystem":true,"capabilities":{"drop":["ALL"]}}` | Container security context for the dry-run webhook probe container |
| `experimental.gpuKaiContract` | `v1alpha1-2026-07` | Required acknowledgement token for experimental GPU/KAI CR fields rendered by the chart |

The probe uses dry-run Pod admission; no container runs. Probe security defaults come from the chart only. Partial security context values retain the other chart defaults, and explicit values override them. Directly managed `GlobalConfiguration` resources must specify these controls themselves under `spec.webhookProbe`.

Webhook behavior notes:

* The pod mutating webhook is always fail-open. Pod creation continues if the webhook hits Kubernetes API communication errors or internal runtime errors; the effect is missed mutation rather than blocked admission.
* Validating webhooks are fail-open by default because `webhook.failurePolicy` defaults to `Ignore`, but that behavior is configurable.
* For operational tuning guidance around these behaviors, see [Tuning Guide](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/tuning-guide.md#admission-webhook-fail-open-semantics).

## Helm-Managed Policy Values

### `policy`

| Key | Description |
| - | - |
| `policy.defaultPolicy` | Default strategy name used when a scope omits `policy` |
| `policy.policies` | Map of strategy definitions generated as `ClusterAutomationStrategy` resources |
| `policy.policies.<name>.allowedPodOwners` | Comma-separated workload owner types copied into generated `ClusterProactivePolicy.scope.workloadTypes`. Supported values: `Deployment`, `StatefulSet`, `DaemonSet`, `CronJob`, `Rollout`, `Job`, `AnalysisRun`, `StrimziPodSet`, `Model`. `ReplicaSet` is not supported. |
| `policy.policies.<name>.enablement` | Resource change permissions and optional floor/ceiling bounds |
| `policy.policies.<name>.inPlaceResize` | In-place resize controls |
| `policy.policies.<name>.podEviction` | Eviction fallback controls |
| `policy.policies.<name>.safetyChecks.maxAnalysisAgeDays` | Recommendation freshness gate written into generated `ClusterProactivePolicy` |

These values apply to Helm-managed recommendation-driven automation only. If you need namespaced policies, fixed-resource policies, or independently managed cluster policies, create those CRs separately and reference either `AutomationStrategy` or `ClusterAutomationStrategy` as appropriate.

### `scope`

| Key | Description |
| - | - |
| `scope[].name` | Name of generated `ClusterProactivePolicy` |
| `scope[].policy` | Name of generated or externally managed `ClusterAutomationStrategy` to reference |
| `scope[].namespaces.operator` | `In` or `NotIn` |
| `scope[].namespaces.values` | Namespace selection values |
| `scope[].podLabels` | Label selector rules converted to `matchLabels` or `matchExpressions` |
| `scope[].weight` | Policy weight for precedence resolution |
| `scope[].containers` | Exact container names for the generated `ClusterProactivePolicy`; empty targets all automatable containers |

For the generated resource fields behind these values, see [Cluster Automation Strategies](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/cluster-automation-strategies.md) and [Cluster Proactive Policies](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/cluster-proactive-policies.md).

***

## Backward-Compatible Values

The chart still reads selected legacy settings from `deployment.controllerEnv`:

| Legacy Key | New Effective Location |
| - | - |
| `deployment.controllerEnv.recommendationsFetchInterval` | `GlobalConfiguration.spec.recommendationReloadInterval` |
| `deployment.controllerEnv.podScanInterval` | `GlobalConfiguration.spec.rescanInterval` |
| `deployment.controllerEnv.apiRequestTimeout` | `GlobalConfiguration.spec.kubexAPIRequestTimeout` |

See [Advanced Configuration](https://docs.kubex.ai/docs-kubex/Content/Kubex/automation-engine/advanced-configuration.md#backward-compatibility-and-migration) for migration guidance.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.