From 7b83e1d3b288461221c89c9daa71943d3ddfd5fd Mon Sep 17 00:00:00 2001 From: salaboy Date: Tue, 21 May 2024 13:24:43 +0100 Subject: [PATCH] Update daprdocs/content/en/operations/dapr-shared/dapr-shared.md Co-authored-by: Mark Fussell Signed-off-by: salaboy --- daprdocs/content/en/operations/dapr-shared/dapr-shared.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/operations/dapr-shared/dapr-shared.md b/daprdocs/content/en/operations/dapr-shared/dapr-shared.md index 5deb79336..651cfea9a 100644 --- a/daprdocs/content/en/operations/dapr-shared/dapr-shared.md +++ b/daprdocs/content/en/operations/dapr-shared/dapr-shared.md @@ -23,7 +23,7 @@ For each Dapr application, you need to deploy the Dapr Shared chart using differ ## Why Dapr Shared? -By default, when Dapr is installed into a Kubernetes Cluster, the Dapr Control Plane is in charge of injecting the daprd sidecar to workloads annotated with Dapr annotations (`dapr.io/enabled: "true"`). This mechanism delegates the responsibility of defining which workloads will be interacting with the Dapr APIs to the team in charge of deploying and configuring these workloads. Sidecars had the advantage of being co-located with your applications, so all communication between the application and the sidecar happens without involving the network. +By default, when Dapr is installed into a Kubernetes cluster, the Dapr control plane injects a Dapr as sidecar to applications annotated with Dapr annotations ( `dapr.io/enabled: "true"`). Sidecars have 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.