Lab 05: Health checks

Día: miércoles · Branch de referencia: lab05-start → lab05-solution

Objetivo

Cablear los tres probes de Kubernetes (liveness, readiness, startup) del Deployment taskflow-api a los endpoints de salud que la app ya expone desde el día 1 (/healthz, /readyz, /startupz), y provocar fallos a propósito para observar cómo reacciona OpenShift en cada caso.

Contexto

TaskFlow ya distingue los tres endpoints en el código (app/TaskFlow.Api/Program.cs):

  • /healthz: solo verifica que el proceso .NET responde. No depende de Postgres a propósito.

  • /readyz: sí depende de Postgres (AddNpgSql, tag ready).

  • /startupz: igual que /healthz, pensado para darle tiempo al proceso a inicializar antes de que la liveness probe empiece a contar fallos.

Hasta este lab, ningún manifiesto de Kubernetes usaba estos endpoints: un pod colgado o sin base de datos no se comportaba distinto de uno sano a nivel de OpenShift.

Pasos

Antes de empezar: confirma que ya hiciste oc login como tu usuario (ver Antes de empezar).

  1. Completar manifests/deployment.yaml agregando startupProbe, livenessProbe y readinessProbe, cada uno apuntando a su endpoint correspondiente en el puerto 8080. El campo image también tiene un # TODO: este lab no cambia código de la app, así que no hace falta reconstruir nada, referencia la misma imagen taskflow-api:lab04 que ya publicó el pipeline el miércoles.

  2. Aplicar y confirmar que el pod pasa por Startup → Ready:

    oc apply -f labs/lab05-health/manifests/
oc get pods -w

  3. Provocar un fallo de readiness sin afectar liveness. Escalar Postgres a 0 réplicas:

    oc scale deployment/taskflow-db --replicas=0

    Observar con oc get pods y oc get endpoints taskflow-api: el pod de la API no se reinicia, pero desaparece de los Endpoints del Service, deja de recibir tráfico sin que Kubernetes lo mate, porque el problema es de una dependencia externa, no del proceso en sí.

  4. Revertir: oc scale deployment/taskflow-db --replicas=1 y confirmar que el pod de la API vuelve a los Endpoints sin haberse reiniciado nunca.

  5. Provocar un fallo de liveness. Entrar al contenedor y matar el proceso principal:

    oc exec deploy/taskflow-api -- kill 1

    Esta vez sí: oc get pods va a mostrar un RESTARTS incrementado: el proceso murió, la liveness probe lo detecta, y Kubernetes reinicia el contenedor.

Criterios de "hecho"

  • Los tres probes están definidos y usan los endpoints correctos.

  • Se observó (no solo se leyó) que un fallo de readiness saca el pod de Endpoints sin reiniciarlo.

  • Se observó que un fallo de liveness sí reinicia el contenedor.

  • El equipo puede explicar por qué /healthz deliberadamente no depende de la base de datos.

Pistas

  • Si el pod nunca llega a Ready, revisar primero el startupProbe: un failureThreshold/periodSeconds muy ajustado puede matar al pod antes de que Kestrel termine de levantar.

  • oc describe pod <pod> muestra en Events exactamente qué probe falló y con qué respuesta.