Skip to main content

signadot cluster

Adding Clusters​

You can use the cluster add sub-command to begin the process of connecting a Kubernetes cluster to Signadot:

signadot cluster add --name my-cluster

The --name that you specify is only used within Signadot. It's the value you'll pass back in other commands to tell Signadot which Kubernetes cluster you want to work with.

The cluster add command will generate the first auth token for that cluster and provide an example kubectl command to install the cluster token as a Secret.

You can use signadot cluster list to see the names of clusters already registered with Signadot.

Managing Clusters​

You can use the signadot cluster token subcommands to manage your existing clusters. For example, here's how to rotate the cluster token for one of your configured clusters:

List the existing tokens for cluster <cluster-name>:

signadot cluster token list --cluster <cluster-name>
ID              TOKEN               CREATED                LAST CONNECTED   LAST CONNECTED IP
pctkw1l1uf2l2   ddvcorp@ak49o8...   2025-08-05T17:28:26Z

Create a new cluster token:

CLUSTER_TOKEN=$(signadot cluster token create --cluster test)

Recreate the in-cluster cluster-agent secret. If you specified a custom secret name during installation using the agent.tokenSecret setting, make sure to use that name instead of the default.

kubectl -n signadot delete secret cluster-agent
kubectl -n signadot create secret generic cluster-agent --from-literal=token=$CLUSTER_TOKEN

Restart the agent deployment:

kubectl -n signadot rollout restart deploy agent

Delete the old cluster token:

signadot cluster token delete --cluster <cluster-name> <token-id>

If you run into connection issues, check that:

  • The cluster token is correctly applied to your cluster
  • Your cluster has outbound access to Signadot

Managing DevMesh Enabled Workloads​

When using DevMesh, you can inspect the status of DevMesh-enabled workloads within a cluster using the signadot cluster devmesh analyze command.

For example:

signadot cluster devmesh analyze --cluster <cluster-name>
KIND         NAMESPACE        NAME       UP-TO-DATE     STATUS         REASON
Deployment   hotrod-devmesh   driver     0/1            NEEDS_UPDATE   1 pods without expected version
Deployment   hotrod-devmesh   frontend   0/2            NEEDS_UPDATE   1 pods without expected version, 1 pods with missing sidecar
Deployment   hotrod-devmesh   location   1/1            OK             
Deployment   hotrod-devmesh   route      0/2            MISSING        2 pods with missing sidecar

This command is especially useful for identifying workloads with outdated or missing DevMesh sidecars. Once identified, you can restart the affected workloads to trigger sidecar updates automatically. This is a convenient way to ensure your workloads are running with up-to-date DevMesh sidecars.

You can also script the restart of baseline workloads that require updates using the signadot cluster devmesh analyze command. Here's an example that filters workloads with a NEEDS_UPDATE or MISSING status and restarts them accordingly:

signadot cluster devmesh analyze --cluster <cluster-name> --status=NEEDS_UPDATE,MISSING -o json \
| jq -r '
    .[] |
    if .workload.kind == "Rollout" then
      "kubectl argo rollouts restart " + .workload.name + " -n " + .workload.namespace
    else
      "kubectl rollout restart " + .workload.kind + "/" + .workload.name + " -n " + .workload.namespace
    end
  ' \
| bash