From 6fc2e274fd8be76d8c98cfab59d5cec43839e4b0 Mon Sep 17 00:00:00 2001 From: Mark Fussell Date: Wed, 26 Jun 2024 13:04:54 -0700 Subject: [PATCH] Update daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md Signed-off-by: Mark Fussell Signed-off-by: salaboy --- .../en/operations/hosting/kubernetes/kubernetes-dapr-shared.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md index 7c30552d0..34ab0f099 100644 --- a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md @@ -27,7 +27,7 @@ By default, when Dapr is installed into a Kubernetes cluster, the Dapr control p -While sidecars are Dapr's default deployment strategy, some use cases require other approaches. Let's say you want to decouple the lifecycle of your workloads from the Dapr APIs. A typical example of this is functions, or function-as-a-service runtimes, which might automatically downscale your idle workloads to free up resources. For such cases, keeping the Dapr APIs and all the Dapr async functionalities (such as subscriptions) separate might be required. +While sidecars are Dapr's default deployment, some use cases require other approaches. Let's say you want to decouple the lifecycle of your workloads from the Dapr APIs. A typical example of this is functions, or function-as-a-service runtimes, which might automatically downscale your idle workloads to free up resources. For such cases, keeping the Dapr APIs and all the Dapr async functionalities (such as subscriptions) separate might be required. Dapr Shared was created for these scenarios, extending the Dapr sidecar model with two new deployment approaches: `DaemonSet` and `Deployment`.