FastAPI sur Kubernetes — le déploiement production que nous livrons par défaut

FastAPI a atteint l'ubiquité en production autour de 2023. Le framework lui-même est excellent. La story de déploiement qui l'entoure est pleine de patterns qui presque marchent — un seul processus uvicorn sous PID 1, shutdown gracieux manquant, pas de vérification OpenAPI en CI, Pydantic v1 qui traîne encore. Chacun a été un incident client à un moment donné.

Voici le template de déploiement FastAPI que nous appliquons à chaque nouveau service que nous gérons sur Kubernetes.

Dockerfile + endpoints de healthcheck

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 c'est « le processus est up ». Readiness c'est « le processus peut servir du trafic ». Ne les confondez pas — une base de données lente devrait sortir un pod de la rotation, pas le redémarrer.

L'article complet couvre :

• Pydantic v2 (model_config, computed_field, model_validator) — l'histoire de migration
• Choix du serveur ASGI : Gunicorn + UvicornWorker (défaut), Hypercorn (HTTP/2), Granian (plus récent)
• Vérification du schéma OpenAPI en CI — faire échouer le build si le schéma a dérivé
• Logging structuré avec le request ID propagé à travers les dépendances
• Patterns de tâches en arrière-plan — fastapi.BackgroundTasks vs Celery vs Arq
• Manifestes Kubernetes : resource requests, readinessProbe, terminationGracePeriodSeconds

Nous livrons ce template sur chaque service FastAPI managé.