Namespaced actors

Learn about namespaced actors

Namespacing in Dapr provides isolation, and thus multi-tenancy. With actor namespacing, the same actor type can be deployed into different namespaces. You can call instances of these actors in the same namespace.

Note

Each namespaced actor deployment must use its own separate state store, especially if the same actor type is used across namespaces. In other words, no namespace information is written as part of the actor record, and hence separate state stores are required for each namespace. See Configuring actor state stores for namespacing section for examples.

Creating and configuring namespaces

You can use namespaces either in self-hosted mode or on Kubernetes.

In self-hosted mode, you can specify the namespace for a Dapr instance by setting the NAMESPACE environment variable.

On Kubernetes, you can create and configure namepaces when deploying actor applications. For example, start with the following kubectl commands:

  1. kubectl create namespace namespace-actorA
  2. kubectl config set-context --current --namespace=namespace-actorA

Then, deploy your actor applications into this namespace (in the example, namespace-actorA).

Configuring actor state stores for namespacing

Each namespaced actor deployment must use its own separate state store. While you could use different physical databases for each actor namespace, some state store components provide a way to logically separate data by table, prefix, collection, and more. This allows you to use the same physical database for multiple namespaces, as long as you provide the logical separation in the Dapr component definition.

Some examples are provided below.

Example 1: By a prefix in etcd

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: statestore
  5. spec:
  6.   type: state.etcd
  7.   version: v2
  8.   metadata:
  9.   - name: endpoints
  10.     value: localhost:2379
  11.   - name: keyPrefixPath
  12.     value: namespace-actorA
  13.   - name: actorStateStore
  14.     value: "true"

Example 2: By table name in SQLite

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: statestore
  5. spec:
  6.   type: state.sqlite
  7.   version: v1
  8.   metadata:
  9.   - name: connectionString
  10.     value: "data.db"
  11.   - name: tableName
  12.     value: "namespace-actorA"
  13.   - name: actorStateStore
  14.     value: "true"

Example 3: By logical database number in Redis

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: statestore
  5. spec:
  6.   type: state.redis
  7.   version: v1
  8.   metadata:
  9.   - name: redisHost
  10.     value: localhost:6379
  11.   - name: redisPassword
  12.     value: ""
  13.   - name: actorStateStore
  14.     value: "true"
  15.   - name: redisDB
  16.     value: "1"
  17.   - name: redisPassword
  18.     secretKeyRef:
  19.       name: redis-secret
  20.       key:  redis-password
  21.   - name: actorStateStore
  22.     value: "true"
  23.   - name: redisDB
  24.     value: "1"
  25. auth:
  26.   secretStore: <SECRET_STORE_NAME>

Check your state store component specs to see what it provides.

Note

Namespaced actors use the multi-tenant Placement service. With this control plane service where each application deployment has its own namespace, sidecars belonging to an application in namespace “ActorA” won’t receive placement information for an application in namespace “ActorB”.

Next steps

Last modified October 11, 2024: Fixed typo (#4389) (fe17926)