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 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:

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

Component Builder

Dapr provides flexibility to developers for building resilient microservices using the component model. Configuring these component manifests correctly to connect to the underlying infrastructure resources is a crucial part of operating Dapr applications. Conductor helps you create these component specifications with the Component Builder.

Component Builder allows users to easily configure components using a user-friendly interface with trustworthy templates, YAML schema validation and component initialization checks. This not only simplifies the configuration process but also reduces the risk of errors across development and higher-level environments.

Watch this short video for a comprehensive overview of Component Builder.

Using the Component Builder

To create a component manifest file, navigate to the Conductor left side panel and select Component Builder.

From the list, select the type of component to create:

Then, select the infrastructure resource of your choice and click Continue:

Choose the authentication profile and enter the required information corresponding to the connection details for the infrastructure resource. Click Continue to move to the next step:

Enter the Required Configuration Items and use the smart selector on the right to add any additional desired metadata properties. Click Continue:

Pick the Cluster and optionally the Namespace allowing you to scope the component to only select the applications that should have access to the infrastructure.

Finally, review the component YAML file and edit it, if needed, before downloading it or copying the content to add to your Dapr project.

Conductor will not apply the manifest to your Kubernetes cluster.