Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 9. Workflow scaling and disruption protection

You can configure scaling and disruption protection for your OpenShift Serverless Logic workflows to handle varying workloads efficiently and maintain availability during cluster maintenance operations. This section describes how to scale workflows manually, configure horizontal pod autoscaling (HPA) for automatic scaling based on resource utilization metrics, and configure pod disruption budgets (PDB) to maintain availability during voluntary disruptions.

Proper scaling and disruption protection configuration helps ensure your workflows can handle increased load while optimizing resource usage and maintaining availability in your Red Hat OpenShift Serverless cluster.

Important

The following features require OpenShift Serverless Logic 1.38 or later and are not available in earlier versions.

9.1. Scaling a workflow manually
Copy link

The SonataFlow custom resource definition (CRD) exposes the Kubernetes scale subresource, which enables you to scale workflows using the standard Kubernetes API. You can scale workflows manually using several methods.

Important

The following feature requires OpenShift Serverless Logic 1.38 or later and is not available in earlier versions.

Note

Workflows deployed with the dev profile are intended for development use and are not designed for scaling.

9.1.1. Querying the workflow scale subresource
Copy link

To query the workflow scale subresource, run the following command: 

$ oc get sonataflow <workflow_name> -n <namespace> --subresource=scale -o yaml
 
apiVersion: autoscaling/v1
kind: Scale
metadata:
  creationTimestamp: "2026-02-12T12:48:46Z"
  name: example-workflow
  namespace: example-workflow-namespace
  resourceVersion: "38397"
  uid: de53b549-dcb5-4b46-bb4e-9a576341e099
spec:
  replicas: 1
status:
  replicas: 1
  selector: app=example-workflow,app.kubernetes.io/component=serverless-workflow,app.kubernetes.io/instance=example-workflow,app.kubernetes.io/managed-by=sonataflow-operator,app.kubernetes.io/name=example-workflow,app.kubernetes.io/version=main,sonataflow.org/workflow-app=example-workflow,sonataflow.org/workflow-namespace=example-workflow-namespace

The output displays the following information:

  • spec.replicas - Number of configured replicas.
  • status.replicas - Number of currently available replicas.
  • status.selector - Selector to query the observed pods.

9.1.2. Scaling methods
Copy link

You can scale a workflow using any of the following methods:

Scaling using the oc scale command

  1. Run the following command: 

    $ oc scale sonataflow <workflow_name> -n <namespace> --replicas=<number>

    where:

    <workflow_name>
    Specifies the name of your workflow.
    <namespace>
    Specifies the namespace where your workflow is deployed.
    <number>
    Specifies the desired number of replicas. 
    $ oc scale sonataflow example-workflow -n example-workflow-namespace --replicas=3
     
sonataflow.sonataflow.org/example-workflow scaled

Scaling by configuring the SonataFlow custom resource

  1. Edit your SonataFlow CR to include the spec.podTemplate.replicas field: 

    apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  namespace: example-workflow-namespace
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
    sonataflow.org/profile: preview
spec:
  podTemplate:
    replicas: 3
  flow:
    start: ExampleStartState
# ...

    Use the spec.podTemplate.replicas field to configure the number of replicas.

  2. Apply the configuration: 

    $ oc apply -f example-workflow.yaml -n example-workflow-namespace
     
    sonataflow.sonataflow.org/example-workflow configured

Scaling by patching the SonataFlow custom resource

  1. Run the following command: 

    $ oc patch sonataflow <workflow_name> -n <namespace> \ --type merge \ -p '{ "spec": { "podTemplate": { "replicas": <number> } } }'

    where:

    <workflow_name>
    Specifies the name of your workflow.
    <namespace>
    Specifies the namespace where your workflow is deployed.
    <number>
    Specifies the desired number of replicas. 
    $ oc patch sonataflow example-workflow -n example-workflow-namespace \ --type merge \ -p '{ "spec": { "podTemplate": { "replicas": 3 } } }'

    + 

    sonataflow.sonataflow.org/example-workflow patched

By using a HorizontalPodAutoscaler (HPA), you can configure how a Kubernetes workload resource scales based on a set of metrics, such as CPU or memory usage.

Workload resources that support autoscaling expose the scale subresource, which allows Kubernetes to adjust the number of replicas dynamically. When you configure horizontal pod autoscaling for a workflow, the OpenShift Serverless Logic Operator automatically manages the coordination between the workflow scale subresource and the associated Kubernetes Deployment, making the workflow pods scale accordingly.

Before configuring an HPA for a workflow, you must define the resources to be used as scaling metrics in the SonataFlow CR.

Important

The following feature requires OpenShift Serverless Logic 1.38 or later and is not available in earlier versions.

Prerequisites

  • You have installed the OpenShift Serverless Logic Operator.
  • You have deployed a workflow using the preview or gitops profile.

Procedure

  1. Configure resource requests in your SonataFlow CR: 

    apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  namespace: example-workflow-namespace
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
    sonataflow.org/profile: preview
spec:
  podTemplate:
    container:
      resources:
        requests:
          cpu: 100m
          memory: 256Mi
        limits:
          cpu: 500m
          memory: 512Mi
  flow:
    start: ExampleStartState
# ...

    This example configures the following resource settings:

    • The spec.podTemplate.container field supports most of the standard PodSpec configurations. For more information, see Container in the Kubernetes documentation.
    • The resources.requests.cpu field specifies the CPU request for the workflow container.

    • The resources.requests.memory field specifies the memory request for the workflow container.

      Note

      HorizontalPodAutoscalers use the request resources for metrics calculations. The resource limits in the example are illustrative and are not used for scaling decisions.

  2. Create a HorizontalPodAutoscaler CR: 

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-autoscaler
  namespace: example-workflow-namespace
