دورة

Déployer un service IA sur Kubernetes avec Helm

Conteneuriser une API d'inférence FastAPI → Gemini, écrire son chart Helm de zéro (sondes, ressources, HPA, PDB, NetworkPolicy, non-root), la charger jusqu'à déclencher l'autoscaling et la mettre à jour sans perdre une requête.

متقدم 6 دروس 6h
ابدأ الدورة
التقدّم 0% · 0/6

هذا المحتوى غير مترجم بعد. تُعرض النسخة الأصلية.

Ferrand Médical, distributeur de matériel médical (900 salariés), a mis en service un assistant interne pour son support informatique : les salariés posent leur question (« mon VPN ne se connecte pas depuis l'hôtel »), Gemini répond en trois phrases. Le prototype tournait dans un conteneur sur une VM. Il est tombé deux fois en un mois : une fois à cause d'une fuite mémoire jamais redémarrée, une fois parce que le déploiement d'une nouvelle version a coupé le service pendant quatre minutes, un lundi à 9 h. L'équipe plateforme exploite déjà Kubernetes pour d'autres applications et demande que l'assistant y entre avec les mêmes garanties que le reste.

Ce projet construit ce service de bout en bout et le prouve sur un vrai cluster local.

L'assistant interne servi par deux pods différents derrière l'Ingress NGINX du cluster kind (capture réelle du 2026-10-15)

Ce que vous livrez

  • Une API d'inférence FastAPI qui appelle Gemini, avec sondes de santé, délestage en surcharge, métriques Prometheus et journaux JSON.
  • Une image non-root de 174 Mo, compatible avec un système de fichiers en lecture seule.
  • Un chart Helm écrit de zéro : Deployment, Service, Ingress, ConfigMap, HPA, PodDisruptionBudget, NetworkPolicy, ServiceAccount sans jeton. La clé Gemini n'y figure jamais : elle vit dans un Secret créé à part.
  • Des tests : 18 tests sans clé (API et rendu du chart avec helm template), un test de bout en bout sur le cluster, un test de charge mesuré.
  • Une procédure de mise à jour et de retour arrière validée sous charge : 68 993 requêtes, zéro erreur, à travers une mise à jour, une version cassée et un rollback.

Architecture

flowchart LR
  U["Navigateur / curl"] -->|"http://assistant.127.0.0.1.nip.io:8081"| ING["Ingress NGINX (nœud control-plane)"]
  subgraph KIND["Cluster kind lab-k8s-ia"]
    ING --> SVC["Service inference"]
    SVC --> P1["Pod API (worker)"]
    SVC --> P2["Pod API (worker2)"]
    HPA["HPA 2 → 6 pods"] -.->|"CPU via metrics-server"| P1
    NP["NetworkPolicy"] -.-> P1
    SEC["Secret inference-gemini (créé par kubectl)"] -.-> P1
    CM["ConfigMap (modèle, limites)"] -.-> P2
  end
  P1 -->|"HTTPS 443"| G["API Gemini"]
  P2 -->|"HTTPS 443"| G

Stack

CoucheChoixPourquoi
APIFastAPI 0.141, uvicorn, google-genai 2.31asynchrone : un pod attend Gemini sans bloquer les autres requêtes
Modèlegemini-3.5-flash (clé d'API), gemini-2.5-flash sur Vertex AIvariable MODEL, aucune valeur en dur
Clusterkind 0.33, Kubernetes 1.37, 3 nœudsgratuit, jetable, assez réaliste pour tester PDB et répartition
EntréeIngress NGINX controller-v1.15.1demandé par l'équipe plateforme ; retiré par le projet Kubernetes, voir leçon 2
PackagingHelm 3.19une release versionnée = un retour arrière en une commande
Mise à l'échelleHPA autoscaling/v2 + metrics-server 0.9.0CPU en lab ; métrique « requêtes en cours » expliquée pour la production

Coût et durée

PosteCoût
Cluster kind0 € (local, 3 conteneurs Docker, 1,8 Go de RAM mesurés au pic de charge)
make e2e1 appel Gemini Flash : une fraction de centime
make load0 appel (backend fake, le test mesure Kubernetes, pas Gemini)
Ressources cloudaucune

Durée : 6 heures, dont 15 minutes de construction de cluster et d'images.

Prérequis

  • Avoir déjà écrit un Deployment et un Service à la main, et lu des journaux avec kubectl logs.
  • Docker avec 4 Go de RAM libres, kind, kubectl, helm 3, Python 3.10+.
  • Une clé d'API Gemini (Google AI Studio). Le port 8081 de la machine doit être libre.

Programme

LeçonCe qui avanceCommande qui marche à la fin
1. L'API d'inférence et son imageAPI, sondes, délestage, métriques, image non-rootmake test vert
2. Le cluster kind et l'Ingresscluster 3 nœuds, Ingress NGINX, metrics-serverkubectl get nodes : 3 nœuds Ready
3. Le chart Helm, écrit de zérotemplates, values, Secret hors chart, tests de rendumake up puis make e2e vert
4. Sondes, ressources, sécuritésondes, requests/limits, non-root, PDB, NetworkPolicyNetworkPolicy vérifiée par make e2e
5. Autoscaling et test de chargeHPA CPU mesuré, métrique custom, un 502 diagnostiquémake load : 2 → 6 pods
6. Mise à jour progressive et rollbackrolling update, version cassée, helm rollback, nettoyagemake down : cluster supprimé

Le dépôt complet est dans files/ : make help liste les commandes.

الموارد

تنزيل الكل (.zip)

المراجع