Skip to main content

Components

Dapr components connect applications to underlying infrastructure resources via the Dapr Building Block APIs. Conductor provides visibility into all Dapr components deployed on a connected Kubernetes cluster.

For every component, core details such as component name, namespace, type, version and scoped applications are displayed.

In addition, the component is assigned an Initialization Status which provides an easy way for users to catch potential component configuration errors. The below section covers this concept in more detail.

component list

Component Initialization​

Dapr component initialization runs on a minute-by-minute basis to ensure all components running in a cluster are configured correctly before being loaded by Dapr-enabled applications. The component initialization is comprised of the following steps:

  1. The Conductor agent retrieves a list of all Dapr resources of kind Component across namespaces in the cluster
  2. A programmatically instantiated version of each component will be created inside the Conductor agent, where its metadata fields will be applied and the associated Init function will be executed. This result will then be reported back to Diagrid Cloud.
  3. The result is shown in the Conductor console in the Initialization Status column of both the Cluster and App Components lists. A green checkmark is displayed when the component has been initialized successfully, and a red icon for an error, along with the error message and timestamp from the last time the error occurred. This result can also be seen in each component's manifest in the initStatus field by clicking on "View Raw". The absence of the initStatus field indicates that the component was initialized successfully. See an example of a component that failed to initialize below:

component fail

Known Limitations​

Unsupported components​

For security reasons, the agent doesn't have access to the application container. This means the following components cannot be validated will always appear initialized successfully: bindings.localstorage, secretstores.local.env, secretstores.local.file

Pod-identity enabled components​

Dapr components that use pod identity mechanisms such as Azure Active Directory Workload Identity or IAM Roles for pods with a Kubernetes service account will always fail to be initialized due to lack of permissions on the Conductor agent pod to authenticate with the identity provider and validate the component

Cross-namespace component checks​

Some components that reside in a different namespace than the Conductor agent have dependencies that can lead to false communication errors, when in fact the component is healthy in its own namespace. Kubernetes network policies between namespaces can also cause incorrect component initialization statuses. For example:

Let's say a Dapr-enabled app that uses the following MongoDB component is deployed in the namespace crud-app. The MongoDB server has a hostname mongo-mongodb and is deployed with a Kubernetes Service in the same crud-app namespace.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: mongo-statestore
  namespace: crud-app
spec:
  type: state.mongodb
  version: v1
  metadata:
  - name: host
    value: mongo-mongodb:27017

Because the Conductor agent is running in the diagrid-cloud namespace, when the component's Init function runs, it will attempt to connect to hostname mongo-mongodb:27017. Since this hostname does not resolve in the diagrid-cloud namespace, Init will result in a communication error.

Mitigation

For the agent to check the component initialization status successfully, it's suggested to specify the service's name along with its corresponding namespace in the connection details like mongo-mongodb.crud-app:27017, or use the full hostname like mongo-mongodb.crud-app.svc.cluster.local:27017.

The following components do not abide to the above limitations and will always be validated successfully without the namespace constraints:

  • pubsub.redis
  • state.redis
  • bindings.redis
  • configuration.redis
  • bindings.zeebe.jobworker
  • bindings.zeebe.command
  • bindings.http
  • pubsub.kafka
  • bindings.kafka
  • pubsub.snssqs