Cluster connection configuration
This guide explains how to customize the Conductor agent and Dapr control plane settings to match your operational requirements when creating a cluster connection.
Once a cluster connection is created, a set of Kubernetes manifests will be generated and should be installed using one of the approaches show in the installation guide.
✅Best Practices
1. Start with defaults - Conductor provides sensible defaults
2. Monitor with Advisor - Let it identify issues
3. Apply recommendations - Adjust based on actual usage
4. Iterate gradually - Don't over-optimize prematurely
Configuration options
The following configuration options are available when onboarding a cluster connection to your Conductor organization.
🛡️Manage Dapr control plane via Conductor
One of the main benefits of Conductor is the ability to offload the management of a cluster's Dapr control plane to the Conductor agent.
The following actions can be executed by Conductor:
- Installation and upgrade of Dapr via the Conductor agent
- Automatic rollout of Dapr-enabled applications after Dapr version changes
- Reconciliation of Dapr config changes to Conductor desired state
- Configuration of Dapr control plane deployment using customized Helm values
⚙️Dapr Control Plane
🔧Conductor Agent
Some configuration options below are not available in Conductor Free. If you need advanced Dapr management or configuration options, contact the Diagrid sales team
Dapr control plane configuration
Conductor can be configured to coordinate and execute a variety of Dapr operational tasks, alleviating the burden of Dapr management while providing all of the necessary insights to troubleshoot any challenges that may arise.
Customize your cluster's Dapr control plane installation using available configuration options.
Manage Dapr Control Plane via Conductor Agent
The Dapr control plane can be installed before or after connecting your cluster to Conductor. However, existing Dapr installations that were deployed using a sub-chart of a parent Helm chart can not be managed by the Conductor agent and therefore unsupported in Conductor.
During the cluster onboarding process, you can configure the Conductor agent to do one of the following after it is successfully deployed:
- Perform a fresh install of the Dapr control plane in the target cluster
- Manage the existing Dapr control plane installation present in the cluster and upgrade to a later version if available
When selecting this option, you can also set Rollout all applications, which will perform a rolling restart of all dapr-enabled pod deployments to ensure the Dapr Sidecars in the cluster are running the same version of Dapr as the control plane.
Conductor supports the three latest minor versions (n-2), and a select number of patch versions for Dapr. By default, Conductor will target the latest available Dapr version and install it in the dapr-system namespace.
Select Environment Profile
If Conductor will be used to manage Dapr, select the Dapr helm chart configuration that best matches your desired installation or customize to use the values of your choice.
- Dev - Optimized for secure networking, fast iteration, and lower resource usage
- Prod - Optimized for secure networking, high availability, and fault tolerance
Using Custom Certificates for Dapr Upgrade
You can set custom mTLS certificates for the Dapr upgrade using Helm values.
dapr_sentry:
tls:
root:
certPEM: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
issuer:
certPEM: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
keyPEM: |
-----BEGIN EC PRIVATE KEY-----
...
-----END EC PRIVATE KEY-----
The Prod profile makes use of Dapr High-Availability (HA) mode. For an in-depth look at running Dapr in production, see the Running Dapr in Production Guide
Enable Dapr configuration reconciliation
Enable Dapr configuration reconciliation to detect Dapr configuration drift and reconcile Dapr Helm settings in the connected cluster to match the desired state configuration defined in Conductor.
Enable Certificate Rotation
Use Conductor's automatic certificate rotation feature to delegate the responsibility of managing Dapr's mTLS certificates entirely to Conductor, avoiding any downtime for the Dapr control plane and your applications.
Conductor will perform the certificate rotation and orchestrate the rollout of the Dapr control plane and your applications based on the renewal frequency and renewal window specified. If the feature is enabled, but no renewal frequency is set, the Dapr mTLS certificates will be automatically rotated after the default expiry period of 1 year.
Conductor Agent Configuration
Conductor consists of three main components, deployed to the diagrid-cloud namespace, that can be configured independently. The Conductor agent is responsible for monitoring the Dapr control plane in the connected cluster.
Enable auto-upgrades for the Conductor agent to receive the latest updates and avoid manual intervention
Agent Components
| Component | Purpose | Default Resources |
|---|---|---|
| diagrid-agent (Deployment) | Manages Dapr control plane, handles upgrades and configuration | 250Mi memory, 10m CPU |
| diagrid-agent-logs-collector (DaemonSet) | Collects logs from Dapr sidecars via open telemetry | 250Mi memory, 10m CPU |
| diagrid-agent-otel (StatefulSet) | Collects metrics from Dapr and applications via open telemetry | 250Mi memory, 100m CPU |
The default resource settings should be appropriate for most use cases, but can be modified via the CLI or console when onboarding a cluster connection.
Kubernetes Node Selectors and Tolerations
Both the diagrid-agent Deployment and the diagrid-agent-logs-collector DaemonSet can be modified to target specific cluster nodes or tolerate certain node taints configured in the target Kubernetes cluster.
By default, two tolerations are applied on the logs collector DaemonSet to ensure log collection from apps running on control plane and master nodes; These can be deleted or updated as necessary:
- key: "node-role.kubernetes.io/control-plane"
operator: "Exists"
effect: "NoSchedule"
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
When to use:
- To ensure Conductor components run on Linux nodes where they are supported
- To target ARM-based nodes in a cluster supporting multiple OS architectures. See: ARM configuration guide →
Managing Active Cluster Connections
View Cluster Connections
Cluster connections can be viewed via the Cluster List view in the Conductor console or via the diagrid clusters list command, regardless of connectivity status.
To see Dapr configuration information for a given cluster connection, select Desired Dapr Settings from the Cluster List action menu.
Edit Cluster Connections
Cluster connections and their associated configuratoin can be edited via the Cluster List view in the Conductor console or via the diagrid clusters update command. Keep in mind you cannot change the cluster name or cluster distribution type after creation.
Revert Cluster Connection Configuration Settings
If a Dapr control plane change is made through Conductor that leads to unexpected behavior in a connected cluster, there is an option to revert to the previously applied control plane configuration.
The revert functionality will only appear if a user has the appropriate RBAC permissions and one or more Dapr control plane changes have been made through Conductor.
When the revert option is available for a cluster, you will be able to view the current and previous Dapr control plane configuration versions and determine to proceed with the rollback process.
Conductor does not keep a version log of all Dapr changes applied to a cluster, but does store the n-1 configuration settings, where n represents the current cluster configuration.
Delete Cluster Connections
Cluster connections can be deleted via the cluster list view in the Conductor console or via the diagrid clusters delete command. Cluster workfloads will continue running normally, but will no longer be managed or monitored by Conductor.
To ensure that all Conductor-specific resources are deleted from the Kubernetes cluster, ensure you run a delete operation against the Kubernetes API. Use the diagrid clusters manifests command to print the manifests for the cluster connection and delete them from the Kubernetes cluster.