FastAPI auf Kubernetes — das Produktions-Deployment, das wir standardmäßig ausliefern

FastAPI erreichte um 2023 Produktions-Ubiquität. Das Framework selbst ist exzellent. Die Deployment-Story drumherum ist voll mit Patterns, die fast funktionieren — ein einzelner Uvicorn-Prozess unter PID 1, fehlender Graceful Shutdown, keine OpenAPI-Verifikation in CI, Pydantic v1, das immer noch herumhängt. Jedes davon war irgendwann ein Kundenvorfall.

Dies ist die FastAPI-Deployment-Vorlage, die wir auf jeden neuen Service anwenden, den wir auf Kubernetes managen.

Dockerfile + Healthcheck-Endpunkte

FROM python:3.12-slim
WORKDIR /app
COPY requirements.lock.txt ./
RUN pip install --no-cache-dir --require-hashes -r requirements.lock.txt
COPY . .
USER 1000
EXPOSE 8000
CMD ["gunicorn", "app.main:app", "--worker-class", "uvicorn.workers.UvicornWorker", \
     "--workers", "4", "--bind", "0.0.0.0:8000", "--timeout", "30"]

@app.get("/healthz", include_in_schema=False)
async def liveness(): return {"ok": True}
 
@app.get("/ready", include_in_schema=False)
async def readiness(): return {"ok": await db.is_connected()}

Liveness ist „der Prozess läuft". Readiness ist „der Prozess kann Traffic bedienen". Vermischen Sie sie nicht — eine langsame Datenbank sollte einen Pod aus der Rotation nehmen, nicht ihn neu starten.

Der vollständige Beitrag behandelt:

• Pydantic v2 (model_config, computed_field, model_validator) — die Migrations-Story
• ASGI-Server-Wahl: Gunicorn + UvicornWorker (Default), Hypercorn (HTTP/2), Granian (neuer)
• OpenAPI-Schema-Verifikation in CI — den Build fehlschlagen lassen, wenn das Schema driftet
• Strukturiertes Logging mit Request-ID, propagiert durch Abhängigkeiten
• Background-Task-Patterns — fastapi.BackgroundTasks vs Celery vs Arq
• Kubernetes-Manifeste: Resource Requests, readinessProbe, terminationGracePeriodSeconds

Wir liefern diese Vorlage auf jedem gemanagten FastAPI-Service aus.