Install a worker

Create a project worker and apply its generated Kubernetes manifests in the required order.

The RestoreTrust console creates a worker identity and generates manifests specifically for that worker. Use those manifests as the installation source; do not start from a copied manifest belonging to another worker.

Before you begin

You need:

a Kubernetes 1.29 or newer cluster;
kubectl access with the required permissions;
a suitable scratch StorageClass;
two dedicated namespace names;
approved outbound connectivity for the generated worker target and image registries.

RestoreTrust publishes its agent and validator images in public Docker Hub repositories. The generated manifests and execution plan identify the exact images to pull; allow those image references and any selected database images through your registry policy. Do not replace a generated digest with an unpinned latest tag.

The identity is shown once

The generated identity manifest contains a secret worker token. Copy the complete installation before closing the creation dialog. Do not paste it into tickets, chat, shell history, or logs. RestoreTrust does not show the token again.

Install from the console

1
Create the project worker
In the RestoreTrust console, open the project, go to Project workers, and select Create project worker.
Enter a name, description, country, and Max parallel jobs value from 1 to 64. The capacity controls concurrent restore Jobs; it does not change the agent replica count.
2
Choose cluster settings
Select different agent and job namespaces. Keep the suggested names or enter unique names for this worker.
Select the scratch StorageClass. Leaving it empty uses the cluster default. Each schedule sets its own scratch size.
3
Apply RBAC and the egress floor
Copy the RBAC apply command from the creation dialog and run it first. It creates both namespaces, ServiceAccounts, namespace-scoped permissions, and the DNS-only egress floor.
Verify the floor before continuing:
bash
kubectl -n <JOB_NAMESPACE> get networkpolicy restoretrust-job-egress-floorkubectl -n <JOB_NAMESPACE> get serviceaccount restoretrust-job
4
Create the identity Secret
Copy and apply the generated Identity secret manifest. The Secret must be named restoretrust-worker-identity in the agent namespace.
Confirm that it exists without printing its value:
bash
kubectl -n <AGENT_NAMESPACE> get secret restoretrust-worker-identity
5
Deploy the agent
Apply the generated Agent deployment manifest. It uses an immutable image digest, mounts the identity Secret read-only, and creates exactly one agent Pod with a Recreate strategy.
bash
kubectl -n <AGENT_NAMESPACE> rollout status deployment/restoretrust-k8s-agent --timeout=5mkubectl -n <AGENT_NAMESPACE> get pods -l app.kubernetes.io/name=restoretrust-k8s-agent
6
Apply optional egress admission
On Kubernetes 1.30 or newer, review and apply the generated Egress admission manifest. It prevents other NetworkPolicies from widening access for restore Pods in this job namespace.
Skip this step on Kubernetes 1.29.
One generated admission policy per cluster
The generated admission objects are cluster-scoped and target one job namespace. Before applying them in a cluster that already has another RestoreTrust worker, inspect the existing restoretrust-managed-egress-v1 policy. Do not overwrite a policy protecting a different job namespace; contact RestoreTrust support for a reviewed multi-namespace policy.
7
Verify registration
Open the worker detail page. Its status should change from Created to Online after the Pod connects.
Confirm that Accepting jobs is Yes and Effective claim capacity is greater than zero. If the worker remains Created, continue with Troubleshooting.

After installation

Create source and backup-encryption Secrets only in the job namespace. Then assign the worker to a schedule and run a small manual check to validate DNS, source access, image pulls, and scratch provisioning.

Keep one Pod per identity

Do not add an HPA, change replicas, or use a rolling update. A second live Pod with the same identity is rejected. Create another project worker when you need another agent identity.

If you close the creation dialog before saving the identity manifest, uninstall the unregistered Created worker and create a replacement. The original token cannot be recovered.

Related topics

Loading documentation…

Before you begin

You need:

a Kubernetes 1.29 or newer cluster;

kubectl access with the required permissions;

a suitable scratch StorageClass;

two dedicated namespace names;

approved outbound connectivity for the generated worker target and image registries.

The identity is shown once

Install from the console

Create the project worker

In the RestoreTrust console, open the project, go to Project workers, and select Create project worker.

Enter a name, description, country, and Max parallel jobs value from 1 to 64. The capacity controls concurrent restore Jobs; it does not change the agent replica count.

Choose cluster settings

Select different agent and job namespaces. Keep the suggested names or enter unique names for this worker.

Select the scratch StorageClass. Leaving it empty uses the cluster default. Each schedule sets its own scratch size.

Apply RBAC and the egress floor

Copy the RBAC apply command from the creation dialog and run it first. It creates both namespaces, ServiceAccounts, namespace-scoped permissions, and the DNS-only egress floor.

Verify the floor before continuing:

bash

kubectl -n <JOB_NAMESPACE> get networkpolicy restoretrust-job-egress-floorkubectl -n <JOB_NAMESPACE> get serviceaccount restoretrust-job

Create the identity Secret

Copy and apply the generated Identity secret manifest. The Secret must be named restoretrust-worker-identity in the agent namespace.

Confirm that it exists without printing its value:

bash

kubectl -n <AGENT_NAMESPACE> get secret restoretrust-worker-identity

Deploy the agent

Apply the generated Agent deployment manifest. It uses an immutable image digest, mounts the identity Secret read-only, and creates exactly one agent Pod with a Recreate strategy.

bash

kubectl -n <AGENT_NAMESPACE> rollout status deployment/restoretrust-k8s-agent --timeout=5mkubectl -n <AGENT_NAMESPACE> get pods -l app.kubernetes.io/name=restoretrust-k8s-agent

Apply optional egress admission

On Kubernetes 1.30 or newer, review and apply the generated Egress admission manifest. It prevents other NetworkPolicies from widening access for restore Pods in this job namespace.

Skip this step on Kubernetes 1.29.

One generated admission policy per cluster

The generated admission objects are cluster-scoped and target one job namespace. Before applying them in a cluster that already has another RestoreTrust worker, inspect the existing restoretrust-managed-egress-v1 policy. Do not overwrite a policy protecting a different job namespace; contact RestoreTrust support for a reviewed multi-namespace policy.

Verify registration

Open the worker detail page. Its status should change from Created to Online after the Pod connects.

Confirm that Accepting jobs is Yes and Effective claim capacity is greater than zero. If the worker remains Created, continue with Troubleshooting.

After installation

Keep one Pod per identity

Do not add an HPA, change replicas, or use a rolling update. A second live Pod with the same identity is rejected. Create another project worker when you need another agent identity.

If you close the creation dialog before saving the identity manifest, uninstall the unregistered Created worker and create a replacement. The original token cannot be recovered.