spec:
  scaleTargetRef:
    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlow
    name: example-workflow
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

    This configuration includes the following settings:

    • The scaleTargetRef field references the target workflow by specifying the apiVersion, kind, and name.
    • The metrics field defines a metric based on CPU resource utilization.

  3. Apply the HorizontalPodAutoscaler configuration by running the following command: 

    $ oc apply -f example-autoscaler.yaml -n example-workflow-namespace
Important

Workflows deployed with spec.podTemplate.deploymentModel: knative cannot be scaled with a HorizontalPodAutoscaler because Knative Serving automatically controls the number of replicas. Additionally, workflows deployed using the dev profile are not designed to scale.

By using a PodDisruptionBudget (PDB), you can configure the required availability of a workflow during a voluntary disruption, such as a node drain, in the cluster.

A PDB limits the number of pods that can be unavailable simultaneously during such disruptions, ensuring that the workflow maintains the desired level of availability.

In general, any tool that needs to guarantee availability should respect the PDB by using the Kubernetes Eviction API instead of directly deleting pods or deployments. The Eviction API ensures that disruption constraints defined by the PDB are honored.

The OpenShift Serverless Logic Operator can automatically generate a PodDisruptionBudget for a workflow based on the SonataFlow CR configuration.

Important

The following feature requires OpenShift Serverless Logic 1.38 or later and is not available in earlier versions.

Available fields for PDB configuration

To configure a PDB for a workflow, use the spec.podTemplate.podDisruptionBudget field in your SonataFlow CR: 

# ...
spec:
  podTemplate:
    podDisruptionBudget:
      minAvailable: 2
      maxUnavailable: 1
# ...

This configuration includes the following fields:

  • minAvailable - Specifies the number of pods that must still be available after an eviction. This value can be either an absolute number or a percentage, for example 2 or 50%.
  • maxUnavailable - Specifies the number of pods that can be unavailable after an eviction. This value can be either an absolute number or a percentage, for example 1 or 50%.
Note

The minAvailable and maxUnavailable fields are mutually exclusive. You must configure only one of these fields. If both fields are specified, the minAvailable value takes precedence.

The semantics of these fields are aligned with the corresponding fields in the Kubernetes PodDisruptionBudget. For more information, see Pod Disruption Budgets in the Kubernetes documentation.

PodDisruptionBudget generation rules

The OpenShift Serverless Logic Operator applies the following rules to generate the PDB:

  1. The PDB is generated only if the workflow has the spec.podTemplate.podDisruptionBudget field properly configured.
  2. The PDB is generated only if the workflow has spec.podTemplate.replicas configured with a value greater than 1.
  3. If the workflow has a configured HorizontalPodAutoscaler (HPA), the HPA spec.minReplicas value takes precedence over the workflow spec.podTemplate.replicas value.
  4. When an HPA is configured, the PDB is generated only if the HPA spec.minReplicas value is greater than 1.
  5. If the workflow is scaled to zero (that is, spec.podTemplate.replicas = 0), no PDB is generated.
Note

If any of the above conditions change after a PDB has been generated, for example, if the workflow is rescaled to 1, the previously generated PDB is automatically deleted.

Important

Workflows deployed with spec.podTemplate.deploymentModel: knative cannot use a PodDisruptionBudget because Knative Serving automatically manages the number of replicas, and a PDB cannot reliably enforce minimum availability. Additionally, workflows deployed using the dev profile are not designed to scale.

Prerequisites

  • You have installed the OpenShift Serverless Logic Operator.
  • You have deployed a workflow using the preview or gitops profile.

Procedure

  1. Configure a PDB in your SonataFlow CR: 

    apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: example-workflow
  namespace: example-workflow-namespace
  annotations:
    sonataflow.org/description: Example Workflow
    sonataflow.org/version: 0.0.1
    sonataflow.org/profile: preview
spec:
  podTemplate:
    replicas: 2
    podDisruptionBudget:
      minAvailable: 1
  flow:
    start: ExampleStartState
# ...

    This configuration includes the following settings:

    • replicas: 2 - The workflow runs with 2 replicas.
    • podDisruptionBudget.minAvailable: 1 - The generated PDB ensures that 1 pod must remain available during a disruption.

  2. Apply the configuration: 

    $ oc apply -f example-workflow.yaml -n example-workflow-namespace

Verification

  • Verify that the PDB was created: 

    $ oc get pdb -n example-workflow-namespace
     
    NAME               MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-workflow   1               N/A               1                     5m

Given this configuration, the OpenShift Serverless Logic Operator generates the following PDB for the workflow: 

kind: PodDisruptionBudget
apiVersion: policy/v1
metadata:
  name: example-workflow
  namespace: example-workflow-namespace
  ownerReferences:
    - apiVersion: sonataflow.org/v1alpha08
      kind: SonataFlow
      name: example-workflow
      uid: 5b7f96d4-1ddf-45f7-af38-555d93339cca
      controller: true
      blockOwnerDeletion: true
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: example-workflow
      app.kubernetes.io/component: serverless-workflow
      app.kubernetes.io/instance: example-workflow
      app.kubernetes.io/managed-by: sonataflow-operator
      app.kubernetes.io/name: example-workflow
      sonataflow.org/workflow-app: example-workflow
      sonataflow.org/workflow-namespace: example-workflow-namespace

This generated PDB has the following characteristics:

  • The PDB has the same name as the workflow.
  • The PDB is created in the same namespace as the workflow.
  • The workflow is configured as the PDB owner.
  • The PDB minAvailable field is configured with the value from spec.podTemplate.podDisruptionBudget.minAvailable in the workflow CR.
  • The PDB selector is configured to target the workflow pods.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top