Automation Configuration - CrewAI Platform Helm Chart

The automation configuration controls how crew pods (automation workloads) are scheduled within your Kubernetes cluster. These settings apply to all crew pods provisioned by the platform, including web servers, workers, and Redis instances for each automation.

This feature requires chart version 0.1.14 or later.

`automation.podScheduling.*`

Scheduling constraints applied to every crew pod provisioned by this platform installation. These settings are applied to each crew pod at creation time.

object

default:"{}"

Node selector labels for crew pod placement.Purpose: Constrains crew pods to nodes with specific labels, useful for dedicating certain nodes to automation workloads.Default Behavior: Empty object ({}) - no node selector constraints applied.Example - Pin crews to dedicated node pool:

automation:
  podScheduling:
    nodeSelector:
      workload-type: "automation"
      node-role.kubernetes.io/worker: "true"

Example - Pin to specific cloud provider node group:

automation:
  podScheduling:
    nodeSelector:
      eks.amazonaws.com/nodegroup: "crew-workloads"

When to Use:

Isolate automation workloads on dedicated nodes
Ensure crews run on nodes with specific hardware (GPU, high CPU, SSD)
Separate automation pods from platform infrastructure pods

array

default:"[]"

Tolerations for crew pods to schedule on tainted nodes.Purpose: Allows crew pods to be scheduled on nodes with matching taints, typically used in combination with nodeSelector to reserve nodes exclusively for automation workloads.Default Behavior: Empty array ([]) - no tolerations applied.Example - Tolerate dedicated automation node pool:

automation:
  podScheduling:
    tolerations:
      - key: "workload-type"
        operator: "Equal"
        value: "automation"
        effect: "NoSchedule"

Example - Multiple tolerations:

automation:
  podScheduling:
    tolerations:
      - key: "automation-pool"
        operator: "Equal"
        value: "enabled"
        effect: "NoSchedule"
      - key: "gpu-workload"
        operator: "Exists"
        effect: "NoExecute"

Toleration Operators:

Equal - Key and value must match
Exists - Only key must exist (value ignored)

Taint Effects:

NoSchedule - Pods won’t schedule unless toleration exists
PreferNoSchedule - Soft constraint (scheduler tries to avoid)
NoExecute - Evicts running pods without matching toleration

object

default:"{}"

Advanced scheduling rules for crew pod placement.Purpose: Provides fine-grained control over pod scheduling using node affinity, pod affinity, and pod anti-affinity rules.Default Behavior: Empty object ({}) - no affinity rules applied.Example - Require SSD nodes:

automation:
  podScheduling:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: "disktype"
                  operator: "In"
                  values: ["ssd"]

Example - Prefer specific availability zones:

automation:
  podScheduling:
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
                - key: "topology.kubernetes.io/zone"
                  operator: "In"
                  values: ["us-west-2a", "us-west-2b"]

Affinity Types:

nodeAffinity - Schedule based on node labels
podAffinity - Schedule near other pods
podAntiAffinity - Schedule away from other pods

Scheduling Modes:

requiredDuringSchedulingIgnoredDuringExecution - Hard constraint (pod won’t schedule if rule not met)
preferredDuringSchedulingIgnoredDuringExecution - Soft constraint (scheduler tries to satisfy but not guaranteed)

Complete Example

This example demonstrates isolating automation workloads on a dedicated, tainted node pool with specific hardware requirements:

automation:
  podScheduling:
    # Pin crews to dedicated automation nodes
    nodeSelector:
      automation-pool: "enabled"
      disktype: "ssd"
    
    # Allow scheduling on tainted automation nodes
    tolerations:
      - key: "automation-pool"
        operator: "Equal"
        value: "enabled"
        effect: "NoSchedule"
    
    # Require high-performance nodes
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: "node.kubernetes.io/instance-type"
                  operator: "In"
                  values: ["c5.2xlarge", "c5.4xlarge"]

Important Notes

Changing automation.podScheduling values requires two steps to take effect:

Run helm upgrade to update the platform configuration (this restarts the platform pod)
Redeploy existing crews for them to adopt the new scheduling constraints

Kubernetes only applies scheduling fields (nodeSelector, tolerations, affinity) at pod creation time. Existing crew pods will continue running with their previous scheduling configuration until redeployed.

Chart Version Requirement

This feature is available in chart version 0.1.14 or later. Earlier chart versions do not support automation pod scheduling configuration.

Empty Values Behavior

The chart preserves empty values ({} for objects, [] for arrays) so the platform can distinguish between:

Unset - Key not present (use platform defaults)
Reset to empty - Key present but empty (explicitly remove constraints)

Leave a sub-key at its default empty value to omit that scheduling constraint type.

​automation.podScheduling.*

​Complete Example

​Important Notes

​Chart Version Requirement

​Empty Values Behavior

`automation.podScheduling.*`

Complete Example

Important Notes

Chart Version Requirement

Empty Values Behavior