Skip to main content
Version: v0.21.0

Deployment

Every Analytics Data Plane uses explicit execution owners, authenticated signaling and isolated Docker or Kubernetes jobs. Configure one owner for a single-tenant deployment or several owners for a shared worker. There is no controlPlane.mode setting. See tenant-aware execution for the complete authority, runtime and migration requirements.

The Control Plane provisions each tenant's registration with the worker's exact dataplaneId, reachable endpoint and executionLease: true. The worker does not self-register. Standalone workers and split servers require a nonempty controlPlane.executionScopes list. Split clients require matching split.executionScopes and an assigned authenticated bridge identity.

Docker​

Run the standalone worker or split client in a Docker container that can access the Docker socket. Set orchestration.workerContainer to that container's exact name or ID. The controller must carry the verified worker identity labels described in tenant-aware execution.

orchestration:
  type: docker
  socketPath: /var/run/docker.sock
  workerContainer: analytics-worker
  allowedImages:
    - registry.example/approved-algorithm@sha256:<digest>
  pullPolicy: Always
  preloadedImages: []
  limits:
    runAsUser: 1000
    tmpfsSize: 67108864
    memory: 536870912
    nanoCpus: 1000000000

Use Linux Docker Engine 28 or newer with isolated gateway support. Each job gets an internal bridge attached only to the job and its verified worker. The runtime derives the callback address from that bridge. Docker network, mountFiles and fixed callbackUrl settings are unsupported. Workers using host networking cannot attach to these per-job bridges.

The Docker socket gives the controller container-management permissions. Algorithm jobs receive neither the socket nor host dataset mounts. Sources stay behind the job capability proxy. Jobs run without external network routes, with a read-only root filesystem, bounded writable directories and resource limits. Qualify the actual daemon's network boundary before relying on it.

Kubernetes​

Select an explicit kubeconfig context or in-cluster, an administrator-controlled nondefault job namespace and a separate tokenless job ServiceAccount. Verify the actual cluster's CNI enforces NetworkPolicy and permits only the intended worker callback.

orchestration:
  type: kubernetes
  context: in-cluster
  namespace: analytics-jobs
  allowedImages:
    - image: registry.example/approved-algorithm@sha256:<digest>
      command: [node, /app/job.mjs]
  jobServiceAccount: analytics-job
  callbackUrl: http://10.0.0.12:3000
  workerNamespace: analytics-workers
  workerPodSelector:
    app: analytics-worker
  resourceRequests: { cpu: 100m, memory: 128Mi }
  resourceLimits: { cpu: "1", memory: 512Mi }

Replace the example address with the running worker's literal Pod IP and API port. The worker verifies the selected running pod owns that address and does not use host networking. Service DNS names are insufficient. Jobs receive no DNS egress, dataset PVC, host path or service-account token. A worker Pod IP change fences existing work.

The Helm chart creates the controller's runtime RBAC and, by default, a separate tokenless job account. Create its job namespace before installation. Set kubernetes.createJobServiceAccount: false when supplying an existing unprivileged account. The chart sets the callback through the downward API; its callback includes the configured API port, subpath and /api prefix. See the chart README.

Images and retained state​

Approve exact cooperative algorithm images and prefer digest pins. Docker pulls to verify registry access; Kubernetes checks the manifest independently before scheduling. Failed authorization or pulls stop the job. preloadedImages explicitly permits every configured owner to use listed cached images with IfNotPresent or Never. Submitted credentials still require registry authorization and a successful pull.

Images must support the configured nonroot UID, read-only root filesystem and bounded /tmp. Both runtimes provide a read-only JSON file through ALGORITHM_INSTANCE_FILE. Docker populates a job-specific volume through the archive API; Kubernetes uses a ConfigMap. Shell tools are not required. Jobs use API-based authority checks; see shared execution for worker-outage limits. These controls require approved images and do not protect against a compromised controller.

Before upgrading a former dedicated deployment, drain its jobs, stop old runtime resources and back up its database. Keep participant databases separate. Configure explicit ownership and submit fresh flows and jobs. Historical ownership remains null and fenced. Preserve split runner authority history. See migration.