feat(dind): multi-queue support, Docker mode fixes, and gVisor sandbox support

[michaellzc]

related https://github.com/sourcegraph/sourcegraph/pull/12881

Summary

Multi-queue & executor improvements

• Add queues list to values: when set, renders one Deployment per queue instead of the single executor Deployment; each queue merges with global executor.env (queue overrides global) and supports replicaCount and resources overrides
• Add structured executor fields (frontendUrl, frontendPassword, queueName/queueNames, log, etc.) with validation that blocks managed env vars from env
• Per-queue queueName/queueNames fields (deployment name suffix vs queue env var are now independent)

Security

• Bind dockerd to 127.0.0.1:2375 instead of 0.0.0.0 — prevents unauthenticated Docker API access from other cluster pods

gVisor support (dind.gVisor.enabled: true)

Enables running executor pods on GKE node pools with sandbox-type=gvisor, providing stronger container-to-host isolation.
See: https://gvisor.dev/docs/tutorials/docker-in-gvisor/

Test plan

• Deployed to dev cluster with both batches and codeintel queues
• Verified executors are running in Docker mode (no RBAC errors)
• Verified gVisor pods reach 2/2 Running on sandbox.gke.io/runtime=gvisor nodes with 0 restarts
• helm template renders correctly for both multi-queue and single-deployment modes

🤖 Generated with Claude Code

[marcleblanc2]

This syntax seems awkward to operate (easier to get wrong than to get right for a new customer's junior admin)

queues:
  - name: batches
    replicaCount: 4
    env:
      EXECUTOR_QUEUE_NAME:
        value: batches
  - name: codeintel
    replicaCount: 4
    env:
      EXECUTOR_QUEUE_NAME:
        value: codeintel

If possible, this would be simpler:

queues:
  batches:
    replicaCount: 4
  codeintel:
    replicaCount: 4

Or this, if either queue can use the same number of replicas

queues:
  batches:
  codeintel:

[marcleblanc2]

Actually, to help reduce the transition cost of moving customers from the k8s Helm chart to this one, it'd be ideal if this Helm chart could read the same values from an override file which was successful with the k8s Helm chart @michaellzc

[marcleblanc2]

Some examples here: https://sourcegraph.sourcegraph.com/search?q=repo:%5Egithub%5C.com/sourcegraph/customer-assets$+lang:YAML+%5Eexecutor:$&patternType=regexp&sm=0

Also to note, it's common to use one Helm values override.yaml file when deploying multiple of our Helm charts, so the values which get read from multiple charts don't need to be maintained in duplicate in separate override files.

[marcleblanc2]

Left comments in the PR thread re: ergonomics of using the added YAML syntax; it looks easier to get wrong than it is to get right, especially for some of our self-hosted customer admins.

[filiphaftek]

@michaellzc the changes are very good and makes executore more mature, I only wonder about backward compatibility - I confirmed with DS that this might break existing executors, do we fix this for customers?

[marcleblanc2]

I only wonder about backward compatibility - I confirmed with DS that this might break existing executors, do we fix this for customers?

@filiphaftek I'm not aware of any customers currently using the DinD deployment method for Executors, and haven't found anything while searching for it in Slack. I'm not sure if we can decipher this via telemetry, or if a new telemetry field needs to be added.

[michaellzc]

@michaellzc the changes are very good and makes executore more mature, I only wonder about backward compatibility - I confirmed with DS that this might break existing executors, do we fix this for customers?

there is no backward compatibility concern. the chart has been broken from day one.

for example, the executor deployment manifest has been missing .metadata.name, the registry image has a typo regisry instead of registry.

some suggestion has been addressed

[sourcegraph-release-bot]

The backport to 7.3.x failed at https://github.com/sourcegraph/deploy-sourcegraph-helm/actions/runs/27037785081:

Reviews may only be requested from collaborators. One or more of the teams you specified is not a collaborator of the sourcegraph/deploy-sourcegraph-helm repository.

To backport this PR manually, you can either:

Via the sg tool

Use the sg backport command to backport your commit to the release branch.

sg backport -r 7.3.x -p 876

Via your terminal

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-7.3.x 7.3.x
# Navigate to the new working tree
cd .worktrees/backport-7.3.x
# Create a new branch
git switch --create backport-876-to-7.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 09972342271f0863de1ed98be81ca25327d86933
# Push it to GitHub
git push --set-upstream origin backport-876-to-7.3.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-7.3.x

If you encouter conflict, first resolve the conflict and stage all files, then run the commands below:

git cherry-pick --continue
# Push it to GitHub
git push --set-upstream origin backport-876-to-7.3.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-7.3.x

• Follow above instructions to backport the commit.
• Create a pull request where the base branch is 7.3.x and the compare/head branch is backport-876-to-7.3.x., click here to create the pull request.

Once the pull request has been created, please ensure the following:

• Make sure to tag @sourcegraph/release in the pull request description.

• kindly remove the release-blocker from this pull request.