ScyllaDB Manager¶

Deployment model¶

ScyllaDB Manager runs as a single, shared Deployment in the scylla-manager namespace. One Manager instance serves all ScyllaDB clusters in the Kubernetes cluster.

Manager requires a small ScyllaDB database to store its own state (task definitions, run history, cluster metadata). This is provided by a dedicated ScyllaCluster resource named scylla-manager-cluster in the scylla-manager namespace, running in developer mode with minimal resources (1 node, 1 CPU, 200 MiB memory).

Manager depends on ScyllaDB Operator — the Operator must be installed first because the backing cluster uses the ScyllaCluster CRD. Additionally, a NodeConfig must be applied and the ScyllaDB Local CSI Driver must be installed to provide storage for the backing cluster.

Manager Agent¶

Each ScyllaDB pod runs a ScyllaDB Manager Agent as a sidecar container. The Agent communicates with Manager to execute operations on the local node (streaming repair data, uploading backup snapshots to object storage, etc.).

The Agent:

• Listens on port 10001.

• Waits for ignition before starting — it does not run until ScyllaDB itself is ready.

• Is configured through layered YAML config files and an auth token that the Operator manages automatically.

• Uses the image specified by the agentVersion and agentRepository fields on the ScyllaCluster spec.

Task synchronisation¶

The Operator bridges your cluster spec to Manager tasks through a chain of internal resources.

ScyllaCluster defines backup and repair tasks inline:

spec:
  backups:
    - name: daily-backup
      location:
        - s3:my-bucket
      retention: 7
      cron: "0 2 * * *"
  repairs:
    - name: weekly-repair
      cron: "0 0 * * 0"

The ScyllaCluster controller translates each entry into a ScyllaDBManagerTask resource in the same namespace.

Disabling Manager integration¶

If you do not want a ScyllaCluster to be managed by the shared Manager instance, add the annotation:

metadata:
  annotations:
    scylla-operator.scylladb.com/disable-global-scylladb-manager-integration: "true"

This prevents the Operator from creating registration and task resources for that cluster.

Security¶

Because Manager is a shared instance, access to the scylla-manager namespace grants control over all registered clusters’ repair and backup tasks.

The Manager Agent authenticates with Manager using an auth token. The Operator generates and distributes these tokens automatically — one per cluster — via Secrets in the cluster’s namespace.

A NetworkPolicy in the scylla-manager namespace allows Manager to reach the backing ScyllaDB cluster pods within that namespace.

Multi-datacenter Manager integration¶

In a multi-datacenter cluster built from multiple ScyllaCluster resources (one per Kubernetes cluster), ScyllaDB Manager must be deployed in only one datacenter. Manager communicates with all nodes across datacenters through the Manager Agent running in each pod.

Every ScyllaCluster is provisioned with a unique, randomly generated auth token stored in a Secret named <cluster>-auth-token. For Manager to manage nodes in all datacenters, every datacenter must use the same auth token. You must manually synchronize the token:

1. Extract the token from the datacenter where Manager is deployed:

   kubectl --context="${CONTEXT_DC1}" -n=<namespace> get secrets/<cluster>-auth-token \
     --template='{{ index .data "auth-token.yaml" }}' | base64 -d
   

2. Patch the token into each remote datacenter’s Secret:

   kubectl --context="${CONTEXT_DC2}" -n=<namespace> patch secret/<cluster>-auth-token \
     --type='json' \
     -p='[{"op": "add", "path": "/stringData", "value": {"auth-token.yaml": "<output-from-step-1>"}}]'
   

3. Rolling restart the remote datacenter so the Agents pick up the new token:

   kubectl --context="${CONTEXT_DC2}" -n=<namespace> patch scyllacluster/<cluster> \
     --type='merge' \
     -p='{"spec": {"forceRedeploymentReason": "sync manager-agent auth token"}}'
   

4. Define Manager tasks on the ScyllaCluster in the Kubernetes cluster where Manager is running.

Limitations¶

• Restore is not yet available through the Operator’s declarative API. To restore from a Manager backup, you must exec into the Manager pod and use sctool directly. See Back up and restore.

• There is one global Manager instance per Kubernetes cluster. Multi-tenancy isolation between clusters sharing the same Manager is limited to auth tokens.

• Manager functionality beyond backup and repair (e.g., healthcheck configuration) is not yet exposed through CRDs.