From 812c9aa4df5bf6c959ce6eee1b93cfce0678b882 Mon Sep 17 00:00:00 2001 From: Richard87 Date: Mon, 16 Dec 2024 13:19:37 +0100 Subject: [PATCH] Add documentation for HealthChecks --- public-site/docs/radix-config/index.md | 74 +++++++++++++++++++++++++- 1 file changed, 73 insertions(+), 1 deletion(-) diff --git a/public-site/docs/radix-config/index.md b/public-site/docs/radix-config/index.md index 009dc90f..cf82ed63 100644 --- a/public-site/docs/radix-config/index.md +++ b/public-site/docs/radix-config/index.md @@ -492,7 +492,7 @@ One exception is when the `replicas` value is set to `0` (i.e. the component is The previous `resources` block have been replaced by `triggers`. ::: -#### Azure Service bus +#### `azureServiceBus` trigger Take a look here [github.com/equinor/radix-sample-keda](https://github.com/equinor/radix-sample-keda) for a sample implementation that runs on Radix. @@ -511,6 +511,46 @@ Service Account: keda-operator # We are hoping on improving this - https://github.com/kedacore/keda/issues/5630 ``` + +### `healthChecks` + +By default Radix configures a TCP Readiness probe that tells the platform your application is ready to accept traffic as soon as the port is opened. +However it is reccommended to to configure this yourself. A HTTP Probe could inform Radix that the application with all the required backend systems (like databases or caches) is ready for work. We also support Liveness and Startup Probes. + +If any custom probes are configured, Radix will not include the default readiness probe and you must configure it yourself. + +```yaml +spec: + components: + - name: backend + healthChecks: + startupProbe: + tcpSocket: + port: 8000 + livenessProbe: + httpGet: + port: 8000 + path: /healthz/live + readinessProbe: + successThreshold: 1 + periodSeconds: 30 + failureThreshold: 3 + initialDelaySeconds: 10 + timeoutSeconds: 5 + httpGet: + port: 8000 + path: /healthz/ready # Component is Ready when this endpoint returns a successful status code (2xx or 3xx) +``` + +All probes have all settings (except for successThreshold that is not available for liveness and startup probes). We support HTTP, TCP, Exec and GRPC probes. +`environmentConfig` can also override individual startup, liveness or readiness-probes (but will not merge probe specific config). + +:::warning +Incorrectly configured probes can lead to premature restarts and will affect your uptime. + +Read more about probes here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ +::: + ### `imageTagName` ```yaml @@ -858,6 +898,38 @@ spec: The `horizontalScaling` field of a component environment config adds automatic scaling of the component in the environment, or it combines or overrides a component `imageTagName` if it is defined. +#### `healthChecks` + +Health check probes defined here will override probes defined on the component level. + +```yaml +spec: + components: + - name: backend + healthChecks: + startupProbe: + tcpSocket: + port: 8000 + livenessProbe: + tcpSocket: + port: 8000 + readinessProbe: + httpGet: + port: 8000 + path: /health/ready + environmentConfig: + - environment: prod + healthChecks: + livenessProbe: + httpGet: + port: 8000 + path: /health/alive +``` + +In this example, the prod environment will have 3 probes, a startup probe (TCP port 8000), a liveness check (HTTP /health/ready) and a readiness probe (HTTP /health/ready) + +Please see more information at [`healthChecks`](#healthchecks) for detailed information and warnings. + #### `imageTagName` ```yaml