Application probes
In order for the application to be able to communicate state that should effect the Avassa system, there are three different kinds of probes, startup, liveness and readiness.
The probes allow an application to:
- trigger restarts
- provision and unprovision DNS entries.
- report aggregated error state from the probes
This article explains each probe and the system behavior related to each probe.
Common
Each probe can be of types http, tcp or command. Please also see the reference documentation for all probe settings.
HTTP
HTTP or HTTPS call to an endpoint, a HTTP status code of 2xx or 3xx is considered success.
TCP
TCP connect to a port, a successful connection is considered success.
Command
Runs a custom command inside the container. An exit code 0 indicates success, any other exit code indicates probe failure.
Startup probe
The startup probe is run once after the container is started. A startup probe is used to determine if a container is successfully started and can be seen as a special liveness probe that is used only once.
If the startup probe returns failure, the container is immediately restarted and the startup probe will be run again on the next invocation.
A common use case for the startup probe (versus using the liveness probe) is that the startup needs a longer timeout than what's wanted on the liveness probe check.
Liveness probe
A liveness probe is used to determine if a container is alive.
If the liveness probe fails the container will be restarted, at restart, the startup probe will be run again.
The liveness probe is executed periodiacally, on a configurable interval.
Readiness probe
Once a container has been successfully started, it may need a separate probe to determine if it is ready to accept traffic or not. For example, it should only be included as a backend server by a load balancer once it is ready.
NOTE: If a readiness probe is not configured, a running container is always considered ready.
The readiness probe is executed periodically, on a configurable interval.
When a container becomes unready, the container's service instance's DNS entry is removed, when the container/service is ready again, the DNS entries are restored for the instance.
Not ready
If a readiness probe returns non success, DNS entries are removed, but the application is still considered to be in a good state.
NOTE: If all readiness probes in a service are non ready, the applications will be set into error state.
Service state
| Container Ready Probe | Service Instance State |
|---|---|
| Any service container unready | unready |
| All service containers ready | ready |
Application operational state
| Service Instance State | Application Operational State |
|---|---|
| All service instances unready | error |
| At least one service instance ready | running |
A use case for being non ready is e.g. with Redis, where you can have an active master and a number of inactive replicas. Only the active master is available in DNS.