Deploy and run Dapr in Kubernetes mode on Dapr Docs

Overview of Dapr on Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Dapr can be configured to run on any supported versions of Kubernetes. To achieve this, Dapr begins by deploying the following Kubernetes services, which provide first-class integration to make running applications with Dapr easy.

Kubernetes services	Description
`dapr-operator`	Manages component updates and Kubernetes services endpoints for Dapr (state stores, pub/subs, etc.)
`dapr-sidecar-injector`	Injects Dapr into annotated deployment pods and adds the environment variables `DAPR_HTTP_PORT` and `DAPR_GRPC_PORT` to enable user-defined applications to easily communicate with Dapr without hard-coding Dapr port values.
`dapr-placement`	Used for actors only. Creates mapping tables that map actor instances to pods
`dapr-sentry`	Manages mTLS between services and acts as a certificate authority. For more information read the security overview
`dapr-scheduler`	Provides distributed job scheduling capabilities used by the Jobs API, Workflow API, and Actor Reminders

Supported versions

Dapr support for Kubernetes is aligned with Kubernetes Version Skew Policy.

Deploy Dapr on a Kubernetes cluster

Mon, 01 Jan 0001 00:00:00 +0000

When setting up Dapr on Kubernetes, you can use either the Dapr CLI or Helm.

Hybrid clusters

Both the Dapr CLI and the Dapr Helm chart automatically deploy with affinity for nodes with the label kubernetes.io/os=linux. You can deploy Dapr to Windows nodes if your application requires it. For more information, see Deploying to a hybrid Linux/Windows Kubernetes cluster.

Install with Dapr CLI

You can install Dapr on a Kubernetes cluster using the Dapr CLI.

Upgrade Dapr on a Kubernetes cluster

Mon, 01 Jan 0001 00:00:00 +0000

You can upgrade the Dapr control plane on a Kubernetes cluster using either the Dapr CLI or Helm.

Note

Refer to the Dapr version policy for guidance on Dapr’s upgrade path.

Upgrade using the Dapr CLI

You can upgrade Dapr using the Dapr CLI.

Production guidelines on Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Cluster and capacity requirements

Dapr support for Kubernetes is aligned with Kubernetes Version Skew Policy.

Use the following resource settings as a starting point. Requirements vary depending on cluster size, number of pods, and other factors. Perform individual testing to find the right values for your environment. In production, it’s recommended to not add memory limits to the Dapr control plane components to avoid OOMKilled pod statuses.

Deployment	CPU	Memory
Operator	Limit: 1, Request: 100m	Request: 100Mi
Sidecar Injector	Limit: 1, Request: 100m	Request: 30Mi
Sentry	Limit: 1, Request: 100m	Request: 30Mi
Placement	Limit: 1, Request: 250m	Request: 75Mi

Note

For more information, refer to the Kubernetes documentation on CPU and Memory resource units and their meaning.

Helm

When installing Dapr using Helm, no default limit/request values are set. Each component has a resources option (for example, dapr_dashboard.resources), which you can use to tune the Dapr control plane to fit your environment.

Deploy Dapr per-node or per-cluster with Dapr Shared

Mon, 01 Jan 0001 00:00:00 +0000

Dapr automatically injects a sidecar to enable the Dapr APIs for your applications for the best availability and reliability.

Dapr Shared enables two alternative deployment strategies to create Dapr applications using a Kubernetes Daemonset for a per-node deployment or a Deployment for a per-cluster deployment.

DaemonSet: When running Dapr Shared as a Kubernetes DaemonSet resource, the daprd container runs on each Kubernetes node in the cluster. This can reduce network hops between the applications and Dapr.
Deployment: When running Dapr Shared as a Kubernetes Deployment, the Kubernetes scheduler decides on which single node in the cluster the daprd container instance runs.

Dapr Shared deployments

For each Dapr application you deploy, you need to deploy the Dapr Shared Helm chart using different shared.appIds.

Why Dapr Shared?

By default, when Dapr is installed into a Kubernetes cluster, the Dapr control plane injects Dapr as a sidecar to applications annotated with Dapr annotations ( dapr.io/enabled: "true"). Sidecars offer many advantages, including improved resiliency, since there is an instance per application and all communication between the application and the sidecar happens without involving the network.

How-to: Persist Scheduler Jobs

Mon, 01 Jan 0001 00:00:00 +0000

The Scheduler service is responsible for writing jobs to its Etcd database and scheduling them for execution. By default, the Scheduler service database embeds Etcd and writes data to a Persistent Volume Claim volume of size 1Gb, using the cluster’s default storage class. This means that there is no additional parameter required to run the scheduler service reliably on most Kubernetes deployments, although you will need additional configuration if a default StorageClass is not available or when running a production environment.

Deploy to hybrid Linux/Windows Kubernetes clusters

Mon, 01 Jan 0001 00:00:00 +0000

Dapr supports running your microservices on Kubernetes clusters on:

Windows
Linux
A combination of both

This is especially helpful during a piecemeal migration of a legacy application into a Dapr Kubernetes cluster.

Kubernetes uses a concept called node affinity to denote whether you want your application to be launched on a Linux node or a Windows node. When deploying to a cluster which has both Windows and Linux nodes, you must provide affinity rules for your applications, otherwise the Kubernetes scheduler might launch your application on the wrong type of node.

Running Dapr with a Kubernetes Job

Mon, 01 Jan 0001 00:00:00 +0000

The Dapr sidecar is designed to be a long running process. In the context of a Kubernetes Job this behavior can block your job completion.

Native sidecars

On Kubernetes 1.28+, you can enable native sidecars to ensure daprd operates as a Kubernetes native sidecar and follows its shutdown semantics.

When running a basic Kubernetes Job, you need to call the /shutdown endpoint for the sidecar to gracefully stop and the job to be considered Completed.

How-to: Mount Pod volumes to the Dapr sidecar

Mon, 01 Jan 0001 00:00:00 +0000

The Dapr sidecar can be configured to mount any Kubernetes Volume attached to the application Pod. These Volumes can be accessed by the daprd (sidecar) container in read-only or read-write modes. If a Volume is configured to be mounted but it does not exist in the Pod, Dapr logs a warning and ignores it.

For more information on different types of Volumes, check the Kubernetes documentation.

Configuration

You can set the following annotations in your deployment YAML: