Skip to content

docs(workload): health check = readiness probe + liveness/startup vía values (EN/ES) #237

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mjroson wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

docs(workload): health check = readiness probe + liveness/startup vía values (EN/ES) #237

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fcf5978
docs(workload): health check = readiness probe + how to add liveness/…
Aug 4, 2026
6d47d3c
docs(workload): la via universal para probes es values a nivel proyecto
Aug 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 35 additions & 5 deletions content/docs/en/project/workload/webservice.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,13 +35,43 @@ To enable auto-scaling, you can set the **Autoscaling** option to enabled and de
### What are the default success codes for a Web Service, and can I change them?
</summary>
The default success code is 200, indicating the service is healthy. You can change this code based on your application’s requirements, as some services might return different success codes based on specific actions.

The success code applies to the load balancer's health check. The in-cluster readiness probe follows the standard Kubernetes HTTP rule instead: any status code greater than or equal to 200 and less than 400 counts as success.
</details>

<details>
<summary>
### What happens if my health check fails repeatedly?
</summary>
If the health check fails consecutively and reaches the Failure Threshold (default is 60), the service is marked as unhealthy, and Kubernetes might restart or terminate the service instance to attempt a recovery.
The health check is deployed as the pod's **readiness probe** — and, for Public and Private services, as the load balancer's target health check. If it fails consecutively and reaches the Failure Threshold (default is 60), Kubernetes marks the pod as *not ready* and stops routing traffic to it until the check passes again. The container is **not** restarted: restarting an unhealthy container is the job of a liveness probe, which SleakOps does not add by default — see the next question to configure one.
</details>

<details>
<summary>
### Can I add a liveness or startup probe to my Web Service?
</summary>
Yes. The workload settings form manages the readiness probe only, but the Deployment template also renders a `livenessProbe` and a `startupProbe` when you define them in your [values](/docs/project/values). Add them in **Project → Settings → Chart Configuration**, in the **Values** editor, nested under the Workload's key — see [Project global values](/docs/project/values#project-global-values):

```yaml
backoffice: # your Workload's key, as shown in the generated values
livenessProbe:
httpGet:
path: /healthz
port: 8000
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 30
startupProbe:
httpGet:
path: /healthz
port: 8000
periodSeconds: 5
failureThreshold: 60
```

If the Workload's **Advanced → Values** tab is available on your account, you can set the same blocks there as a [workload override](/docs/project/values#the-workload-values-tab), without the wrapping key. Either way they are passed to the Deployment exactly as written, so any field of the Kubernetes probe spec is accepted (`httpGet`, `tcpSocket`, `exec`, `grpc`, timings and thresholds).

**Warning:** a failing liveness probe **restarts the container**. Point it at a lightweight endpoint that reflects only the process itself — if it also checks external dependencies such as your database, an outage of that dependency will restart every replica in a loop. Prefer tolerant settings (a long period and a high failure threshold), and use a startup probe instead of a large initial delay for slow-starting applications.
</details>

<details>
Expand Down Expand Up @@ -91,7 +121,7 @@ The **terminationGracePeriod** is a Kubernetes setting that defines how long (in

**How it works:** When Kubernetes needs to stop your container (during a deployment, scaling event, or shutdown), it first sends a **SIGTERM** signal to your process and then waits the number of seconds defined by `terminationGracePeriod` before forcefully killing the container. Most application frameworks handle SIGTERM automatically, but if you have custom processes, make sure your application listens for SIGTERM and gracefully closes all connections and ongoing work — otherwise Kubernetes may kill your container while it's still mid-operation.

**Default value:** 30 seconds
**Default value:** 120 seconds

**When to adjust it:**
- Increase it if your service needs more time to complete long-running tasks during shutdown.
Expand Down Expand Up @@ -222,7 +252,7 @@ Select how will be your connection and click on _Next_.
</Zoom>

### 4. Specify your workload settings
You’ll see the following for to specify the conditions.
You’ll see the following attributes. They define the Web Service **health check**, which SleakOps deploys as the pod's readiness probe and — for Public and Private services — as the load balancer's target health check.

<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
<img
Expand All @@ -236,11 +266,11 @@ You’ll see the following for to specify the conditions.
| **Path** | The path where Kubernetes checks if the web service is operational. Default: `/` |
| **Success Code** | The HTTP success code indicating the service's health. Default: `200`. |
| **Initial Delay Seconds** | Number of seconds after startup before health checks begin. Default: `10`. |
| **Timeout Seconds** | Number of seconds after startup before health checks begin. Default: `1`. |
| **Timeout Seconds** | Number of seconds the probe waits for a response before the attempt is considered failed. Default: `1`. |
| **Period Seconds** | Interval (in seconds) between each health check probe. Default: `5`. |
| **Success Threshold** | Minimum number of consecutive successes required for the probe to be considered successful after it has failed. Default: `1`. |
| **Failure Threshold** | Number of consecutive failures before the probe is considered to have failed. Default: `60`. |
| **terminationGracePeriod** | Time in seconds that Kubernetes waits for graceful shutdown before forcefully terminating the service. Default: `30`. |
| **terminationGracePeriod** | Time in seconds that Kubernetes waits for graceful shutdown before forcefully terminating the service. Default: `120`. |

Once those attributes are completed, click the Next button to move to the next step.

Expand Down
40 changes: 35 additions & 5 deletions content/docs/es/project/workload/webservice.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,13 +34,43 @@ Para habilitar el auto-escalado, puedes activar la opción **Autoscaling** y def
### ¿Cuáles son los códigos de éxito predeterminados para un Web Service y puedo cambiarlos?
</summary>
El código de éxito predeterminado es el 200, que indica que el servicio está sano. Puedes cambiar este código según los requisitos de tu aplicación, ya que algunos servicios pueden devolver diferentes códigos de éxito dependiendo de las acciones específicas.

El código de éxito se aplica a la verificación de salud del balanceador de carga. La readiness probe dentro del clúster sigue en cambio la regla HTTP estándar de Kubernetes: cualquier código mayor o igual a 200 y menor a 400 cuenta como éxito.
</details>

<details>
<summary>
### ¿Qué pasa si mi verificación de salud falla repetidamente?
</summary>
Si la verificación de salud falla de manera consecutiva y alcanza el umbral de fallos (el valor predeterminado es 60), el servicio se marcará como no saludable, y Kubernetes podría reiniciar o terminar la instancia del servicio para intentar una recuperación.
La verificación de salud se despliega como la **readiness probe** del pod — y, para servicios Public y Private, como la verificación de salud del balanceador de carga. Si falla de manera consecutiva y alcanza el Umbral de Fallos (el valor predeterminado es 60), Kubernetes marca el pod como *not ready* y deja de enviarle tráfico hasta que la verificación vuelva a pasar. El contenedor **no** se reinicia: reiniciar un contenedor no saludable es tarea de una liveness probe, que SleakOps no agrega por defecto — consulta la siguiente pregunta para configurar una.
</details>

<details>
<summary>
### ¿Puedo agregar una liveness o startup probe a mi Web Service?
</summary>
Sí. El formulario del workload administra únicamente la readiness probe, pero el template del Deployment también renderiza una `livenessProbe` y una `startupProbe` cuando las defines en tus [values](/docs/project/values). Agrégalas en **Project → Settings → Chart Configuration**, en el editor de **Values**, anidadas bajo la clave del Workload — consulta [Values globales del Project](/docs/project/values#values-globales-del-project):

```yaml
backoffice: # la clave de tu Workload, como aparece en los values generados
livenessProbe:
httpGet:
path: /healthz
port: 8000
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 30
startupProbe:
httpGet:
path: /healthz
port: 8000
periodSeconds: 5
failureThreshold: 60
```

Si la pestaña **Advanced → Values** del Workload está disponible en tu cuenta, puedes definir los mismos bloques ahí como [override del workload](/docs/project/values#el-tab-values-del-workload), sin la clave contenedora. En ambos casos se pasan al Deployment tal como los escribes, así que aceptan cualquier campo de la spec de probes de Kubernetes (`httpGet`, `tcpSocket`, `exec`, `grpc`, tiempos y umbrales).

**Advertencia:** una liveness probe que falla **reinicia el contenedor**. Apúntala a un endpoint liviano que refleje solo el proceso — si además chequea dependencias externas como tu base de datos, una caída de esa dependencia reiniciará todas las réplicas en loop. Prefiere valores tolerantes (un período largo y un umbral de fallos alto), y usa una startup probe en lugar de un retraso inicial grande para aplicaciones que tardan en arrancar.
</details>

<details>
Expand Down Expand Up @@ -90,7 +120,7 @@ El **terminationGracePeriod** es una configuración de Kubernetes que define cu

**Cómo funciona:** Cuando Kubernetes necesita detener tu contenedor (durante un despliegue, un evento de escalado o un apagado), primero envía una señal **SIGTERM** a tu proceso y luego espera la cantidad de segundos definida por `terminationGracePeriod` antes de matar forzosamente el contenedor. La mayoría de los frameworks con los que construimos aplicaciones manejan SIGTERM automáticamente, pero si tenés algo personalizado, asegurate de que tu aplicación escuche SIGTERM y cierre correctamente todas sus conexiones y procesos en curso — de lo contrario, Kubernetes puede matar el contenedor mientras una operación está a medias.

**Valor predeterminado:** 30 segundos
**Valor predeterminado:** 120 segundos

**Cuándo ajustarlo:**
- Auméntalo si tu servicio necesita más tiempo para completar tareas de larga duración durante el apagado.
Expand Down Expand Up @@ -223,7 +253,7 @@ Selecciona cómo será tu conexión y haz clic en _Siguiente_.
</Zoom>

### 4. Especifica los ajustes de tu servicio
Verás los siguientes atributos para especificar las condiciones.
Verás los siguientes atributos para especificar las condiciones. Estos ajustes definen la **verificación de salud** del Web Service, que SleakOps despliega como la readiness probe del pod y — para servicios Public y Private — como la verificación de salud del balanceador de carga.

<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
<img
Expand All @@ -237,11 +267,11 @@ Verás los siguientes atributos para especificar las condiciones.
| **Ruta** | La ruta donde Kubernetes verifica si el Web Service está operativo. Predeterminado: `/` |
| **Código de Éxito** | El código HTTP de éxito que indica la salud del servicio. Predeterminado: `200`. |
| **Retraso Inicial en Segundos** | Número de segundos después del inicio antes de que comiencen las verificaciones de salud. Predeterminado: `10`. |
| **Segundos de Tiempo de Espera** | Número de segundos después del inicio antes de que comiencen las verificaciones de salud. Predeterminado: `1`. |
| **Segundos de Tiempo de Espera** | Número de segundos que la probe espera una respuesta antes de considerar fallido el intento. Predeterminado: `1`. |
| **Segundos entre cada Verificación** | Intervalo (en segundos) entre cada prueba de verificación de salud. Predeterminado: `5`. |
| **Umbral de Éxitos** | Número mínimo de éxitos consecutivos requeridos para que la prueba se considere exitosa después de fallar. Predeterminado: `1`. |
| **Umbral de Fallos** | Número de fallos consecutivos antes de que la prueba se considere fallida. Predeterminado: `60`. |
| **terminationGracePeriod** | Tiempo en segundos que Kubernetes espera para el apagado ordenado antes de terminar forzosamente el servicio. Predeterminado: `30`. |
| **terminationGracePeriod** | Tiempo en segundos que Kubernetes espera para el apagado ordenado antes de terminar forzosamente el servicio. Predeterminado: `120`. |

Una vez completados estos atributos, haz clic en el botón Siguiente para continuar con el siguiente paso.

Expand Down