Skip to main content

Cluster prerequisites

The following guide details the prerequisites for onboarding a cluster to Conductor.

Installation prerequisites​

Before installing Conductor into a cluster, the following requirements must be met:

Supported platforms​

Currently, the following Kubernetes distributions are supported:

  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)
  • Azure Kubernetes Service (AKS)
  • Red Hat OpenShift (v4.x and above)
  • Local Kubernetes i.e. Minikube, kind, and Docker Desktop
Note

Additional Kubernetes distributions have not been tested with Conductor, but you may try them at your own risk.

Permissions​

To install the required Conductor agent, a user must have sufficient RBAC permissions- typically, the cluster-admin role. The required RBAC permissions for the Conductor agent align with the typical RBAC permissions required to install Dapr manually.

Cluster resources​

The recommended production resource configurations for the Dapr control plane are defined in the Dapr documentation and should be applied to your Dapr installation. Installing Dapr using Dev or Prod Helm profiles in Conductor set these for you automatically.

In addition, the cluster resources needed for Conductor are as follows:

  • The Conductor Agent deployment requests 200m CPU and 400Mi memory and runs two replicas by default.
  • The Conductor Agent Logs Collector daemon set uses a modified version of the OpenTelemetry Collector that requests 200m CPU and 400Mi memory per pod.

Networking​

Your Kubernetes cluster needs to be online and have outbound connectivity to Diagrid Cloud. The following URLs must be accessible from your clusters:

To run Dapr version upgrades using the upstream Helm chart and container images, you will need the additional URLs to be accessible from your clusters:

Note: If you opt to use Dapr container images from a private registry, it is not necessary to allow-list these addresses. However, it becomes your responsibility to manage the Dapr Helm chart and container images along with any upgrades you want to apply to your clusters. For more details, read the guide on how to use private images.

If you make use of Kubernetes network policies, you need to ensure the Conductor agent can reach the Dapr data plane (Dapr sidecars) in your cluster on port 3501 to access the metadata API.

Collected data​

For all Conductor connected clusters, the data sent from the Conductor agent to Diagrid Cloud is as follows:

Cluster data:

  • Dapr Helm chart values
  • Dapr Kubernetes resources (CRDs): Components, Resiliency, Configuration, Subscription
    • Not including sensitive Component information which is obfuscated in the agent
  • Component initialization status

Dapr-enabled app and sidecar data:

  • Container names
  • Container health status
  • Container restart count
  • Pod status and message
  • Pod uptime
  • Count of desired pod replicas and ready pod replicas
  • Dapr annotations

Metrics and logs data:

  • Dapr sidecar (daprd) logs from all Dapr-enabled apps
    • Only error, warning, and fatal log levels are collected
  • Dapr metrics from all Dapr-enabled apps and the Dapr control plane
    • Complete list of Dapr metrics collected found here
  • Resource data for Dapr-enabled app containers, Dapr sidecars, and Dapr control plane containers
    • CPU limit, request, and usage data
    • Memory limit, request, and usage data
  1. After installing the Kubernetes Metric Server on local Kubernetes clusters you may need to account for this requirement: Kubelet certificate needs to be signed by cluster Certificate Authority (or disable certificate validation by passing --kubelet-insecure-tls to Metrics Server). To pass that flag, use this command on your cluster: kubectl patch deployment metrics-server -n kube-system --type "json" -p '[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--kubelet-insecure-tls"}]'↩