mirror of https://github.com/dapr/docs.git
Add note for sidecar readiness (#2817)
* Revert "java submodule"
This reverts commit b438550fbb.
* revert submodule changes
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
* remove note
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
* update link
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
Co-authored-by: Mark Fussell <markfussell@gmail.com>
This commit is contained in:
Hannah Hunter
GitHub
parent
d98a712a5c
commit
df5aab736e
|
|
@ -8,7 +8,13 @@ description: "Overview of the Dapr sidecar process"
|
|||
|
||||
Dapr uses a [sidecar pattern]({{< ref "concepts/overview.md#sidecar-architecture" >}}), meaning the Dapr APIs are run and exposed on a separate process, the Dapr sidecar, running alongside your application. The Dapr sidecar process is named `daprd` and is launched in different ways depending on the hosting environment.
|
||||
|
||||
The Dapr sidecar exposes [building block APIs]({{<ref building-blocks-concept>}}) used by your application business logic, a [metadata API]({{<ref metadata_api>}}) for discoverability of capabiliites and to set attributes and a [health API]({{<ref sidecar-health>}}) to determine health status.
|
||||
The Dapr sidecar exposes:
|
||||
|
||||
- [Building block APIs]({{<ref building-blocks-concept>}}) used by your application business logic
|
||||
- A [metadata API]({{<ref metadata_api>}}) for discoverability of capabilities and to set attributes
|
||||
- A [health API]({{<ref sidecar-health>}}) to determine health status and sidecar readiness and liveness
|
||||
|
||||
The Dapr sidecar will reach readiness state once the application is accessible on its configured port. The application cannot access the Dapr components during application start up/initialization.
|
||||
|
||||
<img src="/images/overview-sidecar-apis.png" width=700>
|
||||
|
||||
|
|
|
|||
|
|
@ -6,14 +6,18 @@ weight: 5000
|
|||
description: Dapr sidecar health checks.
|
||||
---
|
||||
|
||||
Dapr provides a way to determine it's health using an HTTP /healthz endpoint.
|
||||
With this endpoint, the Dapr process, or sidecar, can be probed for its health and hence determine its readiness and liveness. See [health API ]({{< ref health_api.md >}})
|
||||
Dapr provides a way to [determine its health using an HTTP `/healthz` endpoint]({{< ref health_api.md >}}). With this endpoint, the Dapr process, or sidecar, can be:
|
||||
|
||||
- Probed for its health
|
||||
- Determined for readiness and liveness.
|
||||
|
||||
The Dapr `/healthz` endpoint can be used by health probes from the application hosting platform. This topic describes how Dapr integrates with probes from different hosting platforms.
|
||||
|
||||
As a user, when deploying Dapr to a hosting platform (for example Kubernetes), the Dapr health endpoint is automatically configured for you. There is nothing you need to configure.
|
||||
When deploying Dapr to a hosting platform (for example, Kubernetes), the Dapr health endpoint is automatically configured for you.
|
||||
|
||||
Note: Dapr actors also have a health API endpoint where Dapr probes the application for a response to a signal from Dapr that the actor application is healthy and running. See [actor health API]({{< ref "actors_api.md#health-check" >}})
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr actors also have a health API endpoint where Dapr probes the application for a response to a signal from Dapr that the actor application is healthy and running. See [actor health API]({{< ref "actors_api.md#health-check" >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
## Health endpoint: Integration with Kubernetes
|
||||
|
||||
|
|
@ -24,7 +28,11 @@ For example, liveness probes could catch a deadlock, where an application is run
|
|||
|
||||
The kubelet uses readiness probes to know when a container is ready to start accepting traffic. A pod is considered ready when all of its containers are ready. One use of this readiness signal is to control which Pods are used as backends for Kubernetes services. When a pod is not ready, it is removed from Kubernetes service load balancers.
|
||||
|
||||
When integrating with Kubernetes, the Dapr sidecar is injected with a Kubernetes probe configuration telling it to use the Dapr healthz endpoint. This is done by the `Sidecar Injector` system service. The integration with the kubelet is shown in the diagram below.
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
The Dapr sidecar will be in ready state once the application is accessible on its configured port. The application cannot access the Dapr components during application start up/initialization.
|
||||
{{% /alert %}}
|
||||
|
||||
When integrating with Kubernetes, the Dapr sidecar is injected with a Kubernetes probe configuration telling it to use the Dapr healthz endpoint. This is done by the `Sidecar Injector` system service. The integration with the kubelet is shown in the diagram below.
|
||||
|
||||
<img src="/images/security-mTLS-dapr-system-services.png" width=600>
|
||||
|
||||
|
|
@ -84,6 +92,6 @@ readinessProbe:
|
|||
|
||||
For more information refer to;
|
||||
|
||||
- [ Endpoint health API]({{< ref health_api.md >}})
|
||||
- [Endpoint health API]({{< ref health_api.md >}})
|
||||
- [Actor health API]({{< ref "actors_api.md#health-check" >}})
|
||||
- [Kubernetes probe configuration parameters](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue