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 for the install sequence
Use Tuning Guide 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 for detailed strategy and scope examples
See Multi-Policy Container Rightsizing for how container-scoped policies of the same kind contribute to a workload
Use Cluster Automation Strategies and Cluster Proactive Policies 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 for behavior details and the eviction-loop warning for spec.affinity.checkCurrentNodeSatisfiesAffinity
ContainerArgsPolicy is managed outside Helm; see Policy Configuration 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:

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:

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:

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:

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

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 and monitor your cluster’s behavior under load.

Monitoring Replica Health

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

# 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 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.
`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.

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 and Cluster Proactive Policies.

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 for migration guidance.

Getting Started

Kubernetes Optimization

Public Cloud Optimization

API Reference

Release Notes

Administration

Configuration Reference

How to Use This Reference

Resources Created by This Chart

Core Components

Generated Custom Resources

Common CR status

CR outcome rules

Notes

Required Values

External Credential Secret

Secondary/DR Cluster Mode

Core Operational Values

Additional Early Pod Mutation

High Availability and Replica Scaling

Leader Election Behavior

When to Increase Replicas

1. High Availability Requirements

2. High Webhook Request Volume

3. Zero-Downtime During Updates

When NOT to Increase Replicas

Scaling Alternatives for Reconciliation Throughput

Example: High-Availability Production Configuration

Monitoring Replica Health

OpenShift Notes

Global Configuration Values

Helm-Managed Policy Values

`policy`

`scope`

Backward-Compatible Values

​How to Use This Reference

​Resources Created by This Chart

​Core Components

​Generated Custom Resources

​Common CR status

​CR outcome rules

​Notes

​Required Values

​External Credential Secret

​Secondary/DR Cluster Mode

​Core Operational Values

​Additional Early Pod Mutation

​High Availability and Replica Scaling

​Leader Election Behavior

​When to Increase Replicas

​1. High Availability Requirements

​2. High Webhook Request Volume

​3. Zero-Downtime During Updates

​When NOT to Increase Replicas

​Scaling Alternatives for Reconciliation Throughput

​Example: High-Availability Production Configuration

​Monitoring Replica Health

​OpenShift Notes

​Global Configuration Values

​Helm-Managed Policy Values

​policy

​scope

​Backward-Compatible Values

How to Use This Reference

Resources Created by This Chart

Core Components

Generated Custom Resources

Common CR status

CR outcome rules

Notes

Required Values

External Credential Secret

Secondary/DR Cluster Mode

Core Operational Values

Additional Early Pod Mutation

High Availability and Replica Scaling

Leader Election Behavior

When to Increase Replicas

1. High Availability Requirements

2. High Webhook Request Volume

3. Zero-Downtime During Updates

When NOT to Increase Replicas

Scaling Alternatives for Reconciliation Throughput

Example: High-Availability Production Configuration

Monitoring Replica Health

OpenShift Notes

Global Configuration Values

Helm-Managed Policy Values

`policy`

`scope`

Backward-Compatible Values