Salud y Preparación

Los puntos finales de salud indican a los orquestadores si un proceso Python está activo (liveness) y si puede aceptar tráfico (readiness). Divídelos para que los picos de dependencia drenen el tráfico sin reiniciar los pods.

Receta

from fastapi import FastAPI, Response, status
 
app = FastAPI()
 
@app.get("/health/live")
def live():
    return {"status": "ok"}
 
@app.get("/health/ready")
def ready():
    if not db_ping():
        return Response(content='{"status":"down"}', status_code=503, media_type="application/json")
    return {"status": "ok"}

Cuándo usar esto:

• Comprobaciones de salud del balanceador de carga de Kubernetes/ECS.
• Despliegues continuos que dirigen el tráfico solo a pods listos.
• Fallos de dependencia que eliminan temporalmente la instancia de la rotación.
• Monitorización sintética comprobaciones externas de tiempo de actividad (generalmente solo /health/live público).

Ejemplo de Trabajo

Preparación de FastAPI con verificación de base de datos limitada por tiempo de espera e inicialización perezosa compatible con la sonda de inicio.

import asyncio
from contextlib import asynccontextmanager
 
from fastapi import FastAPI, Response, status
 
class HealthState:
    def __init__(self) -> None:
        self.db_ready = False
 
    async def check_db(self) -> bool:
        try:
            await asyncio.wait_for(fake_db_ping(), timeout=0.5)
            self.db_ready = True
            return True
        except Exception:
            self.db_ready = False
            return False
 
async def fake_db_ping() -> None:
    await asyncio.sleep(0.01)
 
state = HealthState()
 
@asynccontextmanager
async def lifespan(app: FastAPI):
    await state.check_db()
    yield
 
app = FastAPI(lifespan=lifespan)
 
@app.get("/health/live")
async def live():
    return {"status": "ok"}
 
@app.get("/health/ready")
async def ready():
    ok = await state.check_db()
    body = {"status": "ok" if ok else "degraded", "db": ok}
    if not ok:
        return Response(content=str(body), status_code=status.HTTP_503_SERVICE_UNAVAILABLE)
    return body

Lo que esto demuestra:

• Liveness siempre 200 si el bucle de eventos se ejecuta.
• Readiness devuelve 503 cuando falla la comprobación de la base de datos; el balanceador de carga deja de enrutar.
• Tiempo de espera corto en la comprobación de dependencias para evitar sondas colgadas.

Análisis Profundo

Mapeo de Sondas

Alcance de la Comprobación

• Readiness: pool de base de datos, caché, indicadores de funciones requeridos cargados.
• Liveness: evitar llamadas externas; el reinicio de kubelet es costoso.

Notas de Python

startupProbe:
  httpGet:
    path: /health/ready
    port: 8000
  failureThreshold: 30
  periodSeconds: 10

Errores Comunes

• Comprobación de DB en liveness: la interrupción de la DB mata todos los pods. Solución: readiness solo para dependencias.
• Readiness lenta siempre: el despliegue nunca termina. Solución: startupProbe para inicialización lenta, readiness rápida después.
• Readiness fluctuante: estampida de rebaño en la recuperación de la DB. Solución: histéresis o resultado de comprobación en caché corto (TTL de 1-2 s).
• Readiness pública expone internos: fuga de información {"db": false}. Solución: cuerpo genérico externamente, detalles en logs/métricas.
• Salud en puerto incorrecto: la sonda golpea el puerto de métricas. Solución: documentar el puerto de la aplicación 8000 en Deployment.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Despliegue - introducción a la salud
• Kubernetes para Aplicaciones Python - YAML de sondas
• Despliegues sin Tiempo de Inactividad - comportamiento de drenaje
• Métricas - contadores de fallos de sonda
• Mejores Prácticas de Observabilidad - lista de verificación de sondas

Versiones de la pila: Esta página se escribió para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+ y uv 0.6+.