A Dapr component is the configurable backing implementation for a Dapr API capability. Platform teams connect an API such as state management to an external service or infrastructure mechanism, while applications use the API without knowing which implementation supplies it. section 7.3.2
On Kubernetes, an application annotated for Dapr receives a daprd sidecar in the same pod. The application calls the sidecar through localhost over HTTP or gRPC; the sidecar reads component configuration and connects to the backing service. section 7.3.2
A component configuration establishes:
- The infrastructure boundary hidden from application code: Service A can store and read data through the local state API without knowing whether Redis is used. section 7.3.2
Redis-backed state store
Apply a Kubernetes resource with apiVersion dapr.io/v1alpha1, kind Component, and metadata.name statestore. Set spec.type to state.redis, configure redisHost as redis-master:6379, and reference the redis-password key from the redis secret. A Dapr-enabled service can then use the local state endpoint to store and retrieve values.
Listing 7.1 Dapr Statestore component definition
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.redis #1
version: v1
metadata:
- name: keyPrefix
value: name
- name: redisHost #2
value: redis-master:6379
- name: redisPassword #3
secretKeyRef:
name: redis
key: redis-password
auth:
secretStore: kubernetes
Inspect the complete component resource showing its Kubernetes API version, Redis type, metadata, host, password reference, and secret store. section 7.3.2
Changing component implementations can support movement across cloud providers without changing application code. Dapr sidecars also provide a place to enforce platform rules and extract metrics from Dapr-enabled applications and components. section 7.3.3
