Worker operations
Prepare, install, secure, monitor, upgrade, and remove a RestoreTrust project worker in your Kubernetes cluster.
Loading documentation…
Powered by heyo
A RestoreTrust project worker runs restore checks inside your Kubernetes cluster. It belongs to one RestoreTrust project, and schedules in that project select the worker that should run them.
The worker consists of:
Backup downloads and restores run in your cluster. Source credential values and temporary restored databases stay there; the worker sends execution status, logs, probe results, and selected-file metadata to RestoreTrust. RestoreTrust sends the execution plan, and the worker creates and supervises the corresponding Kubernetes Job.
| Area | What you operate |
|---|---|
| Kubernetes | A supported cluster, two dedicated namespaces, RBAC, Pod Security admission, and NetworkPolicy enforcement |
| Identity | One generated identity Secret and exactly one agent Pod for each worker |
| Storage | A dynamic StorageClass and enough capacity for every concurrent restore |
| Network | Outbound connectivity for the agent, image pulls, DNS, and the configured backup sources |
| Lifecycle | Installation, health checks, generated Deployment upgrades, and cluster cleanup during uninstall |
Restore Jobs run in a namespace separate from the agent and its identity Secret. They use a ServiceAccount without a Kubernetes API token or RBAC permissions. A namespace-wide egress floor allows DNS only; the worker adds a source-specific egress policy for each execution.
A worker identity may be used by exactly one agent Pod. Keep replicas: 1,
use the generated Recreate strategy, and increase Max parallel jobs for
more capacity. To add another agent Pod, create another project worker with
its own identity and namespace pair.
Recreate rollout.A schedule can select only a worker from the same project. Create source credentials and backup-encryption Secrets in that worker's job namespace; never place them in the agent namespace.