Applier configuration

The purpose of this topic is to list and describe the additional parameters available for configuring the StormForge Applier. For parameters that apply to the StormForge Agent, see the Agent configuration topic.

Applier settings:

• Continuous reconciliation
• Installing on Red Hat OpenShift
• Using a webhook-based apply method
• Additional RBAC permissions
• Pod priority

Continuous reconciliation

Controls resource patching behavior based on CI/CD and cluster activity. Auto-deploy must be enabled.

Description

The StormForge Applier can be configured to continuously reconcile drift, ensuring that the latest recommended settings are always maintained on a workload.

The Applier logs whenever it reconciles a workload’s resource settings to the recommended values.

Valid values

• EventBased (default): Workload requests and limits are updated only by relevant StormForge events that trigger an update: auto deployment of a new recommendation, clicking Apply Now in the UI, or running stormforge apply. Subsequent updates to requests and limits by GitOps tools will override the recommended settings.

• Continuous: recommended requests and limits values are maintained and not overwritten during CI/CD or deployment activity on the cluster, except when changes are made by the declared reconciliation.conflictingManagers.

  • reconciliation.conflictingManagers: Optional, honored only when reconciliation.mode=Continuous. Declares which field managers conflict with the Applier. The Applier will not reconcile the desired state for fields owned by conflicting managers. Use this if you cannot configure your existing field manager to accept or ignore changes from StormForge.

Installing on Red Hat OpenShift

Required only when installing the Applier on Red Hat OpenShift.

Description

Set to true when installing the StormForge Applier on Red Hat OpenShift Container Platform version 4.x and later. See this guide for details.

Valid values

• true
• false (default)

Using a webhook-based apply method

The Applier supports the use of a mutating admission webhook for applying recommendations. This feature is enabled by default and can be configured by a cluster administrator.

Optional allow and deny namespace lists restrict webhook use to specific namespaces.

Teams can choose to configure specific namespaces or workloads to use a mutating admission webhook to apply recommendations.

Description

By default, the Applier applies recommendations as patches. The webhook.enabled parameter controls whether the Applier can use a mutating admission webhook to apply recommendations. This setting is enabled by default and grants the additional RBAC permissions required for webhook operation to the Applier.

Cluster administrators can restrict webhook use to specific namespaces by using an allow or deny list:

• To allow webhook use on specific namespaces (or workloads), configure the webhook.allowNamespaces list.

• To deny webhook use on specific workloads, configure the webhook.denyNamespaces list.

  If both webhook.allowNamespaces and webhook.denyNamespaces are configured, the denyNamespaces list is ignored and only the allow list is enforced.

Teams can set live.stormforge.io/apply.method to WebhookImmediateRollout, WebhookHybridRollout, or WebhookDeferredRollout on individual namespaces or workloads. For annotation syntax details, see Apply method in the Apply Settings topic.

By design, the webhook feature permits a different configuration to be shown in the Pod than in the workload. Examples:

• StormForge-recommended resource values may be shown on running Pods while developer-supplied values from Git are shown on the Deployment.

Key points:

• Continuous reconciliation, if enabled, doesn’t run for workloads using a webhook-based apply method, as these methods rely on admission-time mutation rather than continuous patching.
• If a namespace or workload uses a webhook-based method but the Applier doesn’t have the webhook feature enabled, or a namespace allow/deny list restricts access, recommendations are still generated, but can’t be applied. In this case, UI and CLI values may differ from the values on the Pods. The Applier updates the workload with the recommended values, but the Pods aren’t updated accordingly.

Valid values

webhook.enabled:

• true (default)
• false

webhook.allowNamespaces and webhook.denyNamespaces:

• An array containing any string or regex expressions ([]*regexp.Regexp) to match against namespace names. You might choose to set these lists in a .yaml file as shown below instead of using a Helm parameter.

Examples

webhook:
  denyNamespaces:
  - ".*-system"

or

webhook:
  denyNamespaces: null
  allowNamespaces:
  - "monitoring"
  - "frontend"
  - ".ecommerce-*"

To explicitly unset either of these values, use null.

webhook:
  denyNamespaces: null

Additional RBAC permission

A YAML manifest that grants additional RBAC permissions to the Applier.

Description

To optimize resources that are not Kubernetes workload types, the Applier needs additional RBAC permissions on the API group and resources.

Example

Add the API groups and their resources in a YAML manifest (for example, applier-rbac.yaml) as shown below.

rbac:
  additional: |-
    # In this section, add any resources that you want the Applier to patch
    - apiGroups:
      - # YOUR_API_GROUP
      resources:
      - # YOUR_RESOURCES
      verbs:
      - get
      - list
      - watch
      - patch
      - update 

Pod priority

Enables scheduling and priority configurations on StormForge Applier pods.

Description

The priorityClassName parameter assigns an existing Pod PriorityClass to the StormForge Applier stormforge-applier pods.

Valid values

A string that matches the .metadata.name of a PriorityClass defined in your organization.

Examples might look similar to this:

• high-priority
• high-priority-nonpreempting

Related information:

• StormForge Applier description
• Kubernetes official documentation:
  • PriorityClass
  • Pod Priority and Preemption