feat: run several worker pools in one WorkerDeployment

[gibbonjj]

Run several worker pools in one WorkerDeployment. Each pool has its own Deployment spec, and all pools share one Temporal version.

Problem. A workflow on the orders queue calls an activity on the payments queue. With one CR per role, payments is a separate version, so during a ramp a v2 workflow's activity can run on v1.

Fix. Run both roles as pools of one orders CR. They share the build ID, so the activity runs on v2. Each pool keeps its own pods, replicas and autoscaler.

flowchart LR
  wd["WorkerDeployment orders"]
  wd --> v2
  wd --> v1
  subgraph v2 ["Version v2 (current)"]
    w2["Deployment orders-workflows-v2<br/>workflows pool, orders queue"]
    p2["Deployment orders-payments-v2<br/>payments pool, payments queue"]
  end
  subgraph v1 ["Version v1 (draining)"]
    w1["orders-workflows-v1"]
    p1["orders-payments-v1"]
  end
  k["KEDA ScaledObject<br/>one per pool per version"] -.-> p2

Loading

apiVersion: temporal.io/v1alpha1
kind: WorkerDeployment
metadata:
  name: orders
spec:
  pools:                 # in place of spec.deployment
    - name: workflows
      deployment:
        replicas: 2
        template: {...}
    - name: payments     # own pods and scaling
      deployment:
        template: {...}
  rollout:
    strategy: Progressive
    steps: [{rampPercentage: 10, pauseDuration: 10m}]
  workerOptions:
    connectionRef: {name: temporal}
    temporalNamespace: orders
---
apiVersion: temporal.io/v1alpha1
kind: WorkerResourceTemplate
metadata:
  name: orders-payments-keda
spec:
  workerDeploymentRef: {name: orders}
  pool: payments         # targets only the payments Deployments
  template:
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    spec:
      scaleTargetRef: {}
      minReplicaCount: 1
      triggers:
        - type: temporal
          metadata: {taskQueue: payments, queueTypes: activity, targetQueueSize: "5",
                     namespace: "", workerDeploymentName: "", workerDeploymentBuildId: ""}

What the controller creates from this

For build v2-2d5bea39fd. Owner references, hash annotations and the default strategy are left out.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    temporal.io/build-id: v2-2d5bea39fd
    temporal.io/deployment-name: orders
    temporal.io/worker-pool: workflows
  name: orders-workflows-v2-2d5bea39fd-0e5932f9
  namespace: prod
spec:
  replicas: 2
  selector:
    matchLabels:
      temporal.io/build-id: v2-2d5bea39fd
      temporal.io/deployment-name: orders
      temporal.io/worker-pool: workflows
  template:
    metadata:
      labels:
        temporal.io/build-id: v2-2d5bea39fd
        temporal.io/deployment-name: orders
        temporal.io/worker-pool: workflows
    spec:
      containers:
      - env:
        - name: WORKER_ROLE
          value: workflows
        - name: TEMPORAL_ADDRESS
          value: temporal.example.com:7233
        - name: TEMPORAL_NAMESPACE
          value: orders
        - name: TEMPORAL_DEPLOYMENT_NAME
          value: prod/orders
        - name: TEMPORAL_WORKER_BUILD_ID
          value: v2-2d5bea39fd
        image: registry.example.com/orders:v2
        name: worker
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    temporal.io/build-id: v2-2d5bea39fd
    temporal.io/deployment-name: orders
    temporal.io/worker-pool: payments
  name: orders-payments-v2-2d5bea39fd-53a96503
  namespace: prod
spec:
  selector:
    matchLabels:
      temporal.io/build-id: v2-2d5bea39fd
      temporal.io/deployment-name: orders
      temporal.io/worker-pool: payments
  template:
    metadata:
      labels:
        temporal.io/build-id: v2-2d5bea39fd
        temporal.io/deployment-name: orders
        temporal.io/worker-pool: payments
    spec:
      containers:
      - env:
        - name: WORKER_ROLE
          value: payments
        - name: TEMPORAL_ADDRESS
          value: temporal.example.com:7233
        - name: TEMPORAL_NAMESPACE
          value: orders
        - name: TEMPORAL_DEPLOYMENT_NAME
          value: prod/orders
        - name: TEMPORAL_WORKER_BUILD_ID
          value: v2-2d5bea39fd
        image: registry.example.com/orders:v2
        name: worker
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  labels:
    temporal.io/build-id: v2-2d5bea39fd
    temporal.io/deployment-name: orders
    temporal.io/worker-pool: payments
  name: orders-orders-payments-keda-v2-2d5bea3-4e426a8c
  namespace: prod
spec:
  minReplicaCount: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: orders-payments-v2-2d5bea39fd-53a96503
  triggers:
  - metadata:
      namespace: orders
      queueTypes: activity
      targetQueueSize: "5"
      taskQueue: payments
      workerDeploymentBuildId: v2-2d5bea39fd
      workerDeploymentName: prod/orders
    type: temporal

Temporal sees one version, prod/orders:v2-2d5bea39fd, with the orders queue (workflow) and the payments queue (activity). While v1 drains, the same set exists for v1.

Notes:

• A CR sets spec.pools or spec.deployment. CRs without pools are unchanged.
• Activity-only pools must turn off workflow polling (Go: DisableWorkflowWorker).

Draft to make the shape discussed in #330 concrete. Unit tests, make lint and the full integration suite pass.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